We have a requirement where we need to generate a unique sequential uidnumber during account creation.
This is an IBM Tivoli DS connector which follows LDAP. We thought of implementing this using the Create Unique LDAP Attribute / username generator transform but it is designed for username and has no native awareness of the current maximum uidnumber.
The recommended approach would be to query the LDAP server during account creation, retireve the current maximum uidnumber, increment it, and use the incremented value for provisioning the new account. What would be the best way to implement this and is this approach supported/recommended in ISC? Limitation around concurrency is not an issue as the source account is created on request basis.
For this case you can use BeforeProvisioning Rule to achieve above use case. Utilise IdnRuleUtil for checking the new value exists in the application or not.
The idea is to use a BeforeProvisioning Rule to check for the current maximum uidNumber exists in source, increment it, and inject the new value into the provisioning plan during account creation.
IdnRuleUtil can additionally be used for uniqueness validation. Since the provisioning is request-based, concurrency should not be a major concern in this case. Let us know if you have better approach to handle this use case.
You are correct — IdnRuleUtil itself cannot retrieve the maximum uidNumber directly.
My intention was that the actual max uidNumber lookup would need to be performed through an LDAP query (or connector-supported search) inside the BeforeProvisioning Rule logic, while IdnRuleUtil could still be used separately for uniqueness validation/checks if needed.
So the sequence generation logic would primarily rely on the LDAP lookup rather than IdnRuleUtil alone.
Hi @shyam_sreevalsan Let me know if you are pulling the uidNumber into the ISC application schema. If you are aggregating the uidNumber data into the application, and if you are not aggregating the uidNumber, please add the attribute into the schema and aggregate the data. You have the data and you can simply write the account transform by incrementing 1, which is provided by the ISC uniqueCounter.
I haven’t come across any use case to make API calls, but I have read in community other developers implemented, however we can get confirmation on this.
Get all accounts, get uid of all accounts, feed them to a list, find the max number using Collections
HI @KRM7 I’ve heard people have had success using API to write back the last used to an application attribute, but via a connector rule (AD).
Thing is with Cloud Rules, would SP authorise a Rule to retrieve what could be thousands of objects? Also, what about paging? I think it could get messy.
Also using Collections on what could be a large array, could be intensive.
Hi @j_place Here is my proposal: Since LDAP has the UIDNumber, we will aggregate the UIDNumber at the application level. Once we get the UIDNumber at the application level, we have the control to write the transform. From there, we can increase it by 1. That would be a simple solution I would recommend instead of hard-pulling every time during the account request. What would you say @j_place ?
Say you’ve got 10,000 accounts on your source. These are aggregated into ISC (including the UID attribute). You would need to find the highest of the 10,000 UID values to then increment. I’m not aware of any Transform functionality that can do that for you. Obviously, I would be happy to be corrected, so if you could give just a bit more detail on your solution, that would be appreciated.
Hi @KRM7@j_place ,we did this senarion can you check and confirm ,In the Active Directory source’s account create provisioning policy, the sAMAccountName
attribute will be calculated using the Create Unique LDAP Attribute generator with
the pattern $(samValue)$(uniqueCounter)
