Generate unique sAMAccountName even after deletion in AD

Hi all, we have a requirement where the old sAMAccountName should not be used again even after the deletion of this old account in the AD system itself.

Basically we are having similar use case as discussed in the post below, but one issue is that we do not have the sAMAccountName stored in the HR source.

For example,
User A: dummyuser
User B: dummyuser1
User C: dummyuser2

So, before User D is onboarded, User B is offboarded and disabled in IDN, and will be deleted in the AD target system after 30 days.

After 30 days, User D is onboarded. Instead of having the sAMAccountName “dummyuser1”, it should be “dummyuser3” instead.

We were thinking of updating the identity attribute for each user to store the sAMAccountName used when the account is disabled. So, we can check the sAMAccountName for all the deleted users and refrain from provisioning the old ID. However, we are not sure on the feasibility of this to work on IDN.

Appreciate any input on this. Thank you!

If you are not going to delete identity then

Create an Identity attribute for SamAccountName, make it searchable, create first valid Transform for it.

  • If user has AD account, pull samAccountName from AD account
  • If not, pull samAccountName from identity attribute

In this way, it holds SamAccountName even after AD account got deleted.

Create an Account Profile Attribute Generator Rule with countIdentitiesBySearchableIdentityAttribute method.

Generate SamaccountName with whatever format you need, check for uniqueness using the mentioned method and increment accordingly.

1 Like

We have a separate Delimited File (csv) source set up specifically to serve as an answer to the question “what are all the samaccountnames we have ever used?”, mainly because we don’t have identity records for every single account that’s ever existed.

In the create profile, we have a generator rule for samaccountname that checks against both AD and the CSV source for uniqueness, and increments the number after the samaccountname until it finds a unique one in both sources.

Hi Krishna,

Thank you for the input!

To give an example for clearer understanding on what you are proposing,
Identity attribute: adid

Using the first valid operation on the attribute “adid”:

  1. Read the account attribute sAMAccountName from the account source
  2. Read the identity attribute itself “adid”

So, let’s say if the AD account got deleted, and was removed in IDN after aggregation, the transform script will help to read the second valid value, which is the identity attribute itself?

If I understand wrongly, can you assist to further clarify the statement “If not, pull samAccountName from identity attribute”, thank you very much!

Hi Mark, thanks for the input!

Can I know how do you read the sAMAccountName generated from the AD? Or is this CSV generated separately out of IDN and uploaded manually afterwards?

We used a combination of the current samaccountnames in AD and combined it with records we had in a personnel database that went back further. Then uploaded that file for the source. In order to keep it up to date, we use the API to add the newly generated samaccountname to the csv source.

This is what I meant.

{
  "attributes": {
    "values": [
      {
        "attributes": {
          "sourceName": "Active Directory",
          "attributeName": "sAMAccountName"
        },
        "type": "accountAttribute"
      },
      {
        "attributes": {
          "attributeName": "adid"
        },
        "type": "identityAttribute"
      },
      {
        "attributes": {
          "value": "none"
        },
        "type": "static"
      }
    ]
  },
  "type": "firstValid",
  "name": "SamAccountName First Valid Transform"
}

If you delete inactive identity after sometime then you need to follow what @mcheek has suggested with CSV approach.

If your HR source is scoped to not aggregate accounts after a certain amount of time, it will delete the Identity. So it is possible for prior login IDs to be used if the IDN Identity is removed.

There is a parameter that can be set on the source that will not delete the Identity.

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