Articles August 11, 2005 at 1:00 pm

Migrating LDAP Users and Passwords to a Clean 10.4 Server

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, 2005So, 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.

<code>sudo slapcat -l /path/to/file.ldif</code>

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:

<code>sudo mkdir /path/to/backup_directory</code>

Then backup your password server database to that same directory:

<code>sudo mkpassdb -backupdb /path/to/backup_directory</code>

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:

<code>
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=
</code>

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:

<code>
sudo mkdir backup_from_new_server
sudo mkpassdb -backupdb backup_from_new_server
</code>

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:

<code>
mkpassdb -dump
</code>

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 “[email protected]: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:

<code>sudo slapadd -c -l file.ldif</code>

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:

<code> sudo mkpassdb -mergeparent backup_authserver_folder backup_from_new_server</code>

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:

<code>mkpassdb -kerberize</code>

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.

About

Andrina Kelly is responsible for anything and everything touched by, or connected to, a Mac at Bell Media, Canada's premiere multimedia company. You may recognize her name from the end credits of Canada's evening news broadcast. She has previously spoken at MacSysAdmin, JAMF National Users Conference, Apple's WWDC, Macworld IT conferences, Mac Networkers Retreat, and Canada MacExpo.

55 Comments

  • I have a few Kerberos stories to add – promotion and demotion of an OD
    master will have issues if you have a Windows PDC setup, as well….
    maybe more on that later (it still smarts!).

    The "pre-populated" LDAP search base when you go to promote to an OD
    master is the FQDN of the server – is this correct? Shouldn’t the search
    base be just the domain name? (e.g dc=example, dc=com – NOT
    dc=server, dc=example, dc=com). Just wondering…

    A great way to tell if you will be successful in getting Kerberos setup is
    whether the Kerberos field is filled in when you attempt to promote to a
    OD master. Even if it does, do not believe you have it – restart first.

    Now if someone can just figure out why 1/2 of my 10.3.9 clients offer the
    choice to be managed by the Workgroup Manager on login and 1/2 do not,
    I think I may just take a vacation……

    • “The “pre-populated” LDAP search base when you go to promote to an OD
      master is the FQDN of the server – is this correct? Shouldn’t the search
      base be just the domain name? (e.g dc=example, dc=com – NOT
      dc=server, dc=example, dc=com). Just wondering…”

      Yes, this is essentially right – I tried to make reference to this, but obviously not
      very clearly, for my testing I indeed just had “dc=example,dc=com”, but it does
      pre-populate with “dc=server,dc=example,dc=com”. If you’re setting up from
      scratch, rather than trying to migrate there’s no real reason why you shouldn’t
      leave to full pre-populated version in there though.

    • I’ve been trying to follow your otherwise excellent instructions for migration from 10.3.9 to 10.4 Server at AFP548.

      The first command, slapcat indeed creates a large ldif file, but I get stuck when trying to backup the password server database. The command you have quoted, "mkpassdb -backupdb" does not seem to accept that flag as a valid one. All I get when I run that command is the verbose error telling me which flags are valid. backupdb is not one of them, and no file ends up being created in the target folder I designate. Can you help me in understanding what is happening here? Thanks.

      • That is very curious – what version of server are you trying to run the
        backupdb on? Are you using sudo, or are you root when you try the
        command?

        I noticed on a 10.3.8 server I have here the man page for mkpassdb is
        different to the 10.4 server – I don’t have a 10.3.9 server to hand to
        check out the man page there…. I’d suspect there may be something afoot
        there with your machine. Do you apply combo updates, or incremental
        updates to your machines? I’ve found the combo updates to be more
        reliable in actually updating everything that needs to get updated… try
        a combo update to 10.3.9 and try the mkpassdb command again.

        • I had (of course) made a backup of my 10.3.8 installation before attempting the 10.3.9 update (which was in turn merely so I could export the users with the correct schema for processing into 10.4).

          After my first attempt and finding the -backupdb flag was not accepted, I re-cloned and re-updated the server from 10.3.8 to 10.3.9. This time, strangely, the flag was accepted and I was able to export the password database. The only thing that was different this time around was that after the 10.3.9 update there is an additional security update. I did not apply the further security update but rather attempted the export as soon as I could. YMMV

          All I can suggest is to try again!

    • Ok, where you say do the global search and replace of the RSA key in the exported LDIF file (presumably you do it for the Kerberos entry also, right ?), how did you do this ??
      The LDIF export is in a 78-column format with line breaks, whereas the password dump has the RSA key as one big string.
      I’m currently writing a Perl script to do it!

      How did you do it ??

      Jon

      • I just wrote 100 lines of perl to do it, which I’m happy to give to anybody who wants it, but it really sounds like there was a much easier way.

        Jon

        • Ok it works! BUT!
          I can’t get the Linux clients to work, I have no idea why.

          I am exhuasted right now, I will post some error logs tomorrow.
          Thanks all!

          Jon

  • I’m taking delivery of a shiny new xserve next week and I will need to perform
    this very task. I’ll let you know how it goes… expect one of two possible
    strong emotions (and possibly foul language) in my followup.

  • I see the part of these directions that say that your seach base needs to be
    the same, mine isn’t. I’m getting the errors you speak of. How do I change
    the search base for one of the servers?

    • When setting up the OD Master on your new 10.4 server, there’s a window that
      drops down immediately after you promote from stand-alone. In this window
      (near the bottom) is where you can stipulate your search base to be the same.

      • Now I’ve surmounted the "missing backupdb flag" issue, this is my next hurdle too. I’ve clean installed 10.4 server on a new machine and assigned it (as far as I know) exactly the same machine name, IP address etc as the old server (which is offline for now). I try to slapadd the ldif file and it gives me precisely the same error regarding the incompatible search base. Directory access on my 10.3.8 server had a search base of "dc=jwcs,dc=nsw,dc=edu,dc=au", and I’ve tried the config area on my new box to match that, but slapadd still fails. Does it matter if the search base includes the actual machine name (ie "dc=dreadnought,dc=jwcs,dc=nsw,dc=edu,dc=au") or will that muck it up? The error message slapadd is giving me mentions other LDAP parameters like "cn=users" (I think… might be wrong there). Really need a 4-line heads-up on this LDAP business… Thanks in advance if you know the answer and post it here!

        • Ok, I think from what you’ve said the search base on your 10.4 machine is as
          follows: "dc=dreadnought,dc=jwcs,dc=nsw,dc=edu,dc=au" and the search
          base on your 10.3 machine was the following:
          "dc=jwcs,dc=nsw,dc=edu,dc=au"

          If this is the case, this would be where you’re running into issues. When you
          promote your 10.4 server to an OD master, check the bottom of that drop-down
          window and make sure that search base is the same – I had exactly this issue
          when I was testing for the article, as soon as I got my search bases matching,
          things got a whole lot better.

          • Where are you trying to state that the dc=local doesn’t exist? in the
            drop-down when promoting your machine to an OD master, you should
            be able to set this here.

  • Can you provide a little more detail for troubleshooting – have you checked your
    logs for instance? Did you ensure you made a backup of the 10.4
    password database before doing the slapadd command to the new server?

    • I had the same experience when trying to merge to a new 10.4.1 install. Users
      worked fine, passwords didn’t. I will retry with 10.4, perhaps next week.

  • I’d change the home dirs once you’d got all your users into Workgroup Manager
    – it sounds like you’re moving all your users, so a simple select all, and change
    the path ought to sort you out.

  • A note on the LDAP import: Most of my users have no home directory.
    However, the import requires a "homeDirectory:" entry in the ldif file. This
    should be followed by either the path to the home directory, or a "99" for None.
    Without this line, the LDAP importer will reject users.

    I did a search for inetOrgPerson to find all the users (as opposed to groups,
    configs, etc.), and made sure each user included either a real homeDirectory
    entry or a "homeDirectory: 99".

  • First a thanks to andrina. Second, I ran into a caviot that I didn’t expect. I built
    a test server and migrated my settings to that server, then brought up my new
    server. The problem? Two of the sam serial numbers on the network. It seems,
    but I’m not positive, that a serial number conflict turns of the PWS of the
    offending server. In my case it turned off the production server, not the DHCP’d
    test box.

    And definately watch out for the homedirectory issue.

    peet

  • There seems to be several of us having the same problem. Let me give some
    history and maybe this can shed some light on it.

    After running backups mentioned here, I ran a straight upgrade on my server
    from 10.3.9 to 10.4. Upgrade ran fine, smooth, no errors… gave me a BLANK
    OD DB when it was done (fair warning to all of you planning a "simple"
    upgrade…) So, I thought, I’ll do it the hard way from the article. I ran the
    backup for current passdb, imported the ldif file (void of root and my admin
    user, all users/groups/etc came in), and ran the mkpassdb merge, which ran
    fine (alarmingly fast, as someone else reported…) and after this, NO imported
    users could auth. I changed the passwd on one user, and STILL could not
    auth (rebooting each time I tried a new thing). Finally, I changed the user to
    CRYPT password, got an error, changed back to OD passwd, set the passwd,
    and can now auth as that user.

    Now, for the "more". I figured "must be a 10.4 thing", so I upgraded the box
    to 10.4.2, standalone, re-setup ODM, tried again, same thing. After four or
    five attempts at this, I thought, "must be a 10.4.x thing" and started with an
    existing 10.3.9 server. Same thing, with ODM running, KERBEROS working,
    import ldif file, users/groups fine, mergeparent on mkpassdb, and NO auth
    from previous password db.

    I have about 3700 users.

    I’m hoping this info "jogs" someone’s memory… ??

  • First thank you so much for the time you took to helping us and writing the
    instructions.
    I have two questions about the migration.

    1. I did everything as you instructed and I had no errors it looked like it
    worked great. But when I went to login in as a user I get an error: (You are
    unable to log in to the user account “any user” at this time. Logging in to the
    account failed because an error occurred. The home folder for the user
    account is located on an AFP or SMB server. Contact your system
    administrator for help.) The second error that I am in countering is when I
    go to create a network mount for home directories I get Directory Services
    error. An unexpected error occurred while writing to directory Services. This
    started after I flowed your instructions. Please understand I ma not saying
    this is anyone’s fault but my own for not knowing more. But if you or anyone
    has any idea I would love to know why is happing. Thanks again for your
    time.

    Second questions. Not able to add new users Error on type of eDSRecord
    found

    Thank you

  • I wish I had a solution but we can at least commiserate! I started playing with this on a test server on our network and was overjoyed when it worked. I am replacing several of our servers with shiny new xserves so I have set up the new servers plus a couple of older desktop computers to mimic our other servers on a isolated network. But after setting up my OD master on my test network, importing users and merging the password database, I end up not being able to authenticate as one my imported users. Tried this several times with the same results. Comparing log files with my test server on the real network shows no differences what so ever! A quick test watching the /L/L/ApplePasswordServer.log on my existing OD master does prove that my test server is actually authenticating against it, instead of itself.

    • Yippee! Thank goodness for people smarter than me! The RSA key update to this article is the fix for the new OD Master not authenticating your imported users. Thanks!

  • Thanks for the article, very useful information.

    I’m leapfrogging from a 10.2 server to a 10.4 server and I’m trying to figure out
    how to export passwords from the old 10.2 box. I have a mixture of crypt and
    Open Directory passwords and the mkpassdb utility doesn’t offer the option to
    dump the password database in 10.2. Is there another way of exporting the
    password data under 10.2?

    Thanks.

    • So, going back a bit in history here, but when I did my 10.2 to 10.3 migration I
      relied heavily on netinfo… specifically coping /var/db/netinfo/network.nidb
      from the old server to /var/db/netinfo/network.nidb on the new server and
      coping /var/db/authserver/authservermain to /var/db/authserver/authservermain
      on the new server. There’s a lot more massaging that needs to be done to the
      new server after doing this, if you’re changing IPs and hostnames… Once
      netinfo’s migrated nicely you can do the netinfo to LDAP migration in Server
      Admin. Really, not a nice way of doing things, but with all the right ducks in
      the right order in your row, it should go fairly well – and as usual, play with this
      on a testing server first, not on your production machines, and give yourself lots
      of time to do it in!

      • Okay… I have been reading lots about this, but feel I’m real close to having
        the setup the way I need.

        – I’ve got the Open Directory setup as Master.
        – DNS is working for my .local as well as nameserver.sub.domain.com, and I
        have instructed LDAPv3 to use the "domain.com" as the search base, hoping
        to associate this with kerberos…

        Here’s the deal… All my 10.2 users are in the network.nidb. I tried a ‘dumb’
        upgrade but found the directory services were munged… So, I figured I
        better do what everyone else suggested, and clean install…

        I tried copying the .nidb to the server, but this was before I had OD working
        right… Now I have another clean intstall, and hope to avoid further issues:

        My question: It is worth the trouble of trying to copy/transition
        the .nidb and authserver files, converting them to the LDAPv3 and OD???

        ( I could export them without the passwords through WGM; restore around
        95% of the passwords from a clear text database used to manage clients use
        of our facility. While 25+ Staff would be a little peeved; this ma not be too
        bad…)

        Can I do this .nidb/authserver copy/transition now, and expect to get
        kerberos working after the above transition from netinfo? (or should I
        kerberize first, then import?)

        Is there any good how to’s anyone can point me to rergarding moving users
        and passwords from 10.2 netinfo/authserver to a clean 10.4 LDAPv3/OD/
        Kerberos arrangement? (I have looked and looked… thought I found a good
        guide, but the links and site appear to be out of date.)
        link: http://www.it-enquirer.com/main/ite/more/tiger_guide/

        Anything like this that is still active and available? I feel like I missed the boat
        not having a 10.3 intermediate upgrade. I’m about to try the WGM export
        scenario… More later.

        Config:[Still running the old 10.2 from a cloned drive, now prototyping the
        new install on a near duplicate CPU… We have the old Mac OS X Server G3
        400 with a 900 G3 proc upgd.]

        • Okay… changing the search path for LDAPv3 in Directory Access to the
          nameserver.sub.domain.com failed… (I used my own server’s name, not the
          literal text you see here)

          I think this is because I failed to use the "nameserver.sub.domain.com" during
          setup, and it’s now stuck at "MacServer.local" (dc=MacServer,dc=local)

          Do I have to start over? (or can I change this… Do I need to change this? The
          search path changes I made in Directory Access for LDAP did not show up in
          the Server Admin; LDAP settings… they seem stuck at .local and I’ve since
          reverted.)

          • it-spud

            So… After a brief interview with some staff here… I’ve been exploring
            exporting from WGM 10.2, and manually restoring some passwords; while
            forcing staff (5% or so) to make new ones. (and avoidiing the whole netinfo/
            authserver mess… What’s weird here is:

            The format appears to be strict (except for an occasional plist style entry, it’s :
            delimted.)

            Why would I be seeing these ‘anomalies’ in the form of XML, while the
            majority of the records are simple : delimited single line per record?

            I haven’t figured anything obvious here… the records aren’t particularly
            special; just seems like a random few.

          • it-spud

            I’m a dork… I see the XML field and I’m pretty sure I never set these particular
            settings for these folks… (automounts, email, and such) Some WGM 10.2
            detritis I presume.

  • I didn’t see this mentioned specifically so I need to ask before I foul things up. Is there going to be a issue with the different realms? The old server has realm of OLDSERVER.MYDOMAIN.COM and the new server has the realm NEWSERVER.MYDOMAIN.COM. When the old KDC database is imported/merged won’t that confuse the new KDC? TIA.

    • I had different kerbeos realms on the servers I was playing with here setting this
      up, and kerberos is currently working brilliantly for me on the new server, so I’d
      say you’re all good to go – but as usual, I tested all this on a non-production
      testing server, I’d advise you to do the same.

  • Our concern is that the OD is responsible for SMB for our Windows Clients.

    Is there any other work we need to do when moving the OD to a fresh 10.4 server so that the windows user can enjoy their PDC rights?

    Thanks

  • I personally don’t have a PDC here to test with at the moment, however, there’s
    no reason why you shouldn’t test this yourself and let us all know how it goes…
    I do all this kind of work in a testing environment (i.e. separate from the public
    network), I strongly suggest you get one that mirrors your setup as closely as
    possible to try is out.

    • Adrina,

      We will try moving the data and see what gets ported over for PDC. I understand that Mac OS X Server 10.3.9 and 10.4.2 both enjoy Samba 3.0.10 so there is no substantial difference in Samba as far as Panther 10.3.9 and Tiger at the moment and if I also understand correctly OD in 10.3.9 is updated to reflect 10.4.2 wich means that what ever synching tool betwenn OD an tdb files should be engaged the same way.

      All this said there should be no other work other than copying over the TDB files from /var/db/samba & /var/samba over to 10.4

      The real concern is that Tiger appropriatelly creates groupmapping for Windows style domain groups where as with Panther administrators had to manually create groups with the net group command so my final suggestion is the following.

      Transfer OD to Tiger
      copy tdb’s for samba but do not apply just yet

      Turn on Windows services as a PDC
      check the SID number for the new PDC in tiger and check the net groupmap list to see if the grouping has been applied correctly

      Go back to 10.3.9 and look for the SID number with the net command.
      Copy it on paper, apply it with net command to the new PDC in Tiger with net command (man net SID options).

      Now the domains will be seen as identical because of the common SID and the pc’s will not have to be re joined to the domain.

      You can also check your Workgroup Manager to see if the Windows list still hold s all of the computers info.

      I would definitelly try this on test enviroment first.

      Also the newer issue with PDC in tiger is introduction of ACL’s and recreating the ACL’s rights for the Users profiles in a roaming enviroment.

      Later

  • Actually, I suspect you were running into RSA issues – check out the recent
    changes to the article, and try again – my testing was migrating to a server with
    a different name and IP address….

  • Hi,

    I try this method to export users without loosing their passwords, but my OsX
    server (10.3.9) is configured as a "stand alone machine" and i see in /var/db/
    netinfo directory I have only local.nidb file.
    No network.nidb at all.

    So if I try to send first terminal command (slapcat) I obtain this error:

    /etc/openldap/slapd.conf: line 20: could not open datasource "/var/db/
    netinfo/network.nidb" flags [00000401]
    slapcat: bad configuration file!

    How can I solve this thing?

    Thank You in advance….

    • Well – as a standalone server you only have a local netinfo database, and
      not an LDAP setup…. you’re going to be better off migrating your
      local.nidb over manually along with the /var/db/authserver. If you’re
      migrating to a new server which you’re going to set up with a new IP and
      name, you’re going to have some manual tweeking of the nidb required
      however…

      • Do you know some link or documentation that explaint step by step the
        migration of local.nidb database?
        I hope I can preserve users password… 🙂

        In second instance, it is possible to convert a Stand Alone server in an Open
        Directory Master, also preserving Users and Passwords?

        Bye..

  • I believe the knowledge you’re looking for is actually information on
    NetInfo. From what you’re saying, all your clients are currently there –
    Netinfo and LDAP are two completely separate entities. You’re going to
    be looking to do a migration – check out the Netinfo Migration under
    the "Protocol" tab in the Open Directory section of Server Admin

  • Once everything is up and running my new server will be switched over to the
    IP address/DNS name of the old server. Is there anything I need to worry
    about for this switch?

  • Thank you for you article, it has given me hope. However, I follow all the
    steps, but in the end I can’t login to the new server with a network user.
    Here is my story:

    I was able to export all my data from my panther server with slapcat.
    However, after following your steps, I was not able to import the data using
    slapadd. I would also get an error saying that there was a parse problem on
    the last line. I found on the internet that it may be a problem with
    something that might have been opened and not closed. I searched my ldif
    file for all the characters that open something like ({[<‘" but all I found were
    things like "O’Dell" as a last name. I took all the apostrophes out of names
    just in case, but to no avail. It still had the same error.

    I found that if I just left the user entries in my ldif file it would import fine,
    but I wanted the computer lists and other goodies. I tried two things:

    First, I found that if I connected to my panther server with the tiger version
    of Workgroup Manager I could export more of my preferences and then just
    import them, including the users. Then I tried to do a merge of the
    password databases. I could do a dump using mkpassdb and see that all the
    passwords had imported, but when I tried to login I couldn’t. I could login if
    I reset the password in Workgroup Manager. Moving the users over this way
    seemed to be okay, but I questioned whether or not was why the passwords
    didn’t work.

    So then I tried to import an ldif file with just my user record in it, and then
    did a merge. I still couldn’t log in.

    Why is it that the passwords seem to move yet somehow don’t let me login?
    Thanks for your help.

  • I am sure I am not the last person to migrate to Tiger, so I thought I would pass along this regular expression I used in TextWrangler to replace the RSA keys. It will find both the ApplePasswordServer and Kerberosv5 keys. Make sure to check the "Use Grep" box in the find and replace dialog. Enter "35\s(.*\r\s)*.*\sroot" as your search string and "35 newkey root" as the replace string (without the quotes!).

    • Oops! Just realized the escape slashes didn’t make it in there! The search string should read:
      <code>35\s(.*\r\s)*.*\sroot</code>

  • Hello All,

    I was having an authentication issue after having followed these instructions
    where everything would go fine except passwords were not working. I could
    not update passwords nor su to anyone’s account. However I figured out the
    issue was one of two things.

    1. I had 2 "VPN MPPE Key Access User" accounts after importing my ldap file.
    So i deleted one before importing the passwords.

    2. On the search and replace of the RSA key I noticed my text editor was not
    finding every instance of the key. I think this has something to do with line
    breaks but I had to search for the key about 10 time doing about 10 replace
    all commands. Rather than search for the whole key i would search for the
    first 5 numbers and copy the whole key again each time it found it, and then
    doing a replace all. This I think only happened on the kerberos part of a users
    record where it lists the RSA key a second time for each record.

    After doing both of those I am up and running on a clean install with all my
    ldap users, preferences, and passwords working.

    AFP548 ROCKS!

  • I have sucessfully completed this operation a couple of months ago … thanks for the inspiration … I mean information 🙂

  • This just keeps getting wierder.

    All instructions followed, and I can su to any user from any user with the correct password, that part is GREAT and thank yoU!!

    BUT-

    Now the AFP and SMB clients can log in to their client machines just fine, but the Fedora Linux clients (configured using authconfig) cannot.

    The error in the clients’ logs is:
    pam_ldap: error trying to bind as user "uid=username,cn=users,dc=department,dc=university,dc=edu,dc=au" (Invalid Credentials)

    I’ve changed some of the entries there for privacy, not that it really matters here.

    The search base is set to: "dc=department,dc=university,dc=edu,dc=au"

    The wierd thing is that I can do ldapsearch, finger and id from the client and get exactly the right info, I just can’t log in.

    I’m beginning to wonder if I shouldn’t have Kerberized the server, not that we seem to have a choice with that.

    Any clues anybody ?

    • Ok, its working now, and i think the only thing i did differently this time was NOT run mkpassdb -kerberize

      Phew, so now…the options! to enable kerberos capabilities or not so the linux users can change their passwords – or instead to use osxpass, or not.

      that is the question…..

      jon

  • I just tried an import of the ldif file on a Mac OS X Server 10.4.8. I hit a major problem. When I try to run

    sudo slappadd -c -l file.ldif

    I get an error

    sudo: slappadd: command not found

    I even tried sudo: slappcat as a test and again I was informed that slappcat was not found.

    Any suggestions?

    I double-checked that Open Directory is running, that LDAP Server is running, that password server is running and Kerberos is running.

    This test server was previously an Open Directory Slave. I changed it to an OD Master and rebooted it before attempting the import.

    • Nevermind. I can’t type. I see now that I put in an extra ‘p’.

      Is there any reason whey the slappcat and slappadd commands are preferred over the method provided by Apple for exporting and importing the user and groups via WorkGroup Manager?

  • This is a great article, and except for the fact that I had already imported my users and groups from 2 export files from the old server, it probably would have worked. I did notice that once the users were imported from the export files I mentioned, an import of the groups neatly put ll the users in the groups like they were on the old server. I am not sure however if the users would be added to the proper groups using your method.

    It’s a small price to pay though for being able to retain passwords instead of looking like an idiot for losing them for the umpteenth time because Apple’s OD replica scheme for leopard server seems fraught with terrors. I had to do a wipe and reinstall yet again because replication between my Master and Replica suddenly went south one evening and the server kept creating replication sync files that grew forever until the hard drive was full on the master. THAT SUCKED!!! No one has been able to tell me why, or how to make that stop, so a wipe and reinstall was my only option.

    My advice to anyone wanting to use an OD replica is, DON’T DO IT!!! You don’t gain much, and if something is already wrong with your OD LDAP database, the promotion will probably fail. For whatever reason, something will eventually go wrong and hose your LDAP database anyway. I NEVER had these problems with Tiger Server. This has happened to me upwards of 6 or 7 times with Leopard. I cannot use Snow Leopard because the servers are G5’s. I get everything back up and it runs for weeks, sometimes months, and then one day I come in and BAM users cannot log in, or password server is stopped, or OD boot drive is full. Whatever it is, it all traces back to OD replication.

    These problems may be fixed in Snow Leopard, and now in Lion Server, but I will not create another replica in OD ever, until someone at Apple can guarantee me that I won’t be screwed yet again and have the whole company looking at me like I’m an incompetent buffoon. I will NEVER AGAIN deploy Leopard Server in a critical application.

  • This article very good, I like, there is no article on electronic products can look to me, weexchange X315e Smart Phone

Leave a reply

You must be logged in to post a comment.