• State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 95 subscribers
  • Views 7464 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Creating ADSAccount for two employees with the same firstname and lastname

evgenj
over 11 years ago

Hi everyone.

If I try to import data from HR via Data Import tool to create new AD accounts for employees and there are two employees with same name and same lastname (but different ID), I get the follwing error:

The connection mode of the provider was set to Default. Loading import file C:\Program Files (x86)\Quest Software\Quest One Identity Manager\ADSMapping.DLL.XML has changed the object property assignment rules and the member relationships. The access to RAS attributes was set with the value True. The access to terminal properties was set with the value True. [854003] Processing task ADSAccount Insert failed. [997030] Cannot publish object LDAP://MYDOMAINSERVER:389/CN=Firstname Lastname,OU=Users,OU=myOU,OU=myOU,DC=mysubdomain,DC=mydomain,DC=myrootdomain (Message : The object already exists. ). [System.DirectoryServices.DirectoryServicesCOMException] The object already exists.

Both employees should be in the same department and OU. I think the problem is because Q1IM try to set them the same CN which is Firstname Lastname. Because they are in the same OU, Q1IM try to set distinguishedname like DN=Fistname Lastname,OU=myOU,OU=myOutherOU,OU=myAnotherOU,DC=mysubdomain,DC=mydomain,DC=myrootdomain for both.

But if I manually create employee Firstname Lastname and wait Q1IM to create user account and then create another employee Fistname Lastname, Q1IM will change CN for the second employee to Firstname Lastname_1 and this is the behaviour I want.

Why the CN is not changed when I import users through Data Import?

Best regards,

Evgen

  • 0 over 11 years ago

    Hi Evgen,

    just to understand what you are doing exactly:

    Do you import directly to the ADSAccount table or do you import to the Person table and assign an AD account ressource?

    Regards,

    Stefan

  • 0 over 11 years ago

    I import data to Person table and then automatically assign an AD account ressource.

  • 0 over 11 years ago

    Okay, in your scenario, the import should produce a lot processes named VI_PersonHasResourceTotal_AutoCreate_ADSAccount (or something like this, cannot verify this from home). Those processes contain a script that uses the objectlayer to:

    1. create a new ADSAccount object.
    2. link it to the person that just got the ressource (set ADSAccount.UID_Person)
    3. set the managelevel of this account to 1 (or whatever your managelevel is) which will trigger a lot of templates
    4. save the ADSAccount object

    As far as I can remember the template of CN checks, if there is already another account having the same cn, in the same container. The template perfoms this lookup into the database. If there is already such an account, the numeric suffix is attached as you have oberserved in your manual test. So what might have happend is, that the script described above was executed parallel. When the templates of account 2 runs before account 1 is actually saved to the database, the templates of account 2 "thinks" that the cn/dn is unique.

    As stated, those are only assumptions that I can verify tomorrow.

  • 0 over 11 years ago

    You're right. The import process produces a lot of processes named VI_PersonHasResourceTotal_AutoCreate_ADSAccount. But those processes executed with no error. When the processes VI_ADS_ADSAccount_Insert are later created the error mentioned above accours for the second account at the step Create ADS Account in ADS.

    I would appreciate any idea how to deal with this situation.

    Thanks a lot.

  • 0 over 11 years ago

    You are right, the actual failure (frozen job) happens later when the AD component acutally tries to publish the account to AD but the source of the problem already happend during the execution of the script. Allthough it ran without an error it produced a duplicate DN. The simplest workaround is maybe to copy the VI_PersonHasResourceTotal_AutoCreate_ADSAccount and change the task of the job that creates the account from ScriptExec To ScriptExecSingle. This should assure that accounts are created sequential. The downside of this is decreased performance on mass operations.

  • 0 over 11 years ago

    Thanks for the tip. It works.

  • 0 over 6 years ago
    Can I have samaccountname in CN value of DN where we have "firstname lastname" right now? I tried changing in Distinguished name column of ADSAccount table in One IM schema but the value calculation is non editable. Can we have it editable?
  • +1 over 6 years ago
    Did you think about storing the SAMAccountName in the CN property? Your data will get messed up in AD / OneIM if you just try to change the composition of the DN.