From Newsgroup: comp.protocols.kerberos

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.

If we unset the password policy for an account (modprinc -clearpolicy)
we can change the password, but this isn't ideal.

- We disabled FIPS and RHEL8 new crypto policies which gave no change

- We restored the database again, with no change in behavior.

- We removed policies from all accounts, removed all policies,
recreated all policies, and re-applied all the policies to every
account. No change.

I'm stumped and have been trying different things for about 12 hours - help ? --- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

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

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

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:12rC>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

--- Synchronet 3.21d-Linux NewsLink 1.2