Hi everyone,
We’re facing a situation where we have an identity with multiple creation attempts in Active Directory, but the identity already has a correlated account, and yet ISC keeps trying to create it.
Do you have any idea what the problem might be?
it is attempting in the sense, let us know little bit more
@henriqueoliveira2026 IS the AD account already linked in the Accounts page ? If it is already linked. Can you please share the error that you are getting.
Could you please share when it is attempted, like events ?
These will happen if you have 2 ad sources
How many AD Sources you have ??
I have three Active Directory sources; I’m searching within the functions.
one of the criteria is matching so it is attempting to create ad accounts check the criteria Correctly
Can you show the correlated account on the cube?
Do you have any aggregation filters on your AD source that might be excluding that account from being pulled in?
The linked account above appears in accounts on the source do Active Directory
If you have more than one AD source, the role or lifecycle state that’s triggering the creation might be pointing to a different AD source than the one the account is correlated to. ISC would then see no account on that specific source and keep trying to create one.
I agree, that’s what I’m looking for to see if I can find it.
Can you check which AD source the entitlements inside the role are coming from? Since you have multiple AD sources, the issue might be that the identity has an account correlated to one AD source but the role is pointing to a different one?
That ENTRY_EXISTS / 0x80071392 means AD already has an object at the exact DN your create profile is trying to write. Even with the account correlated on the identity, if the OU/CN your account profile generates doesn’t match where the object actually lives (moved, renamed, or wrong OU in the profile), ISC sees “nothing at this DN” and fires a Create — AD then rejects it. Compare the linked account’s distinguishedName against the DN your create profile would build for this identity; that’s almost always where the mismatch is.
I’ve noticed this as well — the way SailPoint constructs the DN differs from how it actually appears in Active Directory. Some identities show this discrepancy, but in these cases, the creation attempt doesn’t even occur, while others do present this issue.
Hi Henrique,
Any chance someone has been moving AD accounts to different OUs directly on AD? Depending on the access on the account and how it was granted, SailPoint might be trying to re-provision the account to the original OU. A ‘sticky entitlement’ scenario: Sticky entitlement - #3 by chirag_patel
I’ve addressed this in the past with a native change detection workflow
For another thought. Have you tried setting your search DN at the lowest level.
Is it possible that you are creating the account in an OU that ISC is not permitted to look into
