Hello All,
Have there been any recent problems with the Active Directory connector?
We’ve encountered a situation where IDN is failing to update Active Directory user accounts if the Distinguished Name of the account was modified externally (outside of the IDN system). Even after running the account aggregation process, IDN continues to use the old DN when adding or removing users from AD groups via roles.
Thanks,
Sushant
Hi @Sushantmr
Welcome to SailPoint developer community.
Can you identify some users and check their account, if it still has old DN or new DN.
Thanks
Krish
The accounts have new DN and the role assignment fails each time the identities are refreshed.
If you run a full aggregation(not delta), IDN should be able to pick up the new changes to DN. Maybe the roles are trying to provision before this aggregation is complete.
Have you seen the new DN getting updated in IDN at any time or it’s not updating at all?
I ran a complete aggregation (not a delta) and see that the new Distinguished Name is reflected in both the Account ID and distinguishedName attributes within the Active Directory source account. Additionally, the value in the identity attribute has been updated, yet IDN is still using the old DN for the group assignment.
I’ve seen similar unexplained behavior related to the update of a DN and generally running a NON-Optimized aggregation (via the API or VSCODE extension) has corrected things.
We are seeing similar behavior. I opened a case but keep getting asked what we changed (which has been nothing). I have multiple examples where updates to AD are failing because Sailpoint is trying to write to an old OU that the identity is no longer in. Our issues appear to have started around 10/3/23.
That’s intriguing. We first noticed the problem on 10/04/2023.
Furthermore, I opened a support case and received the following response:
"Because we are using the DN as a unique Identifier this sometimes has happened. According the the article this is really the only way to fix the issue:
OU moves done directly in AD (outside of IDN) are not supported as it can lead to the scenario described in the problem statement. Instead, it is recommended to initiate account moves from within IdentityNow as described here https://community.sailpoint.com/t5/SaaS-Updates/Real-Time-Active-Directory-Account-Moves/ba-p/233005
As an alternative, in order to clean up the reference to the original DN, you may move the account back to the original OU temporarily, and then revoke the entitlement via API.
Note: You’ll want to make sure the request is of type REVOKE_ACCESS
Once the entitlement is revoked, you can move the AD account freely."
Have you tried a non-optimized aggregation? This should ensure the moved account re-correlates to the identity and once this happens IDN can manage it again.
SailPoint’s message is consistent that OU moves should take place in IDN in order to utilize a recent fix:
Connectivity (CB-DIR 6.1 ) - Active Directory
CONETN-4261
The Active Directory connector now instantly returns the Resource Object to IdentityNow on any OU changes done by the AC_New Parent, which can be further utilized to any rule to work with the updated Resource Object data values.
Totally understand that’s the “message”, but unfortunately in the “real world” things aren’t ideal and accounts get moved out of band for a variety of reasons.
We finally got to this point in our support case, sharing in case it is helpful for anyone else running into this issue:
Hello Carmen,
We observed this issue for multiple customers and our DEV team is working on [IDNARSENAL-20294] it with HIGH priority.
During the investigation we found one Feature Flag which was set to true on Oct 2nd and since then this issue started, but again they are looking into it and trying to find out what exactly the culprit here.
Please bear with us, we’ll keep you posted.
Jut found myself here after a lot of googling this is the same experience we are having as well. I have opened a support ticket already but this seems to be the same problem i started seeing this week as well. old DN is being used to try to modify something that according to sailpoint is already updated and accurate.
Unoptimized aggregations do not resolve it as I would expect either.
We found a potential fix/work-around for this issue. Removing the Feature flag “PREFER_UUID” from the Active Directory source features allowed at least some moved & renamed accounts to be processed.
I am also experiencing this issue. A non-optimized aggregation did not fix it for me either.
I’m also getting a similar line about how we shouldn’t be doing DN/CN changes outside of the tool (which @edmarks has correctly pointed out is impractical in the real world)
I’d like to verify that you are saying that you’ve had accounts that did not undergo the mover process from IDN but instead had their DN’s changed outside of IdentityNow and are now failing to have provisioning complete correct?
If so, I’d like to explain that IdentityNow uses DN as a unique immutable value. Within the design of our connector at the moment, if the DN has been changed without undergoing the mover process, we will have issues re-correlating to the account as it is our only means of recognizing the account and where it’s located in the Domain controller.
The Sailpoint best practice doc for AD account moves states they DO support OU moves outside of IDN:
In the identities where we are seeing this issue, the DN on the identity attributes is always correct but IDN is trying to write to an entirely different OU.
Kevin’s reply is what worked for us yesterday, him and I were looking into how to work around - and removing the feature flag allowed the attribute adds or new information to properly sync, I do think this feature flag is not working as intended at present.
@ndanjou did you have to do anything after removing that feature?
to clarify, we’re talking about “PREFER_UUID”, correct?
Removing “PREFER_UUID” seems to have fixed for me so far.
