M igrating LDAP users & passwords to 10.4

[gw1500se]

I am trying to perform the migration process described in “andrina’s” article (https://www.afp548.com/article.php?story=20050615173039158) but have hit a brick wall. Each step seemed to complete normally with the exception of the “sudo mkpassdb -mergeparent backup_authserver_folder backup_from_new_server” which pumped out a number of duplicate entry warnings. However, it seems like they would be expected since they are for common principals (e.g. pop service, etc.). Assuming they are normal the “mkpass -kerberize” step returned with no errors, just a new prompt.

Here’s the problem. All seemed OK (the users were listed in Workgroup Manager and I could ‘su’ to users. I then tried to login as a user and could not mount the home directory. While investigating this I found that users could not create kerberos tickets (bad password). Using ‘kadmin.local’ and ‘listprincs’ I found that none of the users were in the kerberos database. Plus the last several principals listed appeared to be garbage. Has anyone run iinto this and/or can anyone suggest what I did wrong? Were the duplicate warnings a symptom or cause?

One other question that might be more important. The instructions said to change the RSA keys in the ldif file. It talked about changing all RSA keys but mentioned only the keys in the “;ApplePasswordServer;” line. I also have the same RSA key on an additional line “;KerberosV5;” so I changed that as well. Should the instructions have said to change ONLY the “;ApplePasswordServer;” lines? Do I need to re-migrate leaving those lines with the original key? Are the line endings critical? I had the :rootIP Address> on my lines. The article implied the entire thing was to be replaced but the key from the “mkpassdb -dump” did not have the appended. Was I supposed to have added that? Also the Kerberos line had a slightly different ending then the “-dump” key?

My hope that is one of these omissions is the culprit and someone can advise. TIA.

[gw1500se]

I got it figured out. The answer is yes the Kerberosv5 keys need to be changed as well. Also omitted from the article is that the kerberos realm needed to be edited. The trick is that the ldif format is such that the keys are seperated by new line characters into fixed 78 character lines. Unfortunately, there is no easy way to find/replace them because the breaks depend on the length of the user’s name. I had to brute force edit each user’s entry to get the new keys in it. Once that was done the imported files and kerberizing worked fine.

[Author]

Posts