Hi Experts
I need help or Guidance on how to achieve the above Filter.
I want to exempt a specific OU so that i can use it in another Source(Admins) but i need to exempt it from the Primary AD source.
OU=Administrator Accounts
OU=Users
OU=Disabled Users
I have added the filter
(&(objectCategory=person)(objectclass=user)(!(msDS-parentdistname=OU=Administrator Accounts,DC=myhome,DC=com)))
but it still seems to be getting all the users.
I tried resetting the source but i think that is Blocked.
Hi @MVKR7T
Had thought of this but i have several OU’s and several subdomains was thinking in reverse I add all and exempt rather than add what i need. Thank you any idea what the Max number of scopes is?
Let me Explore this and advice.
Hi @peter_muchangi I also second to @MVKR7T , you can define OUs one by one in the AD source config. I verified this with SailPoint support, currently they say no limit.
We also had similar challenge wherein we defined each OU that we want to aggregate the accounts from separately, and for the exclusion part - we used the search filter.
It may be better to use a field to set a value saying if the account is a user account or an admin account.
for instance using “adminDescription” native field you can fill it with “user” / “admin” and then define this attribute as filter for both your user source and your admin source.
Better than using OU that may change and you can also use that attribute later on to do report by account type.
You can also extend that mechanism to groups (using same attribute) to filter them per source, avoiding to have entitlement duplicated on sources uising same active directory domain (don’t forget to set the filter on user group membership as well to not have entitlement being loaded without knowing why !).
The purpose of containers (OU) in AD is to maintain accounts in a proper hierarchy by grouping the users based on organization requirements.
If you have different type of objects say servers, computers, printers, normal account users, admin account users then it doesn’t make any sense. I would say your AD is messed up.
I would say better to go with separate OU instead of applying filters. Apply filter only if you don’t have a choice. That’s my approach.
I don’t deny that, but when you have multiple OUs across your domain to contains user accounts with different path, then having an attribute to describe the account type is a good thing to have.
In case you need to move OU or create a new one, then you have to work on all the sources to refine the filter, if you’re using attribute then no need.
The attribute can be fill by IDN during creation, so this is not a big deal, just a different way to see things when you have tens of thousands of accounts in your domain including tens of OU !
Teach me Master.
My Real issue is that Users(admins) have 2+ accounts on source AD thus they cant apply for AD specific Roles.
I tool the approach to have 2 sources
AD source and Admin AD source.
is the field in AD or on IDN
@peter_muchangi That’s fine Peter, handling the mess environment is what the real fun rite. May be give some specific insights about your requirement (you can change your data to test data), so that I can give you filters for them.
The field used is a field on the active directory side, to store it on all the accounts, either you reuse existng one that you don’t use today (most of the time adminDescription field is not used) or you define a custom field extending the AD schema (pay attention : this is not reversible).
We have same issue and we have created one source for users and one source for admins (we have even more types of accounts but I won’t enter into details).
Then you just need to put this filter on user source : (&(adminDescription=user)(objectClass=user))
If you want to fill the field using IDN on account creation then you’ll have to add it in IDN in your source using “Account Schema” from the tab “Import Data” and configure it from the create account profile…
Peter K. Muchangi reacted to your message: