Hi All,
I would like to give some clarity on the User and Group search scopes in Active Directory Configuration. It looks easy and straight forward. But many times people got lost and got confused. I will try to explain with an example and will remember forever. Feel free to add or update with the comments if required.
While we are onboarding the Active Directory application, it is mandatory that we have to specify the Account section if you want to pull or aggregate the users from AD. Account section means simply, which users from which container you are interested to pull into SailPoint, which is called the User Search Scope.
Let’s talk about the User Search Scope first.
User Search Scope
User Search Scope is used for specifying the kind of users you are looking for aggregating into SailPoint. It basically contains four options (Search DN, Iterate Search Filter, Group Membership Search DN, Group Member Filter String), as you can see in the screenshot.
Search DN:
This one is used for entering the distinguished name of the domain, or OU, that defines the scope for the users. Meaning, I am interested in pulling/aggregating the users who are under the specified containers.
Now, I am giving one DN, which is OU=Asia,DC=kbp,DC=com (I have built my own AD setup).
Now, let’s run the account aggregation. and see the result.
We have a total 12 users under this container. Those 12 users aggregated in SailPoint.
Now, let’s add one more container (2 users are there under OU=Australia,DC=kbp,DC=com) and see the results. (Note: we can add more than one container in the Scope)
Run aggregation and see the results. All 14 users are aggregating successfully
By this, we can conclude that SailPoint will aggregate the users who are under those containers we configure only.
Iterate Search Filter:
Specify an Iterate Search Filter string to limit the results returned by the search DN. Meaning, for every object there will be an objectClass attribute available, which is a component of the Active Directory schema that defines the “type” for an object, or, in other words, it defines the set of mandatory and optional attributes an object can have. Iterate Search Filter configuration is an optional.
In the above diagram, you can see objectClass as top/user/person/organizationalPerson. Like this, we can custom objectClass as well.
For now, I am interested in aggregating users only if objectClass is user. Let’s configure it.
Run account aggregation and see the results.
All 14 users are having user objectClass. So, aggregated all 14 users.
For better understanding, let me add one custom one like ipUser as objectClass and see the result.
You can see the above task results that indicates two links have been deleted because while SailPoint is aggregating users from OU=Australia,DC=kbp,DC=com, it did not find the users who are having custom objectClass is ipUser. That’s why SailPoint has been filtered out them, not pulled into SailPoint. Later, I have enabled an option called the detect deleted accounts option in the account aggregation task. So that it deleted whatever two accounts were there previously from the domain in the SailPoint.
Group Membership Search DN:
Group Membership Search DN to determine the group membership of the users that you are loading or aggregating. You can have multiple entries by seperating with a semicolon. This is also optional. If the Group Membership Search DN attribute is not defined, then the connector brings all the group memberships associated with the respective account, which are returned by APIs instead of falling back to the scope defined by Search DN.
Let’s configure and test it.
What I am trying to do in the above is pull the users (their objectClass is user) from both OU=Asia,DC=kbp,DC=com and OU=Australia,DC=kbp,DC=com and also add the membership for the users if those are part of the groups that are under OU=North America,DC=kbp,DC=com. Otherwise, don’t add the membership.
The result is, aggregated all users from both domains with objectClass user. But if you check those users’s memberOf (memebership) attributes, you won’t see them because we don’t have any groups in the OU=North America,DC=kbp,DC=com.
No membership for the users from the DN.
Now, let’s add another DN (OU=Australia,DC=kbp,DC=com) that contains groups. In those groups, the few users are part of it. And, test it.
Users in the group which is under this DN
The above result is that for those four users, membership has been added (Identity Entitlements Created). You can check the users.
For the rest of the users, it was not created because those users are not part of the groups that are present in the DN.
You can also have root DN so that all memberships will get. But it depends on your requirements.
Now, Group Member Filter String
This is also optional. Specify a Group Member Filter String as an LDAP search filter string that applies while fetching the user’s group membership. Meaning, whatever the last step has done, it will apply the filter you mentioned (objectClass=group) for those memberships.
If the filter is not matched, then membership won’t be added to the accounts.
I hope it is clear so far.
Let’s talk about the Group Search Scope.
Group Search Scope
In this Group Search Scope, you are telling SailPoint to read and aggregate the groups that are from the specified DNs.
Note: By default, if the scope is not defined for groups, the connector uses the Account search scope. That is the reason you could have seen the groups for those 4 users in the above example.
Now, let’s add the DNs (OU=Australia,DC=kbp,DC=com and OU=South America,DC=kbp,DC=com) along with the filter as objectClass is group (this is also just like the account scope as explained above).
Now, run the group aggregation.
Check the group.
Check the user memberOf attribute.
I hope you learned something new and enjoyed reading this; please do a like if you do so. Thank you, Happy Learning.