HR: match employees on user accounts

HR: match employees on user accounts

Door: Arnout van der Vorst

The basic challenge in matching any HR-system to Active Directory is finding the user account for every employee in HR. The best method of linking is to embed the employee ID or the social security number into the Active Directory user accounts.

When starting to synchronize HR to Active Directory, you may not have an ID for every Active Directory user, so you need to insert them first. To avoid having to manually match all user accounts, UMRA offers some smart scripting tactics to make sure you have about 85-90% matches done automatically.

UMRA’s basic synchronization engine offers the ability to read all employees from any HR-system, including all naming attributes. The results of the method as described in this topic can greatly vary based on how strict you have used naming conventions in the past and if the “displayName” or “cn” attributes contain named values.

  • Format %firstname%, %middlename% and %lastname% to remove diacritical marks
  • Match based on ldap search (&(objectCategory=person)(cn=%firstname%*)(cn=*%middlename_own%*)(cn=*%lastname_own%))
  • Match based on ldap search (&(objectCategory=person)(cn=%firstname%*)(cn=*%middlename_partner%*)(cn=*%lastname_partner%))
  • Match based on ldap search (&(objectCategory=person)(cn=%firstname%*)(cn=*%lastname_own%))
  • Match based on ldap search (&(objectCategory=person)(cn=%firstname%*)(cn=*%lastname_partner%))
  • All above matching techniques MUST only return 1 result, otherwise don’t use the results
  • All above matching techniques MUST be used in the order as shown
  • The above technique is based on the following cn contents: %firstname% %middlename% %lastname%: Arnout van der Vorst. If your cn contains values like “Vorst, Arnout van der” you will need to modify the sequence in the ldap search string
  • The above technique MUST be used in a joining operation, making sure you will never get the same or already processed results twice
  • Use the employeeID or employeeNumber attributes in Active Directory to store the HR unique ID

All entries that still do not match will mostly be misspelled entries, which can’t be detected. If HR contains the name “Adrianna” and your Active Directory user is called “Adriana”, it won’t be matched. UMRA can create a log of all user accounts which were not matched, these entries will need to be processed manually.

Geschreven door:
Arnout van der Vorst

Arnout van der Vorst is Identity Management Architect bij Tools4ever en al ruim 10 jaar in dienst. Arnout legt zich als Architect toe op het bedenken en ontwikkelen van nieuwe features, oplossingen en diensten van Tools4ever die aansluiten op de vraag uit de markt. Arnout studeerde Hogere Informatica aan de Hogeschool van Utrecht.

Anderen bekeken ook

De vooroordelen van Single Sign On

29 november 2011

RBAC: sleutelrol, beheer en evolutie

15 maart 2011

Single Sign On met terminal emulatie (VAX64, AS/400, Linux, SSH)

14 oktober 2010

SAP koppeling met Active Directory

06 september 2012

User- en toegangsbeheer in cloud applicaties: een uitdaging

04 september 2012