Hi Team, we are using an identity attribute to generate EmployeeID which is then mapped to sAMAccountName in AD create account. The issue that I am noticing here is:
In Dev: The sAMAccountName is getting assigned properly to the user during AD account creation. I can see it in account activity details.
In QA: We have same configuration in place, but sAMAccountName is not getting generated during AD account creation. It is throwing warning like this:
As a result of this, we see a random value in user’s sAMAccountName.
My understanding is that ISC is trying to create the AD account before the identity attribute “Employee ID” is created and that’s why not able to map Employee ID to sAMAccountName.
Is there a way this sequence of how tenant generates Identity attributes first and then tries to create AD account be modified ?
@pateldivyang0319 How are you triggering AD provisioning ? via access profiles or roles ? In both it will get triggered when the user is in active LCS so there are less chances that its getting triggered before identity creation. if you have enabled logs for your rule.you can raise a support ticket and check what values are being passed as input.
Regarding your question : “Is there a way this sequence of how tenant generates Identity attributes first and then tries to create AD account be modified ?”
==>
In ISC, this sequence cannot be controlled. Since the samAccountName is not typically synchronized in a standard way, you can generate it during account creation Active Directory. Then, in your Identity Profile, you can map the samAccountName to an identity attribute using the corresponding samAccountName attribute from Active Directory. For a new identity, the samAccountName will initially be empty. However, once the Active Directory account is created, it will be populated automatically.
In general, identity attributes are ready before the provisioning operation are triggered. However, there may be a slight delay in the generation of your samAccountName.
The thing is if its slight delay, it should be populated in some time but the sAMAccountName is not syncing back and changing it to the Employee ID value based on our transform unless we are enabling the Employee ID sync “ON” in AD source.
Even if Attribute Sync is ON → I noticed that in provisioning activity we still see same error but it is performing an additional modify step
Hi @pateldivyang0319 How exactly is your sAMAccountName getting mapped on the Create Account profile? You mention Employee ID Identity attribute, how is that getting mapped in the Identity Profile?
I am using 2 other identity attributes to calculate Employee ID. Using Employee Number which is coming from HR feed and another attribute from HR which gives information whether user is Employee or contractor and based on that information, calculating Employee ID e.g. E100100 or C100100.
@pateldivyang0319 one of the SailPoint technical team members recommended avoiding the use of Identity attributes in transforms, especially when they are mapped to other Identity attributes. Instead, whenever possible, you should use account attributes.
This is because all Identity attributes are calculated in parallel, except for cloudLifecycleState, which is calculated last.
If possible, in your TR_employeeId transform, try using account attributes instead. This approach should work better.
If you can get the same value from account attributes, refer to that and don’t use identity attribute in transforms that are used to populate another identity attribute.
Also for the issue that you are facing, instead of mapping identity attribute directly in the “Create Account” refer to the transform that is responsible for generating your “Employee ID“, this should resolve your issue.
Echoing @baoussounda Why can’t you use account attributes for your Employee ID transform. This is best practice. One of the reasons is the fact that Identity Attribites get calculated in order of the identity profile, so, I’m guessing here, the attributes you use in your transform aren’t getting populated when it creates the identity, only when it refreshes the identity.
Hi @UjjwalJain I’m not sure I agree with relying on the transform in the create account profile. The OP wants an employee ID on the Identity, if it was done on the account create it would have to be read back before it became available on the identity.
I will try to use account attribute. But again, why this is working in one tenant and not in the other. Both have same configurations ? That’s the part I am not able to understand
You could just be getting lucky on the production tenant as it will be more powerful than the QA and those identity attributes could be populated in time for use in the transform. Also the order of attributes in the production identity profile could be different? Either way it sounds like the configuration in production could be “sub-optimal” too.
Also intrigued by your Identity Attribute mapping for Employee ID. I notice it has sAMAccountName as input which (I assume) means that you are referencing the AD as source. Admittedly you may not be referencing the input implicitly in the transform, but slightly confusing to the viewer, I would say, as it implies a circular process, and, indeed could be causing some issues.
Also, attribute sync on sAMAccountName can’t be recommended. I’m just starting to wonder whether it works on your production tenant even more accidentally. Ie it creates the AD account with a random sAMAccountName, the AD account is aggregated back and updates the Employee ID according to the transform and then Attribute Syncs it back to AD (!).
Just re-read your post, when I say production read Dev.
In our case, during account creation, the behavior was inconsistent: sometimes the value was available during provisioning operations, and sometimes it was not, due to the interdependence between identity attributes within the transform.
It also depended on the execution environment. However, once we switched to using Account Attributes, everything worked fine.
I meant to use the transform on the identity profile mapping to populate employee id, but instead of referring to identity attribute in create account, refer to the same transform that is responsible for populating employee id.
@pateldivyang0319 what i see is you are using an identity attribute in the sam accountname which is evaluated based on a transform since there is no sequence of which transform gets evaluated first it may cause this issue. Better try to use the transform directly in create profile
