Migrating LDAP Users and Passwords to a Clean 10.4 Server

Thursday, August 11 2005 @ 02:00 pm MDT

Contributed by: andrina

It was a dark and stormy afternoon when Ian (maccanada) and I sat down to fight the beast that is LDAP migration from an up and running 10.3 Server to a brand new, out of the box, 10.4 server. Lucky for you, the battle was won by us, and the gory details of the fight will lay themselves out for you as you read on...

Revised Password Server details in article Aug 11, 2005

So, here's the deal, We have a production 10.3 server that has previously had a similar trick as we're about to play out done to it to go from 10.2. I'd have to say this round through was considerably easier, but not without its caveats!

The end goal is to have a 10.4 server, with our LDAP users AND passwords, and to have this all running on a nice new shiny install of 10.4, not an upgrade in place from 10.3. After all we all deserve a new server from time to time, don't we?

N.B.Our original server is running 10.3.9 - there was a change in the LDAP schema between 10.3.8 and 10.3.9, for the following instructions to work smoothly, make sure you start with a 10.3.9 server, or upgrade to 10.3.9 and then continue.

First things first, we need to get all the user records from our 10.3 server. This is all going to be done without disturbing our production server. We're going to grab everything into an ldif file.

sudo slapcat -l /path/to/file.ldif

While we're here, we're going to grab our password server database also. In reality you should already have a backup of this database - right?

Make a directory where you want your database files to go to:

sudo mkdir /path/to/backup_directory

Then backup your password server database to that same directory:

sudo mkpassdb -backupdb /path/to/backup_directory

Now, here's the fun part - remember I said earlier that my production server was the previously battled beast that had users and passwords previously migrated to it from 10.2? This left me with anomalies in my LDAP schema, which once found, were remarkably easy to deal with. As some of you may have noticed there was an addition to the schema in 10.3 of the sn attribute, while I won't go into all the details, records without the sn attribute won't import into 10.4.

So, how to get around that - open your ldif backup file in your favourite text editor, I like TextWrangler (not only does it work really well, but it's Free!) and do a find for structuralObjectClass: inetOrgPerson and replace it with sn: 99. Now, you may not have any of these to find and replace, and that will be totally normal if your server has only ever lived it's life as a 10.3 server, and in this case, just carry on with the next steps.

There's one more modification we have to make to this ldif file, we're going to remove the root user account, and the admin user account - in my case this is the user with UID 0 and UID 501. Not removing these causes all sorts of havoc on your 10.4 machine with the diradmin user.

What you're going to be looking for is something like the following to remove:


dn: uid=root,cn=users,dc=example,dc=com
shadowExpire: 0
uidNumber: 0
uid: root
cn: System Administrator
shadowLastChange: 0
loginShell: /bin/bash
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: apple-user
objectClass: extensibleObject
sn: 99
entryUUID: e8d1a0d0-3fa3-1028-9a37-8b0744a1cd20
creatorsName: uid=root,cn=users,dc=example,dc=com
createTimestamp: 20040521185336Z
homeDirectory: /private/var/root
gidNumber: 100
apple-mcxsettings:: *whole lot of mcx gibberish removed from here*
apple-mcxflags:: *more mcx gibberish removed*
entryCSN: 2004090321:18:39Z#0x0032#0#0000
modifiersName: uid=admin,cn=users,dc=example,dc=com
modifyTimestamp: 20040903211839Z
userPassword:: e0NSUDNEfUp5hYmiDSmQzbTl1iDV=

So, remove that whole lump from your ldif file, as well as a similar lump for your admin user - generally this will be the user with user id 501 - you could to a search in your ldif file for uidNumber: 501 to help narrow it down.

Now, set up your shiny new 10.4 server as an Open Directory Master, make sure kerberos is running - if it's not running, do not pass go, do not collect $200 - you've got to fix this first! I'm putting my money on your DNS server...

It's important at this stage to make sure your search base matches that on your old server or your LDIF file won't import properly - you'll get 'container not configured to hold' errors as slapadd tries to dump stuff into the wrong place in OpenLDAP.

So, you have an Open Directory Master, Kerberos is running, and in Workgroup Manager you have a total of one client - your Directory Administrator. We need to back up our password server database at this point on our new 10.4 server - exactly the same process we went through on the 10.3 server for backing up the database there, we're going to do it again now:


sudo mkdir backup_from_new_server
sudo mkpassdb -backupdb backup_from_new_server

We're interested now in the new RSA key that's been created on our 10.4 server, on the new server do the following:


mkpassdb -dump

Look for the section prefaced with "Public Key:". It will be a string of numbers that probably start with 1024 ended by root:your.server.com. Copy all of this.

Open up your ldif file again, and have a look for any user's "authAuthority" record. After authAuthority the entry should contain ";ApplePasswordServer;" then the slot ID of the user, and then the previous RSA key from the old server. Notice that your old RSA key probably ends with "root@server.example.com:ip address", from the mkpassdb -dump you did earlier, find all of the current RSA keys, and replace them with the new RSA key from your 10.4 server with the new IP address on the end of the key. I did this very easily with find and replace in text edit. Save your ldif file.

Time to move in the new neighbors! Copy over the ldif file and the directory of all your password server data to your 10.4 server. First things first, lets get the ldif file imported:

sudo slapadd -c -l file.ldif

You can open up Workgroup Manager and confirm you've got the right number of accounts in there now. If you run into problems at this step, check things like the base DN you used when you promoted your machine to an OD Master (see above).

Assuming all your expected users now show up in Workgroup Manager, time to match up your users passwords - this is where we're using both password server backups, we're using mergeparent rather than just mergedb to preserve the current identity of the password server:

 sudo mkpassdb -mergeparent backup_authserver_folder backup_from_new_server

Now the moment of truth - has it all worked.... simple check, su to a user (probably yourself) that you know the password of from your 10.3 server, if that same password now works on your 10.4 server you have successfully followed all the steps! If not, you have a few episodes of turning your machine to a standalone server and promoting to an OD master ahead of you - not to worry though, my server has gone through this particular episode several times today and has lived to tell the story.

Last thing, how about some kerberos goodness? If you were to try and get a ticket at the moment you'd have an error along the lines of not knowing who the user was (because it isn't in the database), simple fix, kerberize the passwords in your password server database:

mkpassdb -kerberize

N.B. This is assuming you haven't customized kerberos on your 10.3 server, if you do have customizations there you are going to want to back this up with 'kdb5_util dump' and move it over with 'kdb5_util load', for simplicity we haven't gone into details of this here.

So there you go, fully up and running with no hint of an upgraded server in sight! Course, the next bit of pleasure is going to be filling in all those fields we now have available to us on the info tab of Workgroup Manager... Keep your eyes peeled for a script to that effect coming soon.

Comments (86)

AFP548
http://www.afp548.com/article.php?story=20050615173039158