Import user attributes from OpenLDAP

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.

So we have a LDIF Dump from OpenLDAP in the format :

dn: distinguishedName not consistent with AD
uid:  *******  (Active Directory equivalent - sAMAccountName)
employeeNumber:    (Mapped to employeeID attrib in AD, could have mapped to employeeNumber in AD 2003 as well).
-

How do you import this when the dn doesn't match?
Process: Read the uid attribute in the LDIF, lookup sAMAccountName in AD, get the correct AD distinguishedName for the user, dump info into a new LDF in the format :

dn: correct AD dn
changetype: modify
replace: employeeID
employeeID: ****
-
replace: attribute2
attribute2: ***
-
replace: attribute3
attribute3: ***
-

dn: user2
.....

To do this, VBScript needs to:

1) Open the existing OpenLDAP LDIF file
2) Read the first 3 characters into a variable
3) Figure out if it's dn:, uid, or first 3 characters of any of the other attributes being imported
4) Skip a certain number of characters (different for each attribute)
5) Read rest of the line
6) Dump the stuff read into another variable
7) If the line contains the uid attribute, lookup AD for a user with a matching sAMAccountName
8) Get the correct distinguishedName for that account
9) Read the next line --- till end of one user's details
10) Determine if one user's details have been read (based on the extra carriage return after - )
11)  Write the correctly formatted info to a new file.

Once the new LDF was produced with the correct format and distinguishedName attribute, it was simple to import it into AD using LDIFDE.

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! 2, 3, even 5 users with the same EID!! How did that happen? Well, some users exported from OpenLDAP did not have an employeeNumber. Mostly contractors. When the script read stuff for a user with an employee ID, finished writing it to the new file, 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" after details of the first user were written to the new file.

More scripts were written to search AD based on employeeID - that quickly showed the employees with duplicate employeeIDs.

There is no user interface to add the employeeID attribute to a user's account. Either you write a COM object, or a web-based interface, or a script to do it. The script was the shortest path. Now, the challenge is to make that 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.