Apple Open Directory was always a weird and misunderstood part of Apple Server strategies. The Open Directory system in Lion seems to have several drastic changes to it’s structure and while moving from Snow Leopard to Lion using Apple provided Tools, I stumbled on these problems after the migration.
- Unable to add replicas
- Unable to use the Profile Manager
I tried for a while to fix it but I was unable to: it’s very complicated when you don’t know where to go and what the system expects.
The main change is how the ApplePasswordServer store it’s info: no more “authservermain” files. The built-in tools manage it well but I have no idea how to migrate from that file to the new structure which store the info in a “hidden” ldap database. I found a way around though !
You will need a badass but very dangerous software called “Apache Directory Studio“
You will also need a free machine with lion server installed and the “Server Admin tools” (VmWare machines are not OK. I was not able to create an OpenDirectory Master on a VMWare 10.7 running in Fusion.)
- Setup the 10.7 machine with the same IP and host name as your actual 10.6 machine. That means to put it on another network.
- If your Snow Leopard server is not on 10.6.8, upgrade it beforehand. Lots of things changed in 10.6.8 to allow migration to 10.7.
- Take a backup of your OpenDirectory on the Snow Leopard machine.
- If possible, shut down your Snow Leopard server.
- Restore the OpenDirectory Backup on your 10.7 Machine. You may ask me why, I’ll answer the schema. And also the incorporation of the ApplePasswordServer database into LDAP. There are numerous scripts ran by Apple tools to make the LDAP database and ApplePasswordServer compliant to the 10.7 standard. It’s simpler to let these tools do the job than figuring it out.
- Make sure you can authenticate to the 10.7 directory.
- Make a backup of your new 10.7 directory.
- Here comes the fun part: Configure Apache Directory Studio to connect to your directory.
To do this, in the software, create a new connection and fill like this
Replace the Joe blow part with your search base. - Export the “Users” container and “Groups” container to two LDIF files.
- In Workgroup Manager, export the “Computer Groups” and “Computers” to two files.
- Destroy your OpenDirectory by making the machine standalone.
- You can now create a new directory in the Lion Machine that will go in production. Use the same search base and kerberos realm as your original directory.
- Log in to that new directory using “Apache Directory Studio”. Import the “Users” ldif file to the directory.
- Import the “Groups” ldif file to the directory in “Apache Directory Studio”.
- Use Workgroup Manager to restore the “Computer Groups” and “Computers” sections.
Now you will tell me. “It seems to be OK, but I can’t authenticate !” To which I will answer “No shit sherlock, you haven’t restored the password server !”
To restore the password server:
- In the terminal of your server
sudo slapconfig -stopldapserver
sudo slapconfig -stoppasswordserver - Mount the 10.7 directory backup you made in the previous step 7
- In the terminal issue the following command:
/usr/sbin/slapadd -c -w -b cn=authdata -l /Volumes/ldap_bk/authdata.ldifIt will spit out some errors
=> bdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: Key/data pair already exists (-30995)
=> bdb_tool_entry_put: txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30995)
slapadd: could not add entry dn=”cn=authdata” (line=1): txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30995)
=> bdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: Key/data pair already exists (-30995)
=> bdb_tool_entry_put: txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30995)
slapadd: could not add entry dn=”cn=access,cn=authdata” (line=30): txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30995)
=> bdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: Key/data pair already exists (-30995)
=> bdb_tool_entry_put: txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30995)
slapadd: could not add entry dn=”cn=users,cn=authdata” (line=68): txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30995)They are to be expected as we created a new directory. - Start the services
- sudo slapconfig -startldapserver
sudo slapconfig -startpasswordserver - Try to authenticate in the terminal
login <user>
enter the password. It should work.
What you end up with is a fully working and clean Open Directory. You may now add replicas and activate the “Profile Manager”
Now, you may ask why we use Apache Directory Studio to export the Users and Groups. It’s simply because Workgroup Manager won’t keep the “AuthAuthority” of the Users alone and they will end up with a new slot of the Password service: they will lose their password. You may thank god. It’s a LOT faster with Apache Directory Studio. On the other hand, you can’t use it to export computers and computer groups because the LDAP server seems to insist on giving them a new “Generated UID” which incidentally will make all your computer groups with “Not found” machines….
There is no magic. I found the slapadd command featured up there by studying the /Library/Logs/slapconfig.log file while trying to add a replica.I have not toyed with Kerberos yet and I suspect it won’t be happy. Stay tuned !Update: May 31 2012: Kerberos seems to be healthy as “sso_util info -r LDAPv3/127.0.0.1” and “sso_util info -r .” returns proper answers.
Update: September 11 2012: Kerberos is Not working for old accounts if you use this method. According to this post on apple discussions, there is no way to rebuild the kerberos database at this time. In my case it seems to affect only SSO. I will still put it in production because it’s a minor problem for me.
How were you unable to get profile manager to work when you migrated? I guess what I mean is what happen?
The assistant would bitch about an existing directory. The error message was pretty generic.
The apple tools are doing a piss poor job to migrate in many areas. And Apple is not making it easy to improve it as we don’t have lots of technical documentation on the inner working.
I’ll test Kerberos thoroughly after my vacation. I will update the article accordingly.
Thanks for the comments.
Slightly off-topic, but I had a similar issue with creating an OD Master in VMWare Fusion. The fix in the end was to enable a second processing core… Can’t remember how I figured it out, but worked like a charm! Hope it helps to streamline your process a bit.
Kerberos is Not working for old accounts if you use this method. According to this post on apple discussions, there is no way to rebuild the kerberos database at this time. In my case it seems to affect only SSO. I will still put it in production because it’s a minor problem for me.
Changing an account password does not recreate the missing kerberos account. 🙁 You really have to create a fresh account…
Still looking for a solution
Have troubles myself with migrating through the regular way provided by Apple. I am migrating from a buggy Mavericks Server (user passwords worked til the end) to Yosemite. I got a lot of small bugs by migrating, but the passwords still worked in Yosemite, so I want to start with a clean OD DB and just import the users and their password, the rest I can setup manually.
Tried this with Yosemite? And what is the status on getting Kerberos to work with this method?
Hi !
To be frank. I stopped working on this. Too much trouble.
I paid for a consultant to implement Novell eDirectory for the company here and I can’t be happier. It’s much more resilient and powerful than Apple Tools. You also run it in linux which gives much more flexibility.
Oh ! and it’s a LOT cheaper than Microsoft ActiveDirectory.
You can read about it here: http://www.moofo.com/2014/04/11/proper-apple-open-directory-alternative-finally
Thank you for answer. I have been looking for alternatives to OS X Server for years since I ALWAYS have troubles with it. I am not a Windows dude so anything running on Linux would be great. But I wondered about Novell eDirectory, will it integrate with Server.app’s Profile Manager, for distribution of volume programs etc.?
As far as I tested, yes. But you have to follow a procedure:
https://support.apple.com/en-us/HT202285
I’m not using the Profile Manager. I will use Munki and have it deploy the .mobileconfig files. It’s a lot easier.
You can also use Meraki Systems Manager.
I already use munki and I love it, are you saying I can install stuff volume apps etc. from munki? I have never seen that mentioned. The less I deal with Server.app the better. What about Kerberos and Novell eDirectory, does it work?
Also I didn’t think .mobileconfig files could be easily pushed without Server.app to iOS devices etc. I think there is a lot of certification and validation involved. Haven’t tested it out to much myself.
I didn’t configure Kerberos here for eDirectory. Apparently it can be done, but it’s a bit hairy.