At some point we were discussing if it would be possible to synchronize user account based on group membership using the default procedures of Oracle Identity Management.
The idea is to sync as little user accounts as possible to our Oracle Internet Directory where the user accounts are spread over a width range of Active Directory containers were different policies apply to. Not all users in these containers need to have access to the Oracle applications which are integrated with the Oracle Identity Management.
So by granting a user a special group priviledge (soa) in Active Directory it should be synced to Oracle Internet Directory. Other users should not be synced as they are not part of this special “soa” group. When this grant would be revoked, the user account should also be deleted from our Oracle Internet Directory.
Case1 :We are synchronizing all users from Active Directory to Oracle Internet Directory.
When we use a basic searchfilter like :
searchfilter=(&(objectclass=user)
We get all users added and deleted in AD to be processed in OID. This works.
Case2: We are synchronizing based on Group membership.
We use this searchfilter :
searchfilter=(&(objectclass=user)(MemberOf=CN=soa,OU=groups,OU=nieuwegein,DC=iteye,DC=nl))
Users are added to our OID when they straight away are added to the group “soa”, before the sync ( odi ) checks the changes.
In the scenario when the user is added, the sync runs , the user is granted to the “soa” group. The sync will not add the user anymore.
Deletions are not preformed anymore.
Case3: We are synchronizing based on Attributes, we use the displayname attribute as a trigger to sync or not sync our user.
We want to perform this test to see if we could use an attribute ( for example : displayname ) which would indicate this “group membership” by setting a value 1 in it.
We use this searchfilter :
searchfilter=(&(objectclass=user)(displayname=1))
We get only users added which have the displayname changed to 1. No matter if the User was created and adjusted the displayname within a synchronizing period. So in the scenario when the user is added, the sync runs , the users displayname is changed to 1. The sync will still add the user.
Deletions are not preformed anymore. We are not able to delete ( in case 2 and 3 ) or backfill a user based on groupmembership ( case 2 ) After some research we can see in MSDN the description for the memberOf attribute for an AD user:
—————-
memberOf
The memberOf attribute is a multi-valued attribute that contains groups of which the user is a direct member, depending on the domain controller (DC) from which this attribute is retrieved:At a DC for the domain that contains the user, memberOf for the user is complete with respect to membership for groups in that domain; however, memberOf does not contain the user’s membership in domain local and global groups in other domains. At a GC server, memberOf for the user is complete with respect to all universal group memberships. If both conditions are true for the DC, both sets of data are contained in memberOf.
Be aware that this attribute lists the groups that contain the user in their member attribute—it does not contain the recursive list of nested predecessors. For example, if user O is a member of group C and group B and group B were nested in group A, the memberOf attribute of user O would list group C and group B, but not group A.
This attribute is not stored—it is a computed back-link attribute.
————–
http://msdn2.microsoft.com/en-us/library/ms677943.aspx
Now, this means that when you add a user to a group in AD, AD is just modifying the group not also the user itself. Going forward with this, that means that uSNChanged is updated only once.
The ODI server is reading the uSNChanged value and runs a search against the AD to retrieve the last changes. Here it will find only the group has been changed. The filter for the change will be formed:
(&(uSNChanged interval)(our_custom_filter))
So, for both cases 2 and 3, we will need to take some actions on the user when the group is changed which is not possible with ODI. ODI works on an entity level (that means the mapping files are applied , and actions are performed only on the entity detected as changed).
For case 3 you will not be able to delete a user when an attibute is changed as deletes are searched from a special DeletedObjects AD container. A user is not added in this DeletedObjects AD container when you change in our case the displayname attribute.
However, we could , as a partial solution create a OID plug-in that will fire in a post-update LDAP operation on the specific groups. So, if a user is removed from a group, after the synchronization runs, it will trigger the plug-in. In the plug-in code we should be able to identify the user that was removed and delete it from OID.
But this means we need to extend the possibilities of the default procedures available in Oracle Identity Management.
Our conclusion at this point is that it’s not possible to sync based on group membership with deleting and / or backfilling users working using the default procedures of Oracle Identity Management. However there are possibilities to write your own plug-in for Oracle Identity Manager to do a post-update operation on your user store ( OID ) to keep it clean and up to date.




