Recover Master Password in MIT Kerberos

So I am in the process of updating the KDC at my job ( Open Systems @ University of Florida ) and we ran into a few issues:

1. RHEL does not have a new enough version of MIT Kerberos
2. No one can remember the "Master Password" for the KDC
3. The KDC is running on older Power hardware under AIX

It took a while but it looks like we finally figured out how to get from the old AIX/Power box to RHEL/x86_64.

The following is how we solved each one of the problems from above.

RHEL has an older version of MIT Kerberos

As was mentioned in my previous posts: I hate you RHEL and Kerberos 1.8 on RHEL. I was able to get MIT Kerberos 1.8 compiled, packaged, and install on RHEL5.5. See those posts for my work arounds.

Anyone remember the KDC Master Password?

The KDC was installed back in 1996. At the time, the password was known. The stash file was also created so that the KDC could start automatically. There were about 4 people that knew the Master Password either because they entered it in or they had access to the piece of paper that had the password. The person that created the Master Password no longer worked at UF, so when I needed to know what the Master Password was I had to find someone that had access to the piece of paper. After some searching, It was determined that the piece of paper was long lost and assumed destroyed. So no one knew the Master Password. All we had was the stash file.

We thought, well that sucks but at least we have the stash file so we can move forward. WRONG! Turns out the stash file is not endian safe. The file itself is written in the native endianess of the machine. Since we are going from a Power to and x86_64 machine, taking a KDC dump and taking the stash file will not work.

After much research by one of my co-workers we found an option to kdb5_util dump command that allows you to re-key the principals based on a new Master Password. That option is -mkey_convert.

There is one more wrinkle to this story. The new version of MIT Kerberos allows you to have multiple encyption types on your K/M principal. The default encryption type has also changed. So you will not just need to dump with a new Master Password but you will also need to know the encryption type of your K/M principal. This can be achieved by executing a getprinc on K/M and noting the encryption type.

So now that we had all the tools in place here is the procedure:

1. Dump the KDC database on your primary kdc with the following: kdb5_util dump -mkey_convert kdc.dump. This will ask you for a new Master Password. Set it to the actual Master Password that you want in your new KDC
2. Copy the contents over to the new KDC.
3. Figure out what the encryption type of the K/M principal is: kadmin.local -q "getprinc K/M" and not the encryption type. You will need it later.
4. Create a new KDC: kdb5_util -r create. The password is not important.
5. Add a new Master Key encryption type by doing the following: kdb5_util add_mkey -e where encryption type is set to the encryption type used where you took the KDC dump.
6. Get a list of the Master Keys: kdb5_util list_mkeys. Note the kvno of the newly created key.
7. Switch to using the newly created key: kdb5_util use_mkey where kvno is the kvno of the key with the correct encryption type.
8. Create a stash file: kdb5_util stash
9. Load your dump: kdb5_util -r load kdc.dump

At this point, you have a KDC with a password that you should know that you set in step 1 above. You also have a stash file with two entries.

• The Master Password that you entered in step 4
• The Master Password that you set in step 1

The second is more important. If you wanted to, you could create a new stash file which will remove the first entry.

There you have it. If you follow these directions you should be able to:

• Set a new Master Password on your KDC
• Change your KDC CPU architecture from one to another

You just need to have the following things:

• Have a working stash file for your current KDC
• Know the encryption type of your K/M key

Kerberos 1.8 on RHEL

Turned out the dependency hell was easier to get out of this time. I needed to remove both pam_krb5 and krb5-libs.i386. Weird thing is you can leave the krb5-libs.x86_64 installed and the update will work just fine. Probably has to do with the fact that I did not build i386 versions of krb5-libs-1.8 but only x86_64 version.

Again, Thanks RHEL. That sucked but at least I can move on to the next step.