Subject: Before Create Rule: Account Linking Issue due to DN/sAMAccountName Modification
Body: Hi everyone,
I’m struggling with an account linking issue after modifying the DN and sAMAccountName within an AD Before Create Rule.
The Issue:
The account is created successfully in AD with the modified data.
However, the Tenant shows a “ghost” account with the initial data from the Provisioning Policy.
This “ghost” account isn’t actually in AD and can’t be aggregated.
The “real” account (with the modified DN) only appears after a full AD aggregation.
My Theory: Since the DN acts as the Account ID, the response sent back by the IQService doesn’t match the ID the Tenant is expecting. This prevents the immediate linking of the newly created account to the Identity.
Questions:
Has anyone faced this “ghost account” issue when changing the DN/ID via a Connector Rule?
What is the best practice to update the Provisioning Plan/Result within the Rule so the Tenant recognizes the modified DN as the correct Account ID immediately?
Any insights or code snippets on how to properly manipulate the AccountRequest or ProvisioningPlan to avoid this desync would be much appreciated!
This helps me later when starting to build the mover-process, but for now the question is if it is possible to change the DN to a value other than specified in the initial plan during creation via a before create rule or through an after create rule
Hi @fayadm Apols, I’m with you, you want to use a Connector Rule, I take it?
I don’t think the AC_NewParent would work on a Connector Rule so I don’t think your use case is possible as ISC needs to know to run a single aggregation with the new DN following successful provisioning and it won’t know what the new DN is. Can you not put your logic in a Cloud Rule, or Create profile?
I’ll leave it open to the community as I’m not saying it’s not possible, just that I don’t know how to do it.
I just tried it and it did not work, unfortunately I can not put it in the create account policy. I will check if ou moves in the after create rules solve the Problem. If not I would have to using a cloud rule.
Since I didnt use any cloud rules for now. Can I ask you if I need to call them through the create account provisioning policy and how?
Or if I need to put the logic in a before Provisioning rule?
It is very simple: I have to remove special characters like ä,ö,ü from the names and clean up the first and lastname. and based on a specefic attribute I determine the OU. I check if the Cn is already in use and if it is I count up.
I tried doing that through the given Generators in the create policy and I tried to change the input via transforms, but this doesnt work, so it must be a self-defined rule
I have faced this kind of issue. As per my understanding on your use case, during the AD account creation, you are trying to update the DN, correct?
I think during the account creation, you should not change the DN as its part of joiners process. In order to generate DN, we have CN + OU. Hence, create an identity attribute which stores the User’s AD DN and then, pass that attribute inside distinguish Name account attribute inside the create profile of AD.
I have used AD Before provisioning rule whenever I want to change the DN, SamAccountName, UPN, mail, etc. for the User. Also, the sequencing matters of which attributes you are passing in provisioning plan.
As DN is the Account ID attribute for AD source, make sure you are updating at the very end in the provisioning plan. Refer the below screenshot of the before provisioning cloud rule code which will give you more idea.
Hi @rohit_wekhande WADR, it’s considered not good practice to use Identity Attributes to generate uniqueness, because of the way ISC uses multi-threading in Identity Profiles.
Just for storing OU (In which OU the user should be placed), you can use an identity attribute.
Then, inside the account attribute generator cloud rule, use this OU attribute to concatenate ethe value. Also, for uniqueness check, the best way is to do it is through the account attribute generator cloud rule only.
Hence, he can follow the below.
Create an identity attribute named as “AD OU“.
Create a transform to assign a value to the user based on your criteria and attach that transform to above identity attribute inside the identity profile mappings.
Create an account attribute generator cloud rule which will perform the uniqueness check once the CN is generated for the user inside the rule.
Yes, you can do that but you need to make sure that DN has to be provided before the request moves out of ISC to the AD source. Hence, you can disable the DN attribute in create profile and provide the entire logic in before provisioning cloud rule and then, add it to the provisioning plan through before prov cloud rule only.
In my case it did not work. It appears to me that they expect identity attributes, but these are not sufficient for me because I need to change these and remove special characters.
I tried to do that in a transform, but it did not work.
Through Before Prov Rule or attr generator cloud rule , you can perform the complex ops. It can also be done through transforms lets say if you want to remove diacritical characters from CN, etc.
If I were you, I would raise another topic on why your Transforms are failing as what you are describing is nothing above what many people have successfully done before. Introducing Rules, modifying create policies is just introducing complexity where it is not needed
