Recently I imported the employeeID (and a few other attributes) from an OpenLDAP directory into Active Directory. Problem was different distinguishedName attributes in both directories – the OpenLDAP directory had a different OU structure.
The Problem
We have a LDAP Data Interchange Format (LDIF) dump from OpenLDAP in the following format :
- dn: distinguishedName not consistent with Active Directory
- uid: ******* (Active Directory equivalent – sAMAccountName)
- employeeNumber (Mapped to the employeeID attribute in Active Directory, could have mapped to employeeNumber in Active Diretory 2003 as well).
How do you import this when the dn doesn’t match?
The Solution
Read the uid attribute in the LDIF dump, lookup sAMAccountName in Active Directory, get the correct distinguishedName for the user, dump info into a new LDIF file in the following format :
dn: user1 (correct distinguishedName from Active Directory)
changetype: modify
replace: employeeID
employeeID: ****
–
replace: attribute2
attribute2: ***
–
replace: attribute3
attribute3: ***
–
dn: user2
…..
To do this, script needs to:
- Open the existing OpenLDAP LDIF file and read the first 3 characters into a variable
- Figure out if it’s dn, uid, or first 3 characters of any of the other attributes being imported
- Skip a certain number of characters (different for each attribute)
- Read rest of the line
- Dump the values read into another variable
- If the line contains the uid attribute, look-up Active Directory for a user with a matching sAMAccountName
- Get the correct distinguishedName for that user
- Read the next line until all of that user’s attributes are read
- Detect end of one user’s attributes based on the extra carriage return after – )
- Write the correctly formatted info to a new file.
Once the new LDIF was produced with the correct format and distinguishedName attribute, it was simple to import data into Active Directory using LDIFDE tool.
The learning experiences (aka goof-ups)
Each project has its own peculiar goof-ups – some major ones, some minor ones. These are the learning experiences – wouldn’t be fun if everything worked smoothly the first time around, right?
-
Some users had DUPLICATE employeeIDs! Two, three, even five users with the same EID!! How did that happen? Well, some users exported from OpenLDAP, mostly contractors, didn’t have an employeeNumber. When the script read the attributes for a user with an employee ID, finished writing them to the new file and then went back to read the second user’s details – it saw no employeeNumber and used the previous user’s employeeID instead… Why? Because the variable had not been “flushed” or reset after details of the first user were written to the new file.
I wrote more scripts to search Active Directory based on employeeID which quickly revealed the employees with duplicate employeeIDs. Problem solved.
-
There’s no user interface to add the employeeID attribute to a user’s account. The choices were to write 1) a COM object 2) a web-based interface or 3) a script.
The script was the shortest path, but the challenge is to make running it part of the new account creation process that’s followed consistenly – I’m sure this is one step that’ll be missed every once in a while, and users who want to use the application based on this particular attribute will be unable to do so!
It’ll make sense to either script the entire new account creation process, or build a web interface to it. Time consuming projects.
{ 0 comments… add one now }