I know this isn’t best practice, but some of our higher ups are worried about giving SailPoint full access into our AD environment. They are asking if we could set up some specific OUs as “read only”, as we have a lot of regulations around those OUs. Some of those OUs have service accounts and admin accounts, as well as groups.
From an ISC perspective, this is going to cause a lot of issues. Certification campaigns will still show those entitlements but they will be un-revokable, it might try to remove accounts in those OUs, in general, it’s going to be rough.
Is there any native support for read only access to accounts or entitlements, like kicking off a workflow if someone tries to revoke one of these entitlements? Or has anyone had to deal with this?
If they end up not giving us full write access, we may just have to filter those groups and accounts out and never pull them in, but it is preferable to at least have some auditing on those accounts, if possible.
OU ACL…don’t think it’s the Microsoft ‘recommended’ way these days…but it does give you that finer grain control.
This is an authorization concern, best to pull in an AD SME to see how they would like to tackle this. i.e. The target system owner / SME determines how to authorize the service account to manage their accounts. IGA doesn’t own the authorization model on target systems. IGA / ISC is a user / consumer of the service account.
Historically, ACLs in the AD tree can be very complex to manage, to scale well. There’s specific tools for managing ACLs…like this:
The AD SME may already have an existing framework / practice on how they want to go about this.
Recently we have an issue with the IQ service regarding a specific OU, we can read the OU accounts and group but we cannot do any provisioning action , so maybe it’s possible to configure the permissions of the service account and not give the admin permission.