AD Create Account - sAMAccountName not unique

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi all,

I’m encountering an issue in SailPoint Identity Security Cloud (ISC) where multiple Active Directory accounts are being provisioned with duplicate sAMAccountName values, despite using $(uniqueCounter) to ensure uniqueness. This is happening during role-based provisioning (birthright access).

:wrench: Configuration Details

  • Accounts are provisioned automatically via role membership.
  • I’ve defined a custom identity attribute:
    samaccountcreationlogic = first letter of givenName + surname
    (e.g., John Smith → jsmith)
  • In the Create Account provisioning policy for AD, the sAMAccountName is configured as:
$(samaccountcreationlogic)$(uniqueCounter)

So I’d expect something like:

  • jsmith1
  • jsmith2
  • etc.

:red_exclamation_mark: Issue

Despite this logic, AD account creation fails with duplicate sAMAccountName values (e.g., multiple attempts with just jsmith). This results in the following error returned from IQService:

Exception occurred while executing the RPCRequest: Errors returned from IQService. 
"The object already exists. The object already exists. 
00000524: UpdErr: DSID-031A11F8, problem 6005 (ENTRY_EXISTS), data 0 
00000524: UpdErr: DSID-031A11F8, problem 6005 (ENTRY_EXISTS), data 0 
. HRESULT:[0x80071392] 
For identity: <Identity_Name>"

It looks like $(uniqueCounter) is either not being evaluated, or not incrementing during the role-based provisioning flow.

:white_check_mark: What I’ve Verified

  • samaccountcreationlogic is populated correctly and consistently.
  • The same logic works correctly when provisioning via Access Requests.
  • The AD source’s Create Account configuration is mapped as expected.

:red_question_mark: Questions

  1. Is $(uniqueCounter) officially supported in role-triggered provisioning flows?
  2. Are there known limitations with dynamic expressions (like transforms or counters) in Create Account templates during automated provisioning?
  3. Would shifting this logic into a Before Provisioning rule be a better approach to ensure runtime uniqueness?

Any advice or insight would be greatly appreciated — especially if others have faced this behaviour in automated provisioning scenarios.

Thanks in advance!

—Matt

2

Hi Matt,
Please check if you have cloudRequired=true in your Create Account Provisioning Policy.

“attributes”: {
“template”: “$(samaccountcreationlogic)$(uniqueCounter)”,
“cloudMaxUniqueChecks”: “50”,
“cloudMaxSize”: “20”,
“cloudRequired”: “true”
}

It should be something like above. Please add it and try to Provision the issue should get fixed.

Thanks

3

Hi @mnapoli

3 questions:

  1. Are you using the Create Unique LDAP Attribute generator?
  2. Have you aggregated accounts from the source?
  3. Is the conflicting existing jsmith in the scope of your connector?
4

Hi Rakesh,
Yes I have it configured as such.

        {
            "name": "sAMAccountName",
            "transform": {
                "type": "rule",
                "attributes": {
                    "name": "Create Unique LDAP Attribute"
                }
            },
            "attributes": {
                "template": "$(samaccountnamecreationlogic)$(uniqueCounter)",
                "cloudMaxUniqueChecks": "50",
                "cloudMaxSize": "20",
                "cloudRequired": "true"
            },
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        }
    ]
}
5

Apols, I jumped straight in with my questions.

As to your questions: AFAIK:

  1. Yes
  2. No
  3. No (based on the 2 answers above)

2 more questions from me, though, if I may:

  1. When you say role-triggered provisioning flows: Is it Role > AP > Entitlement?
  2. When you say access request works, is that for a role, AP or Entitlement?
6

Hi Jeremy,
Yes I am using the Create Unique LDAP Attribute generator. Also I have aggregated accounts from the source (active directory), and yes ‘jsmith’ is in scope of the connector.

7

I’m sure its probably a typo, but you’ve got

samaccountnamecreationlogic

in the transform, and

samaccountcreationlogic

in the post?

8

Hi Matt - also something else to check. Are you sure it’s the sAMAccountName causing the problem? AFAIK, you would get the same error if UPN or DN were clashing.

9

Hi Jeremy, apologies for the late response here are my answers:

  1. When you say role-triggered provisioning flows: Is it Role > AP > Entitlement?
    Currently it is Role > Entitlement. No AP configured.
  2. When you say access request works, is that for a role, AP or Entitlement?
    Apologies please ignore the access request part of the post. These roles are not requestable (since they are birthright) and have not been tested / implemented for user access requests.
10

Also this is the transform to evaluate the samaccountname for an identity:
“name”: “PVT-SamAccountNameCreationLogic”,
“type”: “static”,
“attributes”: {
“fname”: {
“attributes”: {
“input”: {
“attributes”: {
“name”: “preferredName”
},
“type”: “identityAttribute”
},
“regex”: “[^a-zA-Z0-9]”,
“replacement”: “”
},
“type”: “replace”
},
“lName”: {
“attributes”: {
“input”: {
“attributes”: {
“name”: “lastname”
},
“type”: “identityAttribute”
},
“regex”: “[^a-zA-Z0-9]”,
“replacement”: “”
},
“type”: “replace”
},
“value”: “$fname.substring(0,1).toLowerCase()$lName.toLowerCase()”
},
“internal”: false
}

11

Hi @mnapoli ,

Can you check account activity in search tab for this user and see what value is being pushed for “samAccountName” during create? Is that having $(uniqueCounter)?

13

Hi @mnapoli

Can you confirm that the Identity Attribute you use for the sAMAccountName stub (or seed) is getting correctly populated and the attribute name that you use in the sAMAccountName transform is the “technical” name for that attribute? I see 3 different names used in this post: PVT-SamAccountNameCreationLogic, samaccountnamecreationlogic and samaccountcreationlogic. Bear in mind that the technical name is case specific.

Also, can you confirm that it is the sAMAccountName that is causing the issue with AD, ie the DN and UPN are not causing the object already exists message?

14

Hi All, thank you for your assitance with this topic of discussion. I believe the main problem with this issue I am facing is that in that I am trying to create accounts at the same time and SailPoint cannot interpret that two target accounts will have the same sAMAccountName/DN before being provisioned in the same batch of new identities in SailPoint. It has been made aware to me that this is a race condition when there are multiple accounts getting created at the same time and is difficult to avoid.