How do I access attribute 'Member' on a Group in a Policy Script that is triggered on postCreate

I trigger a policy script from a policy object set to handle changes from dirsync.

the operation is limited to Computer objects, in a specific OU, that have a set prefix.

the $Request  contains the following.  It does not include the 'Member' value -

How do I retrieve the 'current'/refreshed' value of 'Member' attribute when ARS has sniffed out a new group create matching the criteria above?

This question comes about because we are transitioning user provisioning off to a 3rd party provisioning tool  -

ARS policy detects through dirsync that a group was externally created in the domain

I tried $Request.get("Member") - assuming I get nothing back because that attribute isn't present in the $Request

Property name: nTSecurityDescriptor
Property name: parentGUID
Property name: instanceType
Property name: objectClass
Property name: ADsPath
Property name: description
Property name: whenCreated
Property name: name
Property name: displayName
Property name: info
Property name: objectSid
Property name: sAMAccountName
Property name: sAMAccountType
Property name: groupType
Property name: objectCategory

ARS policy 'on PostCreate' doesn't appear to include the member that was added as part of that creation.  add additional function for on PostModify?  what does that look like.

  • I found I could retrieve the value of 'Member' by initiating an additional query within the policy script - but that's probably not a most-efficient way.  is there an alternative to this available within the $request - or dirObj ?

    The policy script returns adspath -which gives me the cookie crumbs to the exact DC the group was created, and using that - I can call the directory searcher shortcut to re-query the group to obtain the member.   

    $adsiObj  = [ADSI]$Request.adspath
    $newMbr = ([adsisearcher]$adsiObj).findone().properties['Member'][0].tostring()

    is there a better way?

  • Is there really a member attribute on these objects? You say you have limited this to Computers. AD Groups I could understand and expect to have member, but computers - not expecting them to - they may have memberOf instead

  • Thanks for making me think - Glenn.   Something I wasn't doing when I explained my issue.

    ARS is set to listen for a new group to be created by the 3rd party provisioning source in one of our domains.

    <3rd party> creates a new group containing an admin user account as member using a specific naming prefix

    I wanted to extract the member attribute for the group - and have achieved that using the following ADSI search.  I was hoping the member attribute was included, or could be refreshed into the $Request - or called via dirObj instead of doing a whole new directorySearch of the $request object to get 'Member'

    $adsiObj   = [ADSI]$Request.adspath
    $newUser = ([adsisearcher]$adsiObj).findone().properties['Member'][0].tostring()

    Our admin account names exceed the regular account names in length so, I further chop the result down to 1st 5 characters of the CN portion of that big-beautiful ADSPATH returned by ADSI

    $regUSRCN = ($($newUser.split('=|,'))[1]).toupper().substring(0,5)
    $newManagedBy = $regUSRCN 

    We split ownership of provisioning with this 3rd party group internally

    - they create the user group,

    - we monitor dirsync in policy to detect the new 'group' in AD with the correct class, and name

    and that's where the need to see the member attribute comes in.

    This is used to map a user to the computer they have special access for, and the results are used to populate managedby and secondary owner attributes.

    I'm feeling my way through this 

    - but I'm at the point where I've thrown code at a wall to see if that works ... and now I'm looking to make that more/MOST efficient.

    Not sure I'm there yet.