We have an issue where we use the AD group for the entitlement name (we don’t rename the entitlements and don’t make them requestable) but when the AD group gets updated, the entitlement name isn’t changing with the AD group rename. The DN on the entitlement changes as well as it other AD properties, but the actual name is not adjusting.
This is an issue because we run reports to see if all of our AD groups have been added to Access Profiles and we do the linking between the SailPoint entitlement and AD group by the name.
Has anyone else solved for this? Is there a way to update these via a workflow when it’s detected that the DN changed? Or any way to build a basic policy to alert when the group name specified in the DN doesn’t match the name of the entitlement?
Otherwise, how has your organization’s audit organization handled not being able to match the entitlement name in SailPoint to the Active Directory group name? I’m worried our audit team will have a heart attack if they see that they don’t match.
Hi @jwagner3 The Entitlement name is mapped from the sAMAccountName of the AD Group in the default mapping. In your scenario is the sAMAccountName getting updated (I assume not)?
Its set the same – “displayAttribute”: “sAMAccountName”, however if I update the sAMAccountName in AD and run an aggregation, it will pull the data up, but the name of the actual entitlement will not change.
Please excuse my ignorance – Is there an unoptimized entitlement aggregation or is it just done using the account aggregation api and including the disableOptimization flag? I don’t see that same flag on the entitlement aggregation api.
There is no separate unoptimized entitlement aggregation in ISC. To force a full refresh, run the account aggregation API with disableOptimization=true try this.
POST /v3/sources/{sourceId}/load-accounts
SailPoint ISC has 2 types of Entitlement; those that are aggregated during an Entitlement Aggregation and those that are detected during an Account Aggregation
If an Aggregated Entitlement is detected during Account Aggregation the Account will get associated with it
If a Detected Entitlement has not been Aggregated it will be created during Account Aggregation
Detected Entitlements can not be deleted
Once an Account has been Correlated SailPoint ISC stores the linkage between Account and Identity using the internal IDs of the 2 objects
Optimized Aggregation keeps this linkage, ie does not attempt to Correlate already Correlated Accounts
Unoptimized Aggregation breaks this linkage, so attempts (re)Correlation on all Accounts
Hopefully you can see why unoptimized Entitlement Aggregation doesn’t mean anything and why unoptimized Account Aggregation doesnt mean anything in this context
In terms of the OP, renaming an AD Group (DN change) will create a new Entitlement and delete the original, if it was not detected (as I say detected Entitlements cannot be deleted). Updating the sAMAccountName will update the Display Name of an aggregated Entitlement, but if the DN changes at the same time, it will probably be a new Entitlement
We have not found this to be the case. What we have seen is when we rename the group (both SamAccountName and the DN) it is still linking to the existing entitlement, and the DN and SamAccountName both are updating, however the entitlement “Name” as displayed in SailPoint is not being updated – it still keeps the old name.
So the SamAccountName is updated, the CN is updated, but the Value still hasn’t reflected (I’m not sure if this is related to identity processing or not) and the Name shows the old name in SailPoint but the API seems to show the updated name.
needless to say, I am very confused at this point.
Hi Jake. I’m going to step back at this point. I guess that this is to do with the fix I mentioned above, allowing DN and Name changes but keeping the Display Name so it doesn’t break things.
