Hello. Question
Is it possible to filter out on-prem AD groups from our Azure source? I imagine that the “DirSyncEnabled” would be leveraged, but am not sure how to syntax the filter
Context
We are a hybrid on-prem/Azure enterprise. We have a 1-way sync on-prem to Azure. On-prem groups cannot be managed in Azure. We aggregate both sources. The sync’d groups are appearing twice.
If you’re using the advanced filters you must add the supportsAdvancedAccountFilter attribute to the source XML using the IdentityNow REST API. The connector will then automatically add the required header (ConsistencyLevel:eventual) in the header and add &$count=trueFor example:POST https://{orgName}.api.identitynow.com/cc/api/source/update/{source ID}In the body of the POST, use the form-data as follows:
Key: supportsAdvancedAccountFilter
Value: true
And you will need some of these permission: Directory.ReadWrite.All , Group.ReadWrite.All , or Group.Read.All , along with Directory.AccessAsUser.All .
You should be able to accomplish what you are looking for, i never tested(going to in nexts days) but should work.
I am not sure. Bottom line is that whatever we sync from on-prem is not operable since it’s a one-way sync. Changes can only be made to the on-prem entitlement. The end goal would be to declutter our UI and not waste the cycles aggregating them.
I was more asking @coelhoya2 because I’m fairly certain even if you do the filtering on your entitlement aggregation, entitlements for on-prem groups will be created as part of the account aggregation process, assuming any accounts that are aggregated have membership in on-prem groups
Ye, i let pass that. From what i can see ISC do a parent endpoint aggregation. List all user and then he gets https://graph.microsoft.com/v1.0/users/user_id/memberOf and here we would do the filter, but as we can’t deploy a rule or edit this operation there’s nothing we can do.
Yes. As people have noted, ISC is ‘discovering’ these read-only replicated entitlements via account aggregation. Filters applied in the source configuration are NOT being used, so these replicated entitlements do show up in ISC (mostly visible in certifications and Access History).
We see this scenario in Azure Active Directory, as well as ServiceNow (which replicates our AD Groups into SN).
As noted in the first reply, there is a user voice voting item on this issue, and if your organization is also being hindered by the lack of filtering entitlement capability, I recommend you go vote for it.