Hi Experts,
My problem statement is: get the last created AD account > get the sAMAccountName from the account and increment it. Is there any way this is possible doing this is the AttributeGenetor Rule?
Looking for ideas!
Thanks,
Tamalika
Hi Experts,
My problem statement is: get the last created AD account > get the sAMAccountName from the account and increment it. Is there any way this is possible doing this is the AttributeGenetor Rule?
Looking for ideas!
Thanks,
Tamalika
Hello @tamalika01,
Could you please clarify why we need the sAMAccountName
of the most recently created account? I’d appreciate it if you could elaborate a bit more on the requirement.
Thanks!
I’d like to understand your use case better, you could try, suggest creating a delimited source. Whenever you generate a samaccountname, you could write to this delimited source.
Then, you can retrieve the most recently created account from that source and utilize it accordingly
You might be able to do this using After Creation rule (type: ConnectorAfterCreate
) where you can run some native PowerShell script to find the last account created (one before the current account that just got created) and extract the number from it, then update the sAMAccountName of newly created AD account
Hi @tamalika01,
Could you please share a bit more detail about your requirement? That would help us provide a more relevant suggestion.
Thanks,
Ujjwal
Hi
Do you have multiple AD sources and need to check uniquess then you can follow below LA
Hi there, so at the moment we are using an Account Attribute rule ro generate the next sAMAccountName and the logic is as follows:
Now we find that this takes some time to generate as every time in our rule we start with “AAA” and continue till we find a unique value. This is why we are thinking of adding a check. So the new flow could be theretically:
FYI @sidharth_tarlapally @UjjwalJain @Sivakrishna1993
@iamology we don’t want to use a NativeRule for this, as the value of sAMAccountName is not written back automatically after a successful account creation if the scope is outside of ISC. We have already tested this approach and decided to move forward with a Cloud Rule.
Hi @tamalika01,
Is prefix value the same for all the users.? If yes, I doubt if you will be able to achieve your use case with ISC, because of the way ISC parallel process each request, independent of the others.
So, if you have 10 account creations on a day, all would be processing almost at the same time and this uniqueness check wouldn’t be possible at all. Which means all would end up with sAMAccountName as PrefixDFG on that day.
Hi Tamalika,
Could you please elaborate why you want to do a check again in the Before Provisioning Rule for the requirement you are already able to achieve in the samAccountName Rule ?
Also, i dont think your requirement can be achieved as Sailpoint works on multi threading model where if you get 10 records it will process them the same time and it will be difficult for you to achieve this in Before Provisioning Rule.
Thanks
I just checked, i meant AttributeGenerator Rule, apologies for the confusion. I edited my post now.
And as for multi threading, I believe this is applicable for the IdentityAttribute rule where we try to generate a value during an Identity creation/update/refresh which can be multi threaded. But account creation is single threaded and I believe we won’t face this issue when we generate a value during account creation @RAKGDS @jesvin90
So to summarize - we are generating the sAMAccountName in an AttributeGenerator Rule at the moment, which is applied on the “Create profile” in the Source configuration. We did already try our “BeforeCreate” native tule, but the catch was that the new generated values were not written back to ISC after a successful provisioning operation, as all the logic was in the PS script, which was out of scope of ISC.
Hi Tamalika,
So suppose you have 10 accounts that are getting created. Sailpoint wont wait for one account to get provisioned it will start the provisioning of all at once. So if the Create Profile generates a username as AAA111. The other account request wont know that and it might also generate AAA111 as it is still not written in ISC.
Are you sure that Create Profile is multi-threaded? I believe accounts get created one by one from a queue. We took this approach as per SailPoint’s best practice recommendation here:
Yes Tamalika,
We had a similar requirement but the issue was that we were not able to generate unique value but it use to fail if there were 30 - 40 Joiners joining. I would recommend try out in your environment and see if you are seeing some issue if you have 30 - 40 joiners
Thanks for the tipm we’ll test this.