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.
by 
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.
You can select more then one user in WGM by holing down shift and selecting,
or command, A to select all.
—
http://www.macprofessionals.com
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.)
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.
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 think what you’re running into is problems with your auth authority –
either your slot ID’s are not matching up with your users, or your users
are point to an incorrect auth authority.
Take another read through of this section from the article:
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
And also check up on the slot IDs – i.e.
On my server, the AuthenticationAuthority for my user account
is: ;ApplePasswordServer;
0x40ae4fe507d49f7f0000000200000002,1024 ….(RSA key etc…)
and doing a mkpassdb -dump | grep andrina you see the following:
overflow 24: 0x40ae4fe507d49f7f0000000200000002 andrina …
(etc…)
Notice how the two match up – if this weren’t the case I’d be having
authentication issues.
As an aside, the dump from Server Admin is very similar to the process
described in the article, check out the backup.ldif from that process for a
few more hints on why your passwords aren’t working – again looking at
the authentication authority.
What about the Kerberos record, does the key need to be changed on that
too?
e.g.
authAuthority: ;Kerberosv5;0x40f2cd4f041e63ca0000015500000155;twlync
[email protected];LDAP.XYZ.WISC.EDU;1024 35
147002710641224609211694329082950
<snip>
</snip>
5699226507613
208426515111783134648601013094604906541676991
[email protected]
Short answer yes. I need to write up some of the discoveries I made in
hacking through my migration, but for both AuthAuthority blocks you have
to get the new one from the new OD install on the new server.
I found slapcat’ing out the new OD directory was an easy way to get the new
keys. Search and replace out the old for the new for both AuthAuthority
blocks, making sure to keep the slot IDs (same for Apple and K).
This got me synched up with passwords working.
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