Account ID for Active Directory

Identity Security Cloud (ISC) ISC Discussion and Questions
1

I know that Sailpoint recommend using the DN for account ID in the Active Directory schema, I would like to know the downside to using the GUID instead (or sAMAcccount).

The reason I ask is that our client has the situation where the DN will change regularly for large number of users (+50,000), moving in and out of a transitional OU. The AD account is to be provisioned as a birthright via LCS, and I fear that it will become uncorrelated during the move (and the full aggregations), thus causing 1000’s duplicate accounts to be created.

Many thanks for you thoughts,
Phil

2

We are using DN as Account ID and we do move accounts from one OU to another. We didn’t face any duplicate issue.

I don’t think there will be a problem in changing the Account ID attribute though SailPoint recommends to not to change, technically shouldn’t be a problem.

Thanks
Krish

3

I am not clear on the the downsides of using GUID instead of DN as this is something I didn’t want to mess around with, but the AD Connector documentation states, “If you update these attributes (Account ID = distinguishedName) from their default values, the connector may fail.” I don’t know exactly what could happen or how this will fail though.

You may have already come across this article, but I figured I would add it in case you haven’t seen it. It talks about how to handle OU moves and updating the DN by using Identity Attributes or the Before Provisioning Rule. If you are looking for these OU moves to be handled by IDN, these might be some solutions that can help in your case.

If the intent is to move accounts but not have IDN perform the action, it might be best to plan for them to occur before a full AD aggregation is run in IDN (or run a full aggregation after) to minimize the risk of account updates not succeeding.

Thank you,

  • Zach
1 Like
4

It’s just the way that SailPoint has implemented their source is what requires the Account ID to be the DN instead of GUID. I’ve mentioned this already a couple of times and we’ve also seen that there is an idea on the ideas portal for this already:
https://ideas.sailpoint.com/ideas/GOV-I-2129

The moves while using DN work because ‘recently’ they’ve implemented this:
https://community.sailpoint.com/t5/SaaS-Updates/Real-Time-Active-Directory-Account-Moves/ba-p/233005

In the past this could give some issues when trying to provision after a move, but nowadays no longer.

2 Likes
5

Follow-up question. Are we able to sync the DN if we sideloaded that attribute via the API call, or would it have to be done via a BeforeProvisioningRule?

Thanks

6

Some of the downsides of using GUID are worse UI (some areas don’t use display attribute, only the unique identifier) - e.g. in some OOTB reports and UI pages.
Moreover, it can cause issues down the line if you’re doing custom development. I’ve previously encountered that certain common features will not work. An example is making a “special account request” quicklink. Implementing in the usual scalable way (pass a flag then utilize application provisioning policy to react on that flag) caused major issues in AD apps. When analyzing with SailPoint, we realized the GUID unique identifier was the root cause. There’s some stuff deep in the connector which only works with DN.

7

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.