Creating ADSAccount for two employees with the same firstname and lastname

Question

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

Stefan.Boerner · Accepted Answer

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.

Markus Weiss-Ehlers · Answer

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.