Migrating Open Directory from 10.3.9 to 10.4 – Problems #1

Recently I finally bit the bullet and migrated my 10.3.9 Open Directory Master to 10.4.3, and ran into a couple of problems along the way…

Although I’ve been hearing the odd report about a successful upgrade, I decided I’d follow something similar to Andrina’s article on afp548.com on how to dump LDAP, Password Server and Kerberos, and then re-import those to a clean 10.4 Open Directory Master.

1. The first problem I ran into was Andrina’s suggestion to use mkpassdb -mergeparent. Doing things this way will generate a new RSA key for the entire Password Server database, which is problematic for my setup. I have way too many mobile users (we’ve been using mobile accounts since they were introduced in 10.3) who have an original_authentication_authority property in their local mobile user record in NetInfo. If the RSA key were to change, I’m pretty sure these accounts would essentially be orphaned, and I just decided I couldn’t take that risk, so I instead used mkpassdb -mergedb, which will replace the entire Password Server db from the 10.3.9 backup, rather than merging it with the clean 10.4.3 database.
2. Another really really annoying problem I ran into regarded the use of slapcat and slapadd to dump and import the LDAP database. I have quite a few ‘email only’ user accounts that do not have a homedirectory property set. As I’ve created these via Workgrop Manager, these are of the type ‘posixAccount’, and the LDAP schema definition for posixAccount requires that all such accounts MUST have a home property. slapadd refused to import these users.

   I had at least three options once I realised this was an issue.

   1. Reboot my existing 10.3.9 server, and use Workgroup Manager to export all the user records, then import them to the 10.4.3 server, and then use the ldap tools to overwrite the authentication_authority records for those accounts. As they had already been created, the ldap tools should have had no problem overwriting properties.
   2. Use ldapmodify/ldapadd to add the accounts from the ldif dump, as they ignore the schema checking that slapadd does. I’d run into some issues with the PWS import, so I was having trouble authenticating to the LDAP directory via password, and I also ran into some issues with the Kerberos import, mainly to do with not having an ldap principal for the OD master so I couldn’t authenticate that way either.
   3. Modify the schema for posixAccount such that it no longer required a home attribute. This seemed to be the path of least resistance, so I went this way. To do this, edit /etc/openldap/schemas/nis.schema, and change the posixAccount definition:
      

      objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY
              DESC 'Abstraction of an account with POSIX attributes'
             MUST ( cn $ uid $ uidNumber $ gidNumber $homeDirectory )
              MAY ( userPassword $ loginShell $ gecos $ description ) )
      

      to:

      objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY
              DESC 'Abstraction of an account with POSIX attributes'
             MUST ( cn $ uid $ uidNumber $ gidNumber )
              MAY ( userPassword $ loginShell $ gecos $ description ) )
      

      Once I’d done this, slapadd happily added all my email-only users.

3. Kerberos. This caused me no end of pain. I initially didn’t want to simply do mkpassdb -kerberize, as I wanted to keep all my existing host and service principals for all my other servers. This was me being kind of lazy, but I also wanted to keep the option to simply roll back to my 10.3.9 OD Master if the migration didn’t work out properly.

   In the end, after struggling with a bunch of different things, particularly the new kinds of principals in 10.4, I just realised I was being stubborn, and created an entirely new Kerberos setup. Part of the reason I was being so stubborn was due to me forgetting just how nice mkpassdb -kerberize is in 10.4. It’s a couple of minutes at most to generate an entirely new Kerberos setup from PWS/LDAP, and then it’s simply a matter of running sso_util on the other servers, and restarting any services that use Kerberos. Definitely the path of least resistance…

macosxserver | RSS 2.0 | Respond | Trackback |