A Forum reader recently asked:
“When I look for the membership of AD group G_Users, the users are not synchronized to the AD group. The group itself is synchronised OK. I also thought the members would be in sync, but they are not. It looks like it that it is because the users are not in the same OU as the Group is.”
And here’s the response from Rob Schneider …
Note the peculiarities of AD as relate to Group synchronization:
1. When you edit a user in eDirectory, and add them to a group, this simultaneously places a “group Membership” attribute on the user, and a “Member” attribute (referencing the user) on the Group.
2. When you edit a Group in E-Dir, the same is true, in reverse.
In “XML land” when you do case #1 above, it sends an XML document that is converted by the AD DC into an LDAP request to modify the user’s Group Membership. AD does NOT allow direct editing of group memberships on the user object. All changes to the User’s Group Membership have to come as the result of an edit to a GROUP object.
How might this result in problems in what you see synchronized into AD groups? Imagine that you have a minimum criteria for a user to have an account created in AD (an entitlement, or required attribute). Further, imagine that you place this user into AD groups BEFORE the user is granted this entitlement.
IDM will attempt to sync the group membership changes but fail for lack of an AD object to reference when it tries to add this new member to the AD group. Later, when you grant the entitlement and the account is created in AD, the driver tries to sync the user object and all of its group memberships. The group memberships fail because of what I said above. End result: you don’t see some users in your AD groups.
I believe Father Ramon pointed me to a policy you can implement that overcomes this limitation, and here’s my latest iteration of it. (You’ll have to adjust the terms to meet your environment, or as they say, YMMV.)
This is in my subscriber command transform:
<?xml version="1.0" encoding="UTF-8"?><policy xmlns:query="http://www.novell.com/nxsl/java/com.novell.nds.dirxml.driver.XdsQueryProcessor"> <rule> <description>Add new user to associated groups</description> <conditions> <and> <if-operation op="equal">add</if-operation> <if-class-name op="equal">User</if-class-name> <if-op-attr name="Group Membership" op="available"/> <if-op-attr mode="regex" name="Group Membership" op="equal">\\customer\\CS\\AD\\.+</if-op-attr> </and> </conditions> <actions> <do-set-local-variable name="groupAssociations"> <arg-node-set> <token-xpath expression="empty"/> </arg-node-set> </do-set-local-variable> <do-for-each> <arg-node-set> <token-xpath expression="*[@attr-name='Group Membership']/value[starts-with(string(.),'\customer\CS\AD\')]"/> </arg-node-set> <arg-actions> <do-set-local-variable name="groupAssociations"> <arg-node-set> <token-local-variable name="groupAssociations"/> <token-xpath expression="query:readObject($srcQueryProcessor, '', $current-node, 'Group','')/association/text()"/> </arg-node-set> </do-set-local-variable> </arg-actions> </do-for-each> <do-for-each> <arg-node-set> <token-local-variable name="groupAssociations"/> </arg-node-set> <arg-actions> <do-add-dest-attr-value class-name="Group" name="Member"> <arg-association> <token-local-variable name="current-node"/> </arg-association> <arg-value type="dn"> <token-dest-dn/> </arg-value> </do-add-dest-attr-value> </arg-actions> </do-for-each> </actions> </rule> </policy>
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.