[39367] in Kerberos
Re: Applying policy results in Bad encryption type
daemon@ATHENA.MIT.EDU (BuzzSaw Code)
Tue Mar 12 16:23:23 2024
MIME-Version: 1.0
In-Reply-To: <202403122012.42CKCRvn005732@hedwig.cmf.nrl.navy.mil>
From: BuzzSaw Code <buzzsaw.code@gmail.com>
Date: Tue, 12 Mar 2024 16:22:07 -0400
Message-ID: <CAJhaRZKW0shdvBDfUi1u=OdMk8TZDyF76F6Dk5bdoSKBNxgSfQ@mail.gmail.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
You nailed it - we dropped DES and switched to AES keys everywhere
else a long time ago but somehow missed that.
Thank you!
On Tue, Mar 12, 2024 at 4:12 PM Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:
>
> >We did a server replacement of our master KDC that had been on RHEL7
> >for years to finally upgrade to RHEL8. We did a dump of the database
> >prior to the swap, we still have the old server sitting around as
> >well. Principal database is on disk in old db2 style. Kerberos
> >version is 1.18 for RHEL8, RHEL7 version is 1.15.
> >
> >Everything went smooth, except any attempt to change a password results in:
> >
> >"change_password: Bad encryption type while changing password for < principal >"
> >
> >Doesn't matter if it is done over the network or with kadmin.local.
>
> What is the key type of the password history principal? That is in your
> database as kadmin/history@REALM.
>
> If it's something like single-DES, then that's your problem because
> the old keys are encrypted in the database with the history key and
> "Bad encryption key" is coming from the attempt to check the password
> history. If that's the case then you can change the history key to a
> modern algorithm using the command detailed here:
>
> https://web.mit.edu/kerberos/krb5-latest/doc/admin/database.html#updating-the-history-key
>
> But as detailed there that will invalidate your password history (much
> like modprinc -clearpolicy).
>
> In THEORY you could do some mangling on the database dump and try to
> re-encrypt the old keys with a new key; when I ran into this situation I
> decided that I didn't care THAT much about the old password history and
> I didn't bother doing that.
>
> --Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
