We have a use case in which, when a password change occurs within an AD domain, it is replicated to another AD domain. In this case, we would have two AD connectors within ISC.
The initial idea is to use the Password Interceptor service to detect and send the password change to ISC, which would then forward it to the second AD connector.
Does the password interceptor work this way, or is there a better way to handle this situation?
Is it possible to avoid using it if both AD domains are on the same ISC connector?
I understand that the Sync Group module synchronizes passwords when the change is made from the ISC Password Manager, but it would not synchronize the password if the change originates from the domain controller itself. Is that correct?
Your instinct about the Password Interceptor is correct, and Sahil’s pointer to Password Sync Groups is the other half of the puzzle. You would need both pieces working together to cover this end to end. Here’s how I would break it down for two AD domains:
Each AD domain needs its own source in ISC (you can’t combine two separate AD domains into a single connector), so that part is set. Once both AD sources are in ISC, you would create a Password Sync Group containing both of them. This should handle any password change that happens through ISC (Password Manager, access requests, etc.). When a user changes their password on one source through the ISC UI, the sync group pushes that password to the other source. This part is pretty straightforward.
But that only covers changes made through ISC. If a user does Ctrl+Alt+Del on their workstation or resets their password directly in AD (which is what happens most of the time), ISC won’t know about it unless you have the Password Interceptor installed on the Domain Controllers.
Now here’s the part I would be careful about. The docs say that when the source is part of a sync group, the Password Interceptor will change all associated passwords in the group “except for AD.” The example they give is a sync group with AD, Oracle, and Google Apps, and the interceptor syncs Oracle and Google Apps but not AD. It says “except for AD” as a type, not “except for the originating AD source.” So in your case, where both sources in the sync group are AD, it’s worth checking whether the interceptor-triggered sync will actually push the password from Domain A to Domain B, since Domain B is also AD. The docs don’t really cover a two-AD sync group scenario specifically.
So what I would suggest is to set up the sync group with both AD sources and the Password Interceptor on both sets of DCs. Then test the native AD password change flow in a sandbox first (change password natively in Domain A, check if it reaches Domain B). If it doesn’t propagate, I’d reach out to SailPoint support to clarify whether the “except for AD” exclusion applies per-source or per-connector-type. For ISC-initiated changes through Password Manager, the sync group should work without any issue.
One more thing, make sure the password policy on the sync group satisfies both AD domains. If Domain A and Domain B have different complexity rules at the AD level and the sync group policy doesn’t align with both, you could run into failures on one side
Thanks for the reply.
I’m going to enable the Sync Group and check with Sailpoint support to see if it’s possible to use the Password Interceptor in this case, since the documentation isn’t entirely clear on whether AD is an exception.