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-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] Im Auftrag von Rainer Krienke Gesendet: Mittwoch, 8. Februar 2017 13:34 An: kerberos@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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
