Add user from command line

This is a "me too" post, but perhaps with a slight twist (same ultimate effect though).

After doing a slapcat on our 10.4 OpenLDAP server, it is obvious that user accounts contain a ton of additional information in binary (or at least base64) format that we won't be able to reproduce with just using dscl, ldapadd, ldapmodify, etc.

ALL our Active Directory users are completely managed with perl scripts that act off of various databases (HR, Student Records, enrollments, etc). With our ultimate goal of having OpenLDAP be our primary directory service, we will need to duplicate this on our Open Directory Master.

My concern is that accounts created/modified with dscl or ldapmodify, etc. will not have all the functionality of accounts created through the GUI and in essence be second-class citizens and might cause "strange" problems.

Are there other, better commandline tools which sill populate the other fields (apple-user-homeurl, authAuthority, apple-mcxflags, apple-generateduid, etc.) with proper or default values? Are there perl modules (beyond Perl::LDAP) that Apple or someone has that can streamline this?

From the date of the original post here and the subsequent responses, I'm guessing I'll be hearing crickets chirping for a while. Any input would be greatly appreciated.

Has anyone found anything yet? I have found that GeneratedUID (apple-generateduid) is not populated for all of my users. It creates problems when trying to upgrade the legacy groups. Anyone have any kind of solution?

Thanks,

Greg Harris

We create ALL (~20,000) our users from the command-line (actually a perl script). We assign custom uid's gid's, etc.

The way we had to do it was to generate a text file that contained the needed information for the user and then run dsimport to create the open directory user.

The text file looks like this:

0x0A 0x5C 0x3A 0x2C dsRecTypeStandard:Users 8 dsAttrTypeStandard:RecordName dsAttrTypeStandard:AuthMethod dsAttrTypeStandard:Password dsAttrTypeStandard:UniqueID dsAttrTypeStandard:PrimaryGroupID dsAttrTypeStandard:RealName dsAttrTypeStandard:UserShell dsAttrTypeStandard:Comment
testUser1:dsAuthMethodStandard\:dsAuthClearText:userPassword:10023:2000:User1\, Test:/bin/bash:User Comment
testUser2:dsAuthMethodStandard\:dsAuthClearText:userPassword:10024:2000:User2\, Test:/bin/bash:User Comment

I'm not sure how this is going to display in the post but the the header information is all on on line and the user records follow on separate lines below it. Contrary to what you might think the dsRecTypeStandard:Users 8 part is NOT the number of users, but the number of attribute fields listed for each user. There are a lot more fields you could add here (try man dsimport) but these are the only one we use - the rest of the attributes we modify with ldapmodify.

The command line we use to create the user is:

dsimport -g pathToUserList.txt /LDAPv3/127.0.0.1 O -u diradmin -p adminPassword

After the user is created we customize the user's other attribute using ldapmodify. This is why we use a script to generate the necessary information and execute the command line. If you have a large amount of users you may run into some issues with the password server database not expanding fast enough to handle user creation (at least we ran into that). We solved it by pre-expanding our password server database (to 30,000) records and then creating our accounts.

Hope this helps...

Yuck, I was hoping that there was an easy way to create the generateduid without disturbing the current LDAP users. It would seem that someone should have done this when adding an OSXS to an existing AD. Oh well, guess I will continue to look around.

Thanks,

Greg Harris

/usr/bin/uuidgen will generate you a new uid , but then you still have to integrate that back into all the right places in the authentication system ...

Interesting bit of info, thanks. But man, that opens up a bunch more questions. In an LDAP layout, it would seem that it only populates the one field. I also seem to remember seeing that it is based on date and time, so it doesn't need to keep track of what uuid's have been created. Anyone know if this is true, or am I off on a rabbit trail with a dead rabbit?

Thanks,

Greg Harris