AD account provisioning creates a unique username using this:
“template”: “$(samaccountnameCalculate)$(uniqueCounter)”, and connects to Entra ID for mailbox provisioning
If a user needs to change their name but wishes to retain all in their data that is held in under their existing email, we must therefore rename the existing account rather than create a new one.
Has anyone managed to do this automatically rather than manually via ADUC?
Does $(uniqueCounter) work in the the UPDATE function of account provisioning, or is it only for AC_NewParent & AC_NewUser?
Hi Phil,
If you want to have a unique value then you will use uniqueCounter inside username generator transform.But it can’t be used in random attribute on source. It can be used used on attribute which is defined as “accountID” in schema (nativeIdentity). Example if u defined DN as accountID then the unique counter works there.In your case if you are not trying to modify the accountID in your source then $(uniqueCounter) won’t work.Try creating custom rules for this.
Thanks!!
Hi @naveenkarthikkrk,
It is being used on the accountName (sAMAccountName).
’
{
“name”: “sAMAccountName”,
“transform”: {
“type”: “rule”,
“attributes”: {
“name”: “Create Unique LDAP Attribute”
}
},
“attributes”: {
“template”: “$(samaccountnameCalculate)$(uniqueCounter)”,
“cloudMaxUniqueChecks”: “10”,
“cloudMaxSize”: “20”,
“cloudRequired”: “true”
},
“isRequired”: false,
“type”: “string”,
“isMultiValued”: false
},
’
However, your answer implies that it does work on the UPDATE profile as well as the CREATE profile. I will see if I can get it to work
Thanks
I see that the rule used here uses internally ldapService.generateUniqueLDAPAttribute method and guess it should work for both update provisioning policy as well (but I personally have not tried it myself yet so please make sure to test it in lower environments). In addition to that you maye also ensure that the required attributes are made searcheable for uniqueness check if this is a new attribute for which you need the uniqueness check to be performed.
But there are many reasons not to use it in update provisioning policy, one of which is that if you add this rule into UPDATE provisioning policy, then for any modification this rule will be invoked and it will need to do uniqueness check for all the accounts which are there in your target application and will add unnecessary load on the system.
I have seen in organizations that these cases are quite rare and if that is case with you too, then i believe you can have a powershell script in place. And when ever such requirement comes then it will be better to do it on adhoc basis you that the control lies with you .
But the decision is completely dependent on the use case but i believe it should work in update policy as well.
Another option you could explore is also standard services before provisioning rule which will give you the flexibility to control its invokable based on identity attribute change or lot more triggers.
I hope this help, in case of additional questions, please let us know.
.