Tiger to Leopard Server Migration, Part Two
In Part One, I described the installation of Mac OS X Server 10.5, and the migration of settings from my old 10.4 Server to the new one, for a couple of services. In this article, I’ll go through the importing of user accounts and data from 10.4 (Tiger) to 10.5 (Leopard).
Migrating User Accounts From LDAP
The method that Apple recommends in their Upgrading and Migrating manual is to select user accounts in Workgroup Manager (WGM), and choose Export from Server menu. This creates a comma-delimited text file of your user account data which can be imported with WGM in Leopard. However, the passwords are left out of the export.
I don’t want to manually change the passwords of every user on my server, so I’m doing a different approach. This thread on afp548 was of some help. Instead of getting the user records using slapcat, I used ldapsearch on a running server to get only the user records:
ldapsearch -v -x -D 'uid=dirmanager,cn=users,dc=netmojo,dc=ca' -W -b "dc=netmojo,dc=ca" -s sub "(objectclass=apple-user)" > users.ldif
There are two things to note about the above command: my directory manager account is named “dirmanager”, which is not the default name for the directory manager. This is the account that you would authenticate to the directory with in WGM. However, any account that has global read permissions in your directory will do.
The second thing to note is the search base, dc=netmojo,dc=ca. Yours will be different. Make sure that the search base in your ldif file is the same search base that you setup in Leopard’s Open Directory.
Next, I opened the users.ldif file in my text editor, and removed some old accounts, the root account, the directory administrator (dirmanager) account, and the ldapsearch stats from the bottom of the file. As the AFP548 article recommends, I also did a search and replace on the 1024-bit RSA key, swapping out the key from my 10.4 server with the new one in my 10.5 server. You can get the new key in 10.5 by running “mkpassdb -key”.
Note that Open Directory and Kerberos are already up and running in my 10.5 server. I covered that in the last article. To import the LDIF file, run (substituting your values appropriately):
ldapadd -v -x -D 'uid=dirmanager,cn=users,dc=netmojo,dc=ca' -W -f /tmp/new-users.ldif
After restarting WGM, all of my users appeared in the Accounts tab.
You may have noticed that the LDIF file contains the same string of gibberish in the userPassword field for each user. OSX Server stores the passwords in a separate password database, which you can access with the “mkpassdb” command. I will come back to this later.
Migrating Computer Accounts
Just like the user accounts, I imported the client computer accounts from LDAP using ldapsearch, a text editor, and ldapadd.
ldapsearch -v -x -D 'uid=dirmanager,cn=users,dc=netmojo,dc=ca' -W -b "dc=netmojo,dc=ca" -s sub "(objectclass=apple-computer)" > computers.ldif
Editing computers.ldif in my text editor, I did a search & replace on the RSA key, removed the entry for the server itself, removed an old computer, removed the “apple-mcxflags” attributes, and the stats from the bottom of the file.
One difference between 10.4 and 10.5 seems to be the addition of an “ipHostNumber” attribute in the computer records. You can add these to the LDIF file (ipHostNumber: 123.456.789.111), or simply fill out the IP Address field in the Network tab of the computer section of WGM after the ldap import. Importing the LDIF file is the same as it was for users:
ldapadd -v -x -D 'uid=dirmanager,cn=users,dc=netmojo,dc=ca' -W -f computers.ldif
The first time that I tried, I got an error:
ldap_add: Naming violation (64)
additional info: value of naming attribute 'cn' is not present in entry
That was strange, because the cn attribute was present. I moved it to the top, right under the dn: attribute, retried, and it worked.
Migrating Passwords
To migrate user passwords in Mac OS X, it is necessary to export them from the password server using the “mkpassdb -backupdb” command, as noted in the AFP548 article. Before proceeding with this method, you should read it through to the end. I encountered problems during the process, and there could be repercussions that I have not yet discovered. It might be worthwhile for you to manually change passwords, as Apple recommends…
On the running 10.4 server:
cd /Volumes/disk2/passwords
sudo mkdir tiger_passwords
sudo mkpassdb -backupdb tiger_passwords
Do the same in 10.5:
cd /Volumes/disk2/passwords
sudo mkdir leopard_passwords
sudo mkpassdb -backupdb leopard_passwords
In my case, “/Volumes/disk2/passwords” is a directory that exists in both my 10.4 server, and my 10.5 server. So this path is probably different for you, or maybe you need to copy the “tiger_passwords” directory over to your 10.5 server some other way.
I am assuming that in 10.5 you have a configured and running Open Directory and Kerberos server. This being the case, merge the differences between the tiger passwords and the leopard passwords, preserving the current identity of the password server by running:
cd /Volumes/disk2/passwords
sudo mkpassdb -mergeparent tiger_passwords leopard_passwords
Problems with Kerberos
As the AFP548 article suggested, I ran “mkpassdb -kerberize”, since I am using kerberos on my network. I’m not so sure that it was a good idea. After a reboot, the Kerberos server wouldn’t start, and these errors appeared in my kdc.log:
krb5kdc: Cannot find master key record in database - while verifying master key for realm LEOPARDSERVER.NETMOJO.CA
And in my kadmin.log:
kadmind[332](Error): Cannot find master key record in database while initializing, aborting
To fix the broken Kerberos server, I had to recreate a Kerberos master key. Basically, I had to wipe out the kerberos database, and start over. This thread on a Kerberos forum at MIT was of great help; I basically followed the given instructions:
cd /var/db/krb5kdc
rm -i * .*
(say 'y' to everything except kadm5.acl and kdc.conf)
kdb5_util -r LEOPARDSERVER.NETMOJO.CA create -s
After that, I rebooted, and the Open Directory panel of Server Admin reported that Kerberos was once again running.
Most users can authenticate, however one of them cannot. Examining that user’s record in WGM, using the “Inspector” (to enable it, check off “Show All Records and Inspector” in the WGM Preferences) I found that it is lacking a Kerberos attribute that the other accounts have. Other accounts have two “authAuthority” attributes, one for “ApplePasswordServer”, and one for “Kerberosv5″. The one that doesn’t work has only “ApplePasswordServer”. I have not yet resolved this issue, but I could probably just delete and re-add the account, or just change the password. I did the latter, and I can login with SSH using that account and the new password.
Migrating Home Directories
Moving home directories is about as simple as it gets: I created a tar archive of them in my 10.4 server:
sudo tar cvf /Volumes/disk2/homes.tar --exclude="Caches" /Users
Then extracted the file in my 10.5 server:
cd /
sudo tar xvf /Volumes/disk2/homes.tar --keep-existing
Check to make sure that the home directories are owned by the appropriate users, and adjust if necessary:
cd /Users
ls -l
sudo chown -R someuser:staff someuser
Migrating SSH Keys
To prevent my users from getting scared by this message when they try to SSH to the new server (yes, I have the kind of users that use ssh):
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
… it is necessary to copy the SSH keys over from the old server. This is straightforward; just copy the /etc/ssh*key* files to the new server:
cd /Volumes/disk2/backup_of_10.4/private/etc/
tar cvf /tmp/oldkeys.tar ssh*key*
ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_key
ssh_host_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
cd /private/etc
tar cvf /tmp/newkeys.tar ssh*key*
...
tar xvf /tmp/oldkeys.tar
Migrating IMAP Email
This article is already way too long, so email migration will be in my next article of this series :).
December 19th, 2007 at 14:08
Why not simply use the Server Admin GUI to Archive/Restore Open Directory database (users accounts and passwords) ?
December 20th, 2007 at 10:42
That’s a good question, and I wonder why Apple doesn’t recommend it in their migration documentation. It could be because there have been schema changes to one of the components that make up the Open Directory system, outside of the user accounts.
Have you tried it?
December 21st, 2007 at 15:51
Yes, we migrate from 10.4 to 10.5 this way.
See Upgrading and Migrating manual pages 34 and 41
about OD Archive/Restore.
Thanks for great articles Brent.
January 28th, 2008 at 15:33
Please note that on Mac OS X Kerberos conf files and principals live in /var/db/krb5kdc/ and not in /var/kerberos/krb5kdc/ as the above MIT forum example suggests.
January 28th, 2008 at 15:45
Ivailo Djilianov: thanks! fixed.
January 30th, 2008 at 15:55
Setup:
Xserve G5
OD Master
10.4.10
3gb ram
migrating to:
Intel Xserve
Dual 2 GHz
5 gig of ram
10.5.1
I am just migrating users and passwords at this point. I exported the file and deleted the directory admin and administrator accounts, and I modified the Password and Kerberos entries to match the new server. When I import the file, It gets hung up on the first user and terminates with this error:
modify complete
ldap_add: Server is unwilling to perform (53)
additional info: no global superior knowledge
No user is added to Open Directory. Does anyone have a clue to why it may be hanging up?
January 30th, 2008 at 16:14
According to: http://www.openldap.org/faq/data/cache/1322.html, the partition that you are trying to put the user into (i.e., dc=foo,dc=bar,dc=your,dc=com) probably doesn’t exist. You’ll have to add those to the top of your import file, so they get added before the records that go into them.
For example:
# deptartment, company.ca
dn: dc=department,dc=company,dc=ca
dc: deptartment
objectClass: domain
# users, deptartment, company.ca
dn: cn=users,dc=department,dc=company,dc=ca
cn: users
objectClass: container
January 31st, 2008 at 08:26
Did the file you used have this info? If it did not, then why did yours work?
January 31st, 2008 at 09:02
Another thing I noticed is that the value for apple-user-homeurl in the file is encrypted, and when I ldapadd is shows the value to be of the old server. I don’t know if this makes a difference. I will try the above and get back to you.
January 31st, 2008 at 09:07
Well, now I get:
modify complete
ldap_add: Undefined attribute type (17)
additional info: dn: attribute type undefined
January 31st, 2008 at 09:30
I put my users in the default location in my base DN. When I defined the Base DN in the Server Admin, it was created for me.
Have you used Server Admin to change Open Directory’s role to an “Open Directory Master”? You can also achieve this by running the slapconfig command (see the man page).
slapconfig -createldapmasterandadmin diradmin your-password 1000 “dc=netmojo,dc=ca” MYREALM.CA
Regarding your undefined attribute, there is probably an attribute in your old records that doesn’t exist in leopard. Any idea which one was left out when you added the records?
January 31st, 2008 at 09:39
The new server is already setup as an OD Master, with the directory administrator account. When I did a slapcat -l and looked at that file, it seemed to have the info you are discussing. Using ldapsearch does not produce the exact same results in terms of what is precisely in the file.
January 31st, 2008 at 09:44
It would appear then that the base DN in your already setup OD Master isn’t the same as the DN that you were trying to add your users to.
January 31st, 2008 at 10:10
The searchbase was different. I just clicked through the setup on the 10.5 server. It added the server name in the searchbase. The old server was not like that. I demoted it and repromoted it to start from ground 0 and try it again. Thanks for your patience and help.
January 31st, 2008 at 10:39
You are welcome. Let me know how it works out. I ended up having more troubles with Kerberos (see my latest post). Single Sign-on wasn’t working. That was at least partly due to the incorrect or missing authAuthority attribute with the “Kerberosv5″ data.
If I were doing it again, I would use the GUI to add a test user, then use ldapsearch to get the proper Kerberosv5 data from the new user’s record. I’d then add that attribute + data to my LDIF import file by search & replacing the old data, or adding it if it doesn’t exist, using sed, a perl script, or a quality text editor like TextMate.
Ringo, the first commenter, said that he successfully used the Archive & Restore functions of Server Admin: Open Directory to migrate. This would, I presume, copy the user data including passwords, and the entire Kerberos setup to the new server. I wonder how that is working out…
January 31st, 2008 at 10:46
Well, I started over and when I run ldapadd now I get an error:
ldap_add: Object class violation (65) additional info: object class ‘inetOrgPerson’ requires attribute ’sn’
The thing is there are sn attributes.
January 31st, 2008 at 10:54
There must be at least one record either without the sn attribute, or with an empty value in an sn attribute.
February 8th, 2008 at 15:32
Ok. Here is an update. After talking to an Apple SE, he recommended archiving the the OD db from the old server and importing it to the new server. The caveat is that the new server must have the same IP address and hostname as the old server. When you promote the new server to OD master, you must make sure to enter the same search base and kerberos realm and then import the OD archive. I did this on a separate, isolated network. Another issue is DNS. Since we use a separate DNS server that is windows based, I had to setup the new server with DNS so it could resolve itself. After I imported it, I tested it and made sure I could login and it worked. I then used changeip to change the ip address and hostname so I could have the new server and old server co-exist on the same network so as to enable users to migrate their own data. Remember to changeip -checkhostname before running it to make sure the host name and IP address resolve. If there is a problem, it will let you know. The other thing I did out of superstition was to reboot after each change in the process. After all was done I connected to the production network and ran software update. So far so good.
March 5th, 2008 at 10:08
Im about to migrate to leopard at a school site with tons of teacher and student accounts.
Can you go more into depth about your step on migrating accounts:
“Moving home directories is about as simple as it gets: I created a tar archive of them in my 10.4 server:
sudo tar cvf /Volumes/disk2/homes.tar –exclude=”Caches” /Users”
I appreciate it.
March 5th, 2008 at 11:36
Do you want more detail on migrating accounts, or on the part that you quoted, which is migrating home directories? If the former, please note the first 3 comments on this post.
Do you have two servers for this upgrade, or are you upgrading a single server that is now running Tiger?
March 5th, 2008 at 14:49
Thanks for the speedy response
I would like more detailed information on the migration of home directories.
When you write about creating a Tar and etc.
I have an xserve with three drives: 80gb(running the os), 700(for the directories) and another 700 for backups(sparse).
I will also have a g5 dual 2gig running as a replica to my xserve.
thanks for all your help. looking forward to your response.
March 8th, 2008 at 20:27
All that you need to do is move/copy the data. I used tar, which is a tried and true way to copy large numbers of files and directories, preserving permissions, access and ownership data. I essentially created an archive of the data with tar, then unpacked that archive on the new machine.
For more information on tar, open a Terminal, and run ‘man tar’. Also run ‘tar —help’, which gives you all of the options for tar.
As an example, if I wanted to tar the /Users directory, I would run ‘tar cvf myarchivefile.tar /Users’. To untar that archive somewhere else, I’d run ‘tar xvf myarchivefile.tar’. tar takes other options as well, such as —exclude. In the blog post, my example excludes the Caches directories; I could add to that “.Trash*” to avoid copying files from user’s trashes.
Aside from tar, there are many other ways of copying files that preserve permissions and other attributes; rsync is another of my other favorites.
March 14th, 2008 at 07:38
Brent
I’m trying to distill the information posted here, but I think I’m a bit confused. Here is my scenario:
G4 MD 10.4Server (OD Master) hosting xServe RAID. New Xeon xServe to replace G4 MD as host and OD Master). Separate Replica to be deployed afterwards. About 100 very stubborn users.
Gist of the problem: Trying to move over the old OD to the new Xeon host. Xeon will have a new IP and DNS name, but the old DNS name will be added/appended/aliased to the current DNS A record kept by our Hospital. What, exactly, do I have to modify? If I follow the OD backup and restore method (easy way), what exactly needs to be modified, other than removing of certain user accounts (as recommended). Sorry for asking for the easy way out here….
March 14th, 2008 at 10:57
Hi Barry,
I haven’t tested your scenario specifically, and I don’t have time at the moment to dig into the documentation (for what thats worth), so bear that in mind. I would suppose that the OD backup / restore is only going to work properly for you if your new machine has the same hostname and DNS settings as the old machine. By “work properly” I’m referring to Kerberos and everything associated with it. Kerberos is inherently tied to host/domain names, so effectively changing those names will break it.
In your case, a better strategy might be to name the new Xserve the same as the old one, then when you are ready to take it online, either take the old one offline or rename it. Or, set up the new server with a new name, and import the data by means other than OD Restore.
Supposing you went ahead with OD restore and everything went perfectly, if you use other Mac OS X services, such as mail and web, you would need to copy the data from those services over to the new server. Same goes for home directories.
April 3rd, 2008 at 16:01
A very useful and informative article, thank you! I am about to migrate a PowerMac dual-G5 from 10.4 Server to 10.5 Server. This is a school with 800+ users on the system. Preserving user data is very important. I have do this in place on the same hardware as I do not have a second/backup/replica machine to use.
My configuration is similar to David’s, above. All the user home directories live on a second drive that will not be directly affected by the install of the new OS on the primary drive. Assuming that I properly export/import the account information from WGM, I’m thinking that there is no need to tar the user accounts. The drive and folders will be just as they were under 10.4 and should just work. Yes? No? Comments?
Thanks for the help.
April 3rd, 2008 at 23:58
Hi Tom,
Apple is getting ready to release 10.5.3 soon; you may want to wait until then for your deployment, as it will fix yet another couple of hundred bugs in Leopard.
To answer your question: yes. The home directories should work just fine on the new server, with the user accounts intact, and if they are mounted/shared at the same location(s). There is no need to ‘tar’, but like all good sysadmins, I know that you will do a complete backup of all data before starting. :)
Have a good migration.
April 15th, 2008 at 14:41
Hi Brent,
Great info. I really appreciate the detail and accuracy you have put in your article.
I am migrating to 10.5 this summer and though I would love to archive and restore (same Xserve, IP and hostname) as I’ve done before, there are some issues with our OD being corrupt and after many attempts and discussions with Apple SE’s the solution is to go with a clean install and import users and groups (we’re losing pw’s but necessary to move forward)
Though I am very interested in you password migration steps. Have you encountered any repercussions so far?
Also, I have many servers to upgrade this summer. Would I be fine just doing a clean install on the OD master and upgrading the replicas and afp servers? I’m just not looking forward to all the settings I’ll have to redo if I’m doing a clean install on 20 servers.
thanks again
May 30th, 2008 at 05:16
Like Ringo I used the Archive/Restore method in Server Admin to do a test migration from G5 Tiger 10.4.11 to a an Intel 10.5.3. After the restore I was missing a lot of users. These users fell into to two groups. The first group did not have any sn attribute. The second group had no home directory.
I added sn and home directory entries to those users then Archived/Restored again. Out of 5924 users 2 are missing.
June 27th, 2008 at 14:53
[...] was able to utilize information from NetMojo, specifically this article, and sed to get it done. In the next article I’ll give the specific steps I used to get the [...]
July 3rd, 2008 at 07:32
[...] the last post I mentioned how I was using an article from NetMojo and the stream editor sed to get the users and groups out of the 10.4 Open Directory and into the [...]
July 19th, 2008 at 13:51
At home on my testsetup my 3 test users migrate and all works well, on a client’s setup I get this: ‘ldap_bind: Invalid credentials (49′ after running ‘ldapadd -v -x -D ‘uid=diradmin,cn=users,dc=mydomain,dc=net’ -W -f /tmp/new-users.ldif’. Any idea what this could be? I can’t find any weird mistakes in editing or legacy code from Panther Server…
August 14th, 2008 at 07:30
Brent,
I have a strange problem which I am hoping you can help me with. I just migrated our 10.4.11 server to a new 10.5.4 server. Everything seemed to go fine. I used Apple’s migration instructions and did the Open Directory Archive and restore to bring over users and passwords which worked flawlessly. Obviously the new machine has the same IP address and DNS as the old one. Mail is up and running but I have run into a problem with my managed clients. When I log in from a brand new machine with LDAP setup I can log in as any of my users with no problems. When I try to log in from an existing machine (one that use to log in to my 10.4.11 server) it gets to the point of displaying the users desktop and then it hangs and never displays the dock and desktop icons and menu bar. What is strange is that if I try logging in as UserA from a machine that I know they logged in from to the old server I get in. If I try the same user from a machine they have never used it locks up. This is true for both Leopard and Tiger clients although I have not tried a clean Tiger install.
I am thinking the client machines must be remembering something about the old server that is confusing them when they log into the new server (which they think is the same machine). I am hoping there is something I can reset on the client machines so they can log into the new server as a new machine. Is there a file or directory somewhere I can reset to accomplish this? The existing machines contain all the applications the users use so I don’t want to wipe those machines if I can avoid it.
August 14th, 2008 at 08:35
Hi John,
I don’t quite understand the issue: at first you seemed to say that logins on managed clients from the old server hang, but then you seem to say the opposite, that UserA can login fine from managed clients from the old server, but not with new clients. So is the problem with old client computers, or new client computers? With users, or with client computers?
Try renaming/removing the file:
~/Library/Preferences/edu.mit.Kerberos.KerberosLogin.plist
from an old user’s home directory, and see if that changes the hang-up problem.
Cheers
Brent
August 14th, 2008 at 08:47
Brent,
Sorry, I see now I was unclear. New client computers don’ have a problem no matter who is logging in from that computer. Old client computer hand when it is a user who did not use that computer when logging into the old server. If it is a computer they did use then it seems to log in fine. I am at home now at not at the school where I can check this but I don’t think we were using Kerberos on either the old server or the new one.
August 14th, 2008 at 09:49
OK, so the hanging occurs on old client computers with new users. That is, “old client” meaning client computers that were managed from the 10.4 server, and “new users” meaning users who previously had not logged into the client computer in question.
I’m not sure if client computers can be managed without Kerberos; I thought that was how the client machines authenticate to the server, and vice versa…
Have a look at the /Library/Preferences/edu.mit.Kerberos files on the old client computers, to see if there are references to the old server in there. Try removing/renaming that file, so it gets a new one from the new server, or editing it to reflect the new server.
August 15th, 2008 at 03:10
Brent,
That file was empty on the old client machines. It does not exist on the new Leopard client machine. I tried deleting it but there is no change. I guess I should try enabling Kerberos?
August 16th, 2008 at 21:55
I’m also getting the ldap_bind: Invalid credentials (49) after running ‘ldapadd -v -x -D ‘uid=admin,cn=users,dc=mydomain,dc=com’ -W -f users_modified.ldif
Has anyone else had this issue and found the cause? I have even tried creating another user with administrative rights to ldap with the same result.
August 19th, 2008 at 10:20
Ok, now I feel really dumb for having posted my last comment. Even though in my text above, it was formatted properly, when typing in at the CLI, I was leaving off the cn=users. I guess that’s what I get for not triple checking my command.. I even ran it against another server, but I guess machismo took over when entering the user auth string and I wasn’t entering the cn=users.
April 9th, 2009 at 14:00
Great Information. On the part with the user permissions I found that make a short shell script works well for this. I used this when I moved about 1000 users and the permissions were not correct for any of them.
This is what I did…
Open Terminal as admin…
sudo su
cd /Users
nano changeowner.sh
paste this into the editor…
!/bin/sh
for i in *
do
chown -R $i:staff $i
done
CTRL+X to exit and save
Make the file executable….
chmod 775 changeowner.sh
Execute the file…
./changeowner.sh
May 27th, 2009 at 22:42
Craig,
Your script can actually be accomplished with a one-liner using “find”.
From your user account directory, you can do `find * -maxdepth 0 -exec chown -R {}:staff {} \;`
Brent,
You mention briefly a problem I’m seeing on a system I migrated with the archive/restore option. Several accounts don’t have Kerberos Auth information. Can you suggest a way to actually resolve this, short of deleting and recreating those accounts? How would textmate allow you to do this?
May 28th, 2009 at 10:07
Hi Ryan,
You could use dscl to add the missing information to accounts that require it. For example, if user “foo” has the appropriate Kerberos Auth information, but user “bar” does not, do:
dscl /LDAPv3/127.0.0.1 list /Users
dscl /LDAPv3/127.0.0.1 read /Users/foo dsAttrTypeNative:authAuthority
dscl /LDAPv3/127.0.0.1 read /Users/bar dsAttrTypeNative:authAuthority
I assume that the line with ‘foo’ produced a result, but the one for ‘bar’ did not. Next, we copy & paste the results from ‘foo’ into ‘bar’ (they would normally be the same for all users).
dscl -u diradmin -p /LDAPv3/127.0.0.1 create Users/bar dsAttrTypeNative:authAuthority ';ApplePasswordServer;0x4a1db45d623129c80002222400000006,1024 35 1552336520790876143357923422342342344432068520467333585001342495331358288032423423856319795003339107102915145945351348424622871193864577936392142765821418484201121590222222237589909738845159189198379761266987937615847029786176646000187194939169913424926663686764473845226289233284388945450029977166706293007559029595311 root@myserver.netmojo.ca:10.0.1.240
> ;Kerberosv5;0x4a1db45d623129c80002222400000006;bar@NETMOJO.CA;NETMOJO.CA;1024 35 1552336520790876143357923422342342344432068520467333585001342495331358288032423423856319795003339107102915145945351348424622871193864577936392142765821418484201121590222222237589909738845159189198379761266987937615847029786176646000187194939169913424926663686764473845226289233284388945450029977166706293007559029595311 root@myserver.netmojo.ca:10.0.1.240'
Another thing to check is whether the users in question have a kerberos principle in the kerberos database.
sudo kadmin.local
kadmin.local: listprincs bar*
If not, add one:
kadmin.local: addprinc -randkey bar@NETMOJO.CA
WARNING: no policy specified for bar@NETMOJO.CA; defaulting to no policy
Principal "bar@NETMOJO.CA" created.
Cheers
Brent
May 28th, 2009 at 12:46
Brent,
Makes sense. The users that don’t have Kerberos auth info in OD seem to be those that were migrated from 10.3, then to 10.4, and now 10.5. Everyone else has that info. So maybe I need to script something to go through all the users and create that info… though, I guess since everyone would have the same info, even if they have it, there’s no harm in replacing it, is there?
I also wonder if I can do an archive, open up the sparse image, and edit the dump from the ldap db, then reimport. Supposedly slapconfig -kerberize is supposed to create kerberos info for all the users, but it hangs on the mkpassdb -kerberize part, which runs fine otherwise… so seems kinda broken.
kadmin.local does list a principle for the users in question.
Thanks a bunch of the info. Feel free to email if it would be easier than conversing this way. =)
May 28th, 2009 at 13:07
Yes, you could just delete & create the attribute for all users. Off the top of my head (untested!):
for user in `dscl /LDAPv3/127.0.0.1 list /Users | grep -E "[^root|diradmin]"`;
do
dscl -u diradmin -P s3cr3t /LDAPv3/127.0.0.1 delete Users/$user dsAttrTypeNative:authAuthority
dscl -u diradmin -P s3cr3t /LDAPv3/127.0.0.1 create Users/$user dsAttrTypeNative:authAuthority ';ApplePasswordServer;0x4a1db4...'
done
Only users “root” and “diradmin” are excluded — you may want to expand that list. I noticed that the vpn user doesn’t have the kerberos part of the authAuthority attribute, probably because you don’t want that user to be able to login…
May 28th, 2009 at 16:19
that would work, except it looks like the kerberos auth info has the username in the string, so we’d need to construct that based on the username… but, that’d be easy enough.
I’ll give this a shot on my test OD master and write back…
Any idea what the kerberos auth entry actually gives you? users without that still get tickets…
Also, semi-related… the users that don’t have kerberos entries also can’t seem to have their ical server set. Could this have something to do with it?
And, have you heard anything about the “Allow simultaneous login…” being broken in WGM? even with it unchecked, users can login multiple times, and yes, they are on managed clients, and yes, they’re network home directories. =P
Thanks Brent!
May 28th, 2009 at 16:57
Brent, actually, looking at various users, the entries don’t appear to be the same for every user…
Example:
server:~ admin$ dscl /LDAPv3/127.0.0.1 read /Users/user1 dsAttrTypeNative:authAuthority
dsAttrTypeNative:authAuthority:
;ApplePasswordServer;0x470bb9eb325f31c3000040ee00002257,1024 35 142348687369980182134507175767473848406728018835938950439244504199810591467084867869429532763785664902803450035110236201552277202539905523086333992178101548673534094938083763850217881171960226316582341046758647121979394968026644558722582733133246430363127883800192071325741645982074225105651514207812440564579 root@server.example.com:123.123.123.123
;Kerberosv5;0x470bb9eb325f31c3000040ee00002257;user1@EXAMPLE.COM;EXAMPLE.COM;1024 35 142348687369980182134507175767473848406728018835938950439244504199810591467084867869429532763785664902803450035110236201552277202539905523086333992178101548673534094938083763850217881171960226316582341046758647121979394968026644558722582733133246430363127883800192071325741645982074225105651514207812440564579 root@server.example.com:123.123.123.123
server:~ admin$ dscl /LDAPv3/127.0.0.1 read /Users/user2 dsAttrTypeNative:authAuthority
dsAttrTypeNative:authAuthority:
;ApplePasswordServer;0x48c859af4df339b7000043aa00002a0a,1024 35 142348687369980182134507175767473848406728018835938950439244504199810591467084867869429532763785664902803450035110236201552277202539905523086333992178101548673534094938083763850217881171960226316582341046758647121979394968026644558722582733133246430363127883800192071325741645982074225105651514207812440564579 root@server.example.com:123.123.123.123
;Kerberosv5;0x48c859af4df339b7000043aa00002a0a;user2@EXAMPLE.COM;EXAMPLE.COM;1024 35 142348687369980182134507175767473848406728018835938950439244504199810591467084867869429532763785664902803450035110236201552277202539905523086333992178101548673534094938083763850217881171960226316582341046758647121979394968026644558722582733133246430363127883800192071325741645982074225105651514207812440564579 root@server.example.com:123.123.123.123
So, don’t think that’ll work… can you confirm your’s are the same for any user?
May 29th, 2009 at 13:13
Ryan,
I tested on a larger directory, and got the same results. Some of the users have what appear to be the same keys, but many are different. I would like to know the relationship between these values and the Password Server and Kerberos databases. A specific key probably does not align with a specific password or account in the database, since some users share the same key. I thought that these keys simply matched a particular password server or kerberos server, but obviously servers do not require unique keys. I don’t have time to investigate right now. If you’re going to do this, I’d appreciate it if you let me know what you find.
Thanks!
Brent