Hi Team, Two AD accounts created for one user, one is Active and another one is inactive. The active AD account does not have mail, UPN and few more attribute values were missed. Disabled account have all attribute values, email also picking from disabled account. How to resolve this issue, Can we delete the disabled account and add missed attributes to the enable account? please suggest.
Based on your description, this appears to be more of an account correlation or identity attribute promotion issue than an AD provisioning issue.
Since the identity has two correlated AD accounts:
The active account is missing attributes such as mail and userPrincipalName.
The disabled account still contains those values, and ISC is promoting attributes (such as email) from that account.
I would recommend checking the following before deleting the disabled account:
- Verify that both AD accounts are correlated to the same identity and identify which account ISC considers the primary account.
- Review your Identity Profile attribute mappings to determine which account is being used to promote identity attributes like email.
- Check the AD source aggregation to confirm whether mail, userPrincipalName, and the other missing attributes are actually present on the active account in ISC.
If the active account should be the authoritative account, update the missing attributes in AD (or provision them through ISC if applicable), run an account aggregation, and then perform an Identity Refresh.
I would not recommend deleting the disabled account until you understand why ISC is sourcing identity attributes from it. Deleting it without resolving the correlation or attribute mapping could lead to unexpected identity data or provisioning issues.
Could you also confirm:
Is this a single AD source or multiple AD sources?
Are both accounts correlated to the same identity?
Is the mail attribute configured as an identity attribute in your Identity Profile?
Hi Sowmya, We have single AD source, and both accounts correlated to the same identity. Email_address work is configured as identity attribute in identity profile. I have previewed the identity in identity profile it will pick the disabled account email.
Hello Ravikumar, @ssowmya567 covered the foundational checks well.
ISC is picking the disabled account because when there are multiple accounts on the same source, it defaults to the oldest account (by created date) for attribute values. Your disabled account is the older one, so that’s where the email is coming from.
To fix this, update your identity profile mapping for email (and any other attribute coming from AD) to use an accountAttribute transform with accountPropertyFilter. This tells ISC to only read from the enabled account:
{
"type": "accountAttribute",
"name": "Get Email from Active AD Account",
"attributes": {
"sourceName": "Your AD Source Name",
"attributeName": "mail",
"accountPropertyFilter": "(IIQDisabled != \"true\")"
}
}
Do the same for UPN and any other attributes that are pulling from the wrong account.
Also, make sure the active AD account actually has those missing attributes populated in AD itself. If mail and UPN are blank on the active account, the transform won’t have anything to pull even after filtering.
Once both are done, run aggregation and process the identity. Preview again and you should see it pick the right account.
it is happening due to identity refresh is happening 2 times if you open a SailPoint ticket they will turn on feature flag
Hi Chaitanya, Already opened SailPoint case for this issue. Let me check.
Is Active Directory your authoritative source, or is it just a target for provisioning?
I’ve seen this happen when an account exists in AD and is disabled, then an identity comes from your HR source that should correlate to the existing AD account, but the AD aggregation hasn’t run yet. Then by policy the identity should have an AD account, so ISC creates one. Later, the existing account gets correlated when aggregation completes.
The missing attributes are a result of the directory rejecting non-unique attributes. For example, UPN must be unique across the domain, so if your provisioning plan would put a UPN in the new AD account that is already in the existing account you will see errors on the account create with wording like “constraint violation”, or something like that.
Hi @ravikumar7284 Are you able to ascertain which of these accounts was created by ISC and which (if any) were created “out of band”?
Also, has the user logged into either?
Briefly, I would say determine which one needs to be kept and then fix issues in AD (and potentially exchange), then delete the account that isn’t needed (from AD).
However, this can be a tricky scenario and should be done with requisite knowledge of AD.
Hi @ravikumar7284 Before deletion of either AD account you can try the below options:
1.Run a Full (Non-Optimized) Account Aggregation- This forces SailPoint to scan every record, notice the disabled account is gone, and remove its stale record from ISC.
2.Review the Identity Profile Mappings-Verify that your identity Email attribute is cleanly mapped to the AD technical source schema attribute mail (or your primary HR source where email originates).
3.Trigger an Identity Refresh-Sync Attributes to instantly refresh their cloud profile with the correct, active AD data mappings.
Hi @Deepak_Chaudhary why an unoptimised aggregation? Without knowing the OP’s correlation setup, there is no guarantee that either will be removed. Even if the disabled one was removed (unlikely as the identity has picked the email address from it)that will leave the OP with an orphan account. If the enabled one remains correlated, that is the one without email or UPN, so it will still need fixing.
Hi Harish, Why its not picking the email from enable account was the enable account does not have mail, UPN values populated. So that disable account have those it will be picking from that account.
I can see one difference Provisioning Policy: “name”: “ObjectType” and Schema: “name”: “objectType” Case sensitive causing this issue. IIQ Disabled present in Provisioning policy and not in shema.
Was this answer meant to be on your other topic?
You can simply delete both accounts on ISC and rerun the target aggregation. It will likely solve the issue, or at least show you where the issue really is
Hi @Pratyush27 I take it you mean ‘remove’, rather than ‘delete’?
I’m interested, how do you think this will solve the issue or show what the issue is?
At the moment, we haven’t even determined there actually is an issue: all we know is there are 2 accounts in AD and they are correlating to the same Identity,
I do mean remove rather than delete.
Working on the assumption that the source has a working correlation rule and the disabled account is not manually correlated, if OP deleted one account in the source, updated the other with the required details and both were removed from isc, the correlation rule should fire similarly for the one remaining account and fix the issue
Ah, ok. So you’re saying fix the AD accounts then run an aggregation (I think we’re agreed on that). Still not sure why you would need to remove the accounts from ISC, unless the OP hasn’t enabled Account Deletion on the source, something which he hasn’t mentioned.
Indeed, I am supporting the fixes mentioned in the original post. About account deletion, they haven’t but I have also encountered this issue when the DN changes on the target and SailPoint gets confused which is the real account. With account deletion disabled (or limited), it might be the case that the account isn’t removed after the fixes. Removing both from ISC gives you a more “clean slate” approach and is usually a faster a resolution and avoids rolling problems if the above assumptions are incorrect
