Merge Databases, can't dump -mkey_convert principal

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Merge Databases, can't dump -mkey_convert principal

Eric Hattemer
We have a production Kerberos cluster, and a test cluster.  I'd like to
refresh test from production without overwriting those principals that
are specific to test.  We also have something wrong with our production
master database where it will respond to 'kdb5_util dump -verbose'
commands by either hanging or looping.  Generally speaking, everything
works fine, it's just that the database (which is 20 years old) cannot
be dumped.  So eventually I'd like to copy the prod database over to
test and figure out what's wrong with it.

The prod and test databases have different master keys at the moment.  I
thought what I would do is dump all the test-specific principals with
'-mkey_convert' to the prod master password.  But that's currently where
I'm stuck.  If I run:

sudo kdb5_util dump -verbose -mkey_convert -k aes256-cts-hmac-sha1-96

it runs for a few hundred accounts, then stops at one specific principal:

kdb5_util: Decrypt integrity check failed while converting b@REALM to
new master key
kdb5_util: Decrypt integrity check failed performing Kerberos version 5
release 1.11 dump

If I limit the dump to just b@REALM, it fails immediately with the same
error.

That account is involved in some automated testing.  Dumps failed both
before and after the account successfully changed its password and
logged in.  So the principal works, it just can't be dumped with
mkey_convert.  The whole database dumps fine without mkey_convert.  I
had two mkeys loaded in the database.  I tried:

sudo kdb5_util use_mkey 1
sudo kdb5_util update_princ_encryption b@REALM

and it converted just fine.

I'm probably going to create a third environment that doesn't need the
test principals in it.  But I'm just wondering if there's a solution to
the principal that works for the user but can't be dumped with a new key.

--
--
Eric Hattemer
Engineer
Identity and Access Management



________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Merge Databases, can't dump -mkey_convert principal

Greg Hudson
(Sorry for the slow response.)

On 10/01/2018 08:54 PM, Eric Hattemer wrote:
> We have a production Kerberos cluster, and a test cluster.  I'd like to
> refresh test from production without overwriting those principals that
> are specific to test.  We also have something wrong with our production
> master database where it will respond to 'kdb5_util dump -verbose'
> commands by either hanging or looping.

Release 1.15 added (well, re-added) "kdb5_util dump -recurse" which can
help with this situation.  The DB2 format contains iteration pointers as
well as parent-child pointers; if the iteration pointers are corrupt,
lookups work but iteration does not.  Dumping with the -recurse option
forces the use of the parent-child pointers for iteration.

> kdb5_util: Decrypt integrity check failed while converting b@REALM to
> new master key
> kdb5_util: Decrypt integrity check failed performing Kerberos version 5
> release 1.11 dump

> That account is involved in some automated testing.  Dumps failed both
> before and after the account successfully changed its password and
> logged in.  So the principal works, it just can't be dumped with
> mkey_convert.  The whole database dumps fine without mkey_convert.  I
> had two mkeys loaded in the database.  I tried:
>
> sudo kdb5_util use_mkey 1
> sudo kdb5_util update_princ_encryption b@REALM
>
> and it converted just fine.

I don't have any good theories here.  krb5_util dump -mkey_convert and
kdb5_util update_princ_encryption both use similar code paths to decrypt
the existing key entries
(src/kadmin/dbutil/dump.c:master_key_convert()), so it's strange that
one would fail and the other would succeed.  There was a bug related to
the -keepold flag which we fixed in 1.13:

http://krbdev.mit.edu/rt/Ticket/Display.html?id=7995

but I would expect that problem to apply to update_princ_encryption, and
you didn't mention using the -keepold flag.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos