I’m currently exploring the integration of SailPoint with Active Directory (AD) and I’d like to get some insights regarding SailPoint’s role as an Identity and Access Management (IAM) master.
I have a few test scenarios in mind to determine whether SailPoint functions as an authoritative source in our AD integration:
1.Adding and Removing AD Groups: I plan to test adding an AD group from SailPoint and then removing it directly on the target AD. After aggregation, I want to see if SailPoint reinstates the group, indicating that it is acting as the authoritative source.
2. Business Role Creation and Group Removal: I’m considering creating a business role with multiple AD groups. I will then remove one of the AD groups directly on the target AD and check if SailPoint removes it entirely or if it enforces the addition of the group, again suggesting that SailPoint is authoritative.
3. Business Role Creation and Group Addition: Lastly, I will create another business role with several AD groups and then add a new AD group directly on the target AD. I’ll observe whether SailPoint removes this group after aggregation.
I would appreciate any insights, experiences, or best practices you may have regarding SailPoint’s role as an IAM master in AD integrations. Thank you in advance for your help!
If you add the group via access request of “Entitlement” or “Role” then ISC will re-add it.
If identity has a role in ISC and one of the entitlement which is part of Role, is removed from target system , on next identity refresh ISC will re-add it.
if you add a group directly from target system , ISC will attach it to identity as an entitlement (hoping no AP is created) after aggregation.
Thank you for your insights regarding the integration of SailPoint with Active Directory.
From your responses, particularly the last point, it seems to indicate that SailPoint does not inherently adopt the behavior of an IAM master. I would like to understand if there is a way to enable this functionality or if there are specific configurations that can be implemented to ensure that SailPoint acts as an authoritative source in managing entitlements and access requests.
Your guidance on this matter would be greatly appreciated!
Hi @s_tartaglione , regarding your last query. Seems this is a contradiction(If I understood it correctly), you are creating role with AD groups in SailPoint and you are adding AD group to an account on the target system. Here the added AD group will get attached as just an entitlement to user. So you will not find this AD group in the role even after aggregation which is the know behavior of SailPoint.
You should explicitly add the AD group into the role in SailPoint.
Hi @JackSparrow ,
but what for this particolar scenario:
I have a target source Entra ID and some Entra ID groups as Entitltment aggregated.
My Entra ID account has group1 and group2 and is aligned between Entra and Sailpoint.
Someone “illegally” adds the groups3 to my account directly on Entra ID.
If I perform an aggregation on Sailpoint I see the group3 linked to my Entra ID Account.
Is there a way to force (by Sailpoint) the removal of the group3 illegally added directly on the target?
Because if Sailpoint is master, every new add group request must pass by Sailpoint (that have some approval steps).
Hi @ffalcitelli ,
SailPoint will not be able to detect and remove the access that is being explicitly added directly on the target. SailPoint will have only read capabilities while aggregating the data.
@JackSparrow You wrote that Sailpoint “will have only read capabilities while aggregating the data”.
But in the opposite case, if the access is being explicitly REMOVED directly on the target, Sailpoint will re-add the access at the first aggregation. So, Sailpoint has not only read capabilities during the aggregation. Right ?
It could just be the order of operations causing confusion. If SailPoint reads an account from the target, and an entitlement that is granted by a role is missing, a separate provisioning event will take place that adds the entitlement.
If the concern is around an entitlement that was added out of band, then it sounds like Native Change Detection might be a solution.