[37861] in Kerberos

home help back first fref pref prev next nref lref last post

Problem with db master password migrating kerberos server to new

daemon@ATHENA.MIT.EDU (Eichhorn, Thomas)
Wed Feb 8 07:55:16 2017

From: "Eichhorn, Thomas" <Thomas.Eichhorn@klinikum-nuernberg.de>
To: "'Rainer Krienke'" <krienke@uni-koblenz.de>,
        "kerberos@mit.edu"
	<kerberos@mit.edu>
Date: Wed, 8 Feb 2017 12:54:52 +0000
Message-ID: <CB77FE5A1D7BA34FBC22A5829EB549113B4DFC0B@KNEXCH3.klinikum-nuernberg.de>
In-Reply-To: <2cda36cc-ae39-8a9d-bcf7-b08051b4e572@uni-koblenz.de>
Content-Language: de-DE
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit

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@mit.edu [mailto:kerberos-bounces@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


home help back first fref pref prev next nref lref last post