Problem with db master password migrating kerberos server to new machine

[Eichhorn, Thomas]

Hello Rainer,

>>
>> http://web.mit.edu/kerberos/krb5-latest/doc/admin/database.html?highlight=master#updating-the-master-key
>
>This solution looks promising. I simply created a new kerberos db, exported the old one and imported everything on the new server. Using the old stash file I am able to work with the new database. Carrying out the described commands in >order to add a new master key worked fine.
>
>The only thing I ask myself is, if the new encryption typed available in this new kerberos version (aes256-cts-hmac-sha1-96) could bite an older client that does not know anything about this enctype but wants to get a ticket from the server for a principal that has been encrypted with this new encryption-algorithm during the kdb5_util update_princ_encryption run, or if a new principal is created?
>
>Is this danger real?

This is the encryption type for the master key.
You should still be able to allow weak crypto for older clients if you have to: http://web.mit.edu/Kerberos/krb5-devel/doc/admin/enctypes.html

Best regards
Thomas

-----Ursprüngliche Nachricht-----
Von: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] Im Auftrag von Rainer Krienke
Gesendet: Mittwoch, 8. Februar 2017 13:34
An: kerberos at mit.edu
Betreff: Re: Problem with db master password migrating kerberos server to new machine

Hello  Greg,

thank you very much for your answer.

> If you configure "master_key_enctype = des3-cbc-sha1" in the [realms]
> subsection for your realm in kdc.conf (or krb5.conf), I believe it
> should work again (in both versions).  Alternatively, you could rotate
> the master key by following this procedure:

This solution did not work for me. I put the master_key_enctype as described into the krb5.conf and kdc.conf files but a kdb5_util create -r xyz -s still created a aes256-cts-hmac-sha1-96 master key. Next I tried kdb5_util -k des3-cbc-sha1 create -r xyz -s. This worked in the sense that the master key was actually a des key, but access via kadmn.local -m <password> does then not work. Using the new stash file it works. Perhaps a fixed encryption type  compiled into the binaries?

>
> http://web.mit.edu/kerberos/krb5-latest/doc/admin/database.html?highli
> ght=master#updating-the-master-key

This solution looks promising. I simply created a new kerberos db, exported the old one and imported everything on the new server. Using the old stash file I am able to work with the new database. Carrying out the described commands in order to add a new master key worked fine.

The only thing I ask myself is, if the new encryption typed available in this new kerberos version (aes256-cts-hmac-sha1-96) could bite an older client that does not know anything about this enctype but wants to get a ticket from the server for a principal that has been encrypted with this new encryption-algorithm during the kdb5_util update_princ_encryption run, or if a new principal is created?

Is this danger real?

>
> I am curious why you sometimes use the typed-in master key password
> when you have a stash file.
>
Well I justed wanted to ensure in the first place that everything that workes with the old server also does work with the new one. I used kadmin.local -m just for testing if the master key ist still valid and working. In general of course I make use of the stash file, but it could get corrupted or accidentally deleted which might lock me out of the database.

Thanks you very much
Rainer
--
Rainer Krienke, Uni Koblenz, Rechenzentrum, A22, Universitaetsstrasse 1 56070 Koblenz, Tel: +49261287 1312 Fax +49261287 100 1312
Web: http://userpages.uni-koblenz.de/~krienke
PGP: http://userpages.uni-koblenz.de/~krienke/mypgp.html

________________________________


Klinikum Nürnberg, Sitz: Nürnberg, Amtsgericht Nürnberg -Registergericht- HRA 14190, Vorstand: Dr. Alfred Estelmann