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.
There’s already an idea looking to address this. I know @ccarlton @jroozeboom have discussed it before, so it’s not a new thing
As documented in GRAPH API if you made a request for GET https://graph.microsoft.com/v1.0/groups?$onPremisesSyncEnabled eq Null&$count=true
and in the header you add ConsistencyLevel=eventual you would be able to retrieve this groups.
And following the ISC documentation if you edit your connector with
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:
supportsAdvancedAccountFiltertrueAnd 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.
Let me know if works.
What happens when you aggregate accounts that are members of the groups you’re trying to exclude from the entitlement aggregation?
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
in ISC i see now ay of doing it
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.
Sim, infelizmente não tem como colocar rule ou filtro quando o Now começa a agregar os grupos do usuário.
Então , isso eh uyma coisa ruim do conector , vc vai puxar os objetos on premise.
talves algum filtro escondido. Abre um ticket com a Sailpoint
@coelhoya2 Maybe you can use the aggregation filter?
Click on advance and try to filter the dyrsync attribute
This would work for group aggregation but the onprem entitlemenst will be created as is going to be listed on account aggregation.
Tenta criar o mesmo filtro para contas, sabe?? Acho que rola.
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.
Entitlement MEMBERSHIP Aggregation Filters | SailPoint Ideas Portal
@colin_mckibben , any updates here? We continue to be blocked by SailPoint not being able to understand that some entitlements showing up in a source should not be listed/managed in SailPoint.
We do not want an AAD Source bringing AD entitlements and have no way of configuring SailPoint to prevent this.
This is starting to impact our ability to use ISC, raising costs / effort in using it, etc.
Has anyone engaged SailPoint professional services about this topic? They are far more knowledgeable about these things than I am, and they may know more about any workarounds or may be able to help prioritize this feature.
We have contacted our CSM about this, and they are asking internally (CAR-2837). We don’t want to burn hours on this as we have read others have done so without resolution.
(This is from the last bullet in the URL list below: “Don’t bother opening a ticket to SailPoint support they’ll have no idea how to resolve. We wasted 15 billable hours on this and no one could solve our problem…”)
If our CSM comes back with something viable (like professional services has a solution we can buy for this issue, or if we manipulate the platform in some particular way, I’ll definitely share that info with others so they can go the same route…
Here’s my running list of URLs on this particular issue, in case people are also tracking this:
To add to the general topic of entitlement filtering, we were expressly told by Advisory Services that post-hoc modifications to source entitlement filters can cause issues. (IE don’t make changes to filters if you’ve already aggregated the source).
With that in mind, any solution we brainstorm is tempered with the concern that we may only get “one shot”.
This gives us trepidation for both AAD and Service Now. Our Microsoft reps are recommending Azure Identity Governance which also offers group-based approvals. Hopefully this gets addressed soon.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
