Re: heimdal -> MIT kdc migration

Reply: Rick Macklem : "Re: heimdal -> MIT kdc migration"
In reply to: Rick Macklem : "Re: heimdal -> MIT kdc migration"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Cy Schubert <Cy.Schubert_at_cschubert.com>
Date: Mon, 08 Sep 2025 20:23:53 UTC
In message <CAM5tNy5idSu8oxnpiJDC3Pw0Bij0Whpu6Be2+8=k9RDnPgZcxA@mail.gmail.c
om>
, Rick Macklem writes:
> On Wed, Sep 3, 2025 at 8:28=E2=80=AFAM Rick Macklem <rick.macklem@gmail.com=
> > wrote:
> >
> > On Tue, Sep 2, 2025 at 10:10=E2=80=AFPM Rick Macklem <rick.macklem@gmail.=
> com> wrote:
> > >
> > > On Tue, Sep 2, 2025 at 9:37=E2=80=AFPM Cy Schubert <Cy.Schubert@cschube=
> rt.com> wrote:
> > > >
> > > > In message <CAM5tNy7aNgOyzaKvzRWFGPkpdaHsA_bhjNFjMDQVk0df0dBFjw@mail.=
> gmail.c
> > > > om>
> > > > , Rick Macklem writes:
> > > > > On Sun, Aug 31, 2025 at 5:58=3DE2=3D80=3DAFPM Rick Macklem <rick.ma=
> cklem@gmail.co=3D
> > > > > m> wrote:
> > > > > >
> > > > > > On Sun, Aug 31, 2025 at 5:41=3DE2=3D80=3DAFPM Rick Macklem <rick.=
> macklem@gmail.=3D
> > > > > com> wrote:
> > > > > > >
> > > > > > > On Sat, Aug 30, 2025 at 9:47=3DE2=3D80=3DAFPM Rick Macklem <ric=
> k.macklem@gmai=3D
> > > > > l.com> wrote:
> > > > > > > >
> > > > > > > > On Sat, Aug 30, 2025 at 4:22=3DE2=3D80=3DAFPM Rick Macklem <r=
> ick.macklem@gm=3D
> > > > > ail.com> wrote:
> > > > > > > > >
> > > > > > > > > On Sat, Aug 30, 2025 at 8:56=3DE2=3D80=3DAFAM Rick Macklem =
> <rick.macklem@=3D
> > > > > gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Aug 29, 2025 at 1:05=3DE2=3D80=3DAFPM Rick Mackle=
> m <rick.mackle=3D
> > > > > m@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Aug 29, 2025 at 7:43=3DE2=3D80=3DAFAM Rick Mack=
> lem <rick.mack=3D
> > > > > lem@gmail.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Aug 27, 2025 at 8:39=3DE2=3D80=3DAFPM Rick Ma=
> cklem <rick.ma=3D
> > > > > cklem@gmail.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=3DE2=3D80=3DAFPM Rick =
> Macklem <rick.=3D
> > > > > macklem@gmail.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=3DE2=3D80=3DAFAM Gle=
> b Smirnoff <gl=3D
> > > > > ebius@freebsd.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb =
> Smirnoff=3D
> > > > >  wrote:
> > > > > > > > > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Ri=
> ck Mackl=3D
> > > > > em wrote:
> > > > > > > > > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then =
> "pkg ins=3D
> > > > > tall heimdal", you get a
> > > > > > > > > > > > > > > T> R> working Heimdal-7.8 in ports.
> > > > > > > > > > > > > > > T> R>
> > > > > > > > > > > > > > > T> R> Now, I have another challenge. Fixing the=
>  master =3D
> > > > > passwords.
> > > > > > > > > > > > > > > T> R> I'll work on it later to-day.
> > > > > > > > > > > > > > > T>
> > > > > > > > > > > > > > > T> I have applied two commits from Heimdal from=
>  2012 th=3D
> > > > > at add 'kadmin dump -f MIT'
> > > > > > > > > > > > > > > T> feature to our base heimdal and polished the=
> m to com=3D
> > > > > pile.  So far it doesn't
> > > > > > > > > > > > > > > T> work yet, either create an empty dump or cre=
> ate a co=3D
> > > > > re dump, instead of
> > > > > > > > > > > > > > > T> database dump :) I'll see how difficult it i=
> s going =3D
> > > > > to further resolve that to
> > > > > > > > > > > > > > > T> a working condition. If I succeed, then havi=
> ng 'dump=3D
> > > > >  -f MIT' in base without
> > > > > > > > > > > > > > > T> any ports would be the best solution.  Can a=
> lso be m=3D
> > > > > erged to FreeBSD 14.4.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Good news.  In the above paragraph I was testin=
> g my cha=3D
> > > > > nge incorrectly - threw
> > > > > > > > > > > > > > > the new binary on a system running unpatched li=
> braries.=3D
> > > > >   When run correctly,
> > > > > > > > > > > > > > > it successfully produced something that looks l=
> ike a co=3D
> > > > > rrect dump in MIT format.
> > > > > > > > > > > > > > > I haven't yet tried to load it into MIT kdc yet=
> , though=3D
> > > > > .
> > > > > > > > > Well, would you like the not so bad news or the bad news??;=
> -)
> > > > > > > > > Your patch works, in that it produces a dump that "kdb5_uti=
> l load
> > > > > > > > > -update" can load.
> > > > > > > > > After loading, if the principal only has keys for the newer=
>  encrypt=3D
> > > > > ion types of
> > > > > > > > > aes256-cts-hmac-sha1-96
> > > > > > > > > aes128-cts-hmac-sha1-96
> > > > > > > > > then you can look at the principal via kadmin.local, but th=
> e passwo=3D
> > > > > rd must
> > > > > > > > > be changed before it works.
> > > > > > > > > --> This is the same behaviour as you get if you use Heimda=
> l-7.8 to=3D
> > > > >  do the
> > > > > > > > >       dump conversion.
> > > > > > > > > So far, so good...
> > > > > > > > >
> > > > > > > > > Now, the not so good news. Once you update the Heimdal libr=
> aries
> > > > > > > > > (libhdb.so and libkadm5srv.so) "kadmin -l" is broken on the=
>  system
> > > > > > > > > running the old KDC. "kadmin -l dump" works, but something =
> like:
> > > > > > > > > # kadmin -l
> > > > > > > > > kadmin> get rmacklem
> > > > > > > > > kadmin: get rmacklem: Service key not available
> > > > > > > > > - I have not yet looked in your patched sources to see wher=
> e this
> > > > > > > > >   failure comes from?
> > > > > > > > >
> > > > > > > > > Now, more not so good news...
> > > > > > > > > My patch doesn't help.
> > > > > > > > > It does re-encrypt the key in the master key from the MIT K=
> DC
> > > > > > > > > system, but that doesn't make the password work.
> > > > > > > > > When I compared the dump generated via kadmin with both
> > > > > > > > > your patch and mine, the key for aes256-cts-hmac-sha1-96
> > > > > > > > > is 34bytes long.
> > > > > > > > > After doing the change_password so that it works, a dump
> > > > > > > > > generated by "kdb5_util dump -r13" (the same dump format)
> > > > > > > > > has a key that is 62bytes long.
> > > > > > > > > --> So, there is more to converting the key than just re-ec=
> rypting
> > > > > > > > >       it. (I'll try and find where the MIT code encrypts a =
> key in a=3D
> > > > >  master
> > > > > > > > >       key to see why it ends up at 62bytes and whether that=
>  can be =3D
> > > > > done
> > > > > > > > >       in the old code.)
> > > > > > > > >
> > > > > > > > > So, if we are going to continue with this...
> > > > > > > > > - We need to figure out why your patch breaks "kadmin" for =
> other
> > > > > > > > >   things and fix that.
> > > > > > > > > - I/we need to figure out how to convert the 34byte key to =
> the MIT
> > > > > > > > >   62byte key (and then maybe the password won't need to be =
> changed?=3D
> > > > > ).
> > > > > > > > >
> > > > > > > > > Or do we just say "When you convert the KDC database, all t=
> he passw=3D
> > > > > ords
> > > > > > > > > must be changed to get them to work?".
> > > > > > > > All I've got sofar is this patch...
> > > > > > > > https://people.freebsd.org/~rmacklem/print.patch
> > > > > > > >
> > > > > > > > It tweaks entry2mit_string_int() so that it skips over the ke=
> ys for
> > > > > > > > old encryption types and fills in a fake "modified by" entry =
> if none
> > > > > > > > exists.
> > > > > > > >
> > > > > > > > These changes at least make the MIT dump such that the record=
> s
> > > > > > > > don't end up "incomplete or corrupted" when you try to do som=
> ething
> > > > > > > > like "get_principal <principal>" in kadmin.local.
> > > > > > > >
> > > > > > > > As noted, your patch makes "kadmin -l" break for most things,
> > > > > > > > reporting "Service key not available". The failures go away i=
> f
> > > > > > > > you revert back to the non-patched libraries.
> > > > > > > > I have not located the problem yet.
> > > > > > > >
> > > > > > > > As for the passwords...no luck yet, rick
> > > > > > > Finally..it works. (First off, apologies for all the posts, jus=
> t ignore
> > > > > > > them.;-)
> > > > > > >
> > > > > > > The patch is at:
> > > > > > > https://people.freebsd.org/~rmacklem/kadmin.patch
> > > > > I just updated the patch with a fix for the case where the
> > > > > Heimdal principal does not have any keys for string encryption.
> > > > > (That is fixed now and I haven't found any other bugs, so I
> > > > > think I am done playing with it. Yippee!!)
> > > > >
> > > > > Please test when you can find the time, rick
> > Outstanding issue/question w.r.t. converting the KDC database
> > from Heimdal 1.5.2->MIT.
> >
> > Right now, the patch I have drops the weak encryption type keys
> > (des3.. and arcfour..).
> > If the principal in the Heimdal KDC does not have keys for either
> > of:
> > aes256-cts-hmac-sha1-96
> > aes128-cts-hmac-sha1-96
> > the patch generates a "fake" one. As a result, a change_password
> > for the principal is needed for this case.
> >
> > The alternative to doing this would be an option that converts
> > the weak keys, but...
> > - The MIT KDC will find the principal "incomplete or corrupted"
> >   for at least the "out-of-the-box" configuration.
> >   - It might accept them if "accept_weak_ecntypes" is set in
> >     the kdc.conf.
> >     This leads to a couple of questions:
> >     - Does anyone know if MIT 1.22 still allows
> >       "accept_weak_enctypes?
> >     If it does not allow them, I don't think there is much use
> >     for this option?
> >
> > Given the release schedule, it would be nice to get this
> > resolved soon.
> Since no one reported whether or not they saw the
> "Service key not available" errors from the patched kadmin
> for commands like "get", I poked at it and found it was caused
> by some code the cherry-pick from the newer Heimdal added,
> related to historical keys (which are not supported by Heimdal 1.5.2.)
>
> Commenting out one new function the cherry-pick added along
> with the two calls to it seems to have fixed the problem.
>
> I've updated my patch at:
> https://people.freebsd.org/~rmacklem/kadmin.patch
> to include these changes.
>
> So, can you guys test this and get it into main?
> (You are welcome to include my patch in the commit,
> That is probably faster than doing it as a separate one.)
> At this point, it works for everything I have tested and, yes,
> the passwords do work after the dump is loaded into the
> MIT KDC!
>
> rick
> ps: I cannot test it more than I have already done until it
>       is in a snapshot that I can install for further testing.

The patch doesn't apply here. Do I need to apply a prerequisite patch?

slippy$ git apply /tmp/kadmin.patch
error: patch failed: crypto/heimdal/kadmin/dump.c:72
error: crypto/heimdal/kadmin/dump.c: patch does not apply
error: patch failed: crypto/heimdal/lib/hdb/common.c:156
error: crypto/heimdal/lib/hdb/common.c: patch does not apply
error: patch failed: crypto/heimdal/lib/hdb/mkey.c:458
error: crypto/heimdal/lib/hdb/mkey.c: patch does not apply
error: patch failed: crypto/heimdal/lib/hdb/print.c:378
error: crypto/heimdal/lib/hdb/print.c: patch does not apply
slippy$ 
slippy$ 
slippy$ patch -C -p1 < /tmp/kadmin.patch 
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|commit 66bbcc907b21adea8af90ac080faed14dd4be439
|Author: Rick Macklem <rmacklem@uoguelph.ca>
|Date:   Fri Aug 29 07:05:00 2025 -0700
|
|    kadmin: Add support for conversion to MIT's master key
|    
|    When "-f MIT" is used for "kadmin -l dump" it writes
|    the dump out in MIT format.  This dump format is understood
|    by the MIT kdb5_util command.
|    
|    However, there are a couple of issues:
|    - If there are weak encryption keys in a principal's entry,
|      MIT's kadmin.local will report that the principcal's entry
|      is incomplete or corrupted.
|      This is also true if there is no modified_by component
|      in the dump line for a principal.
|    - The keys are encrypted in Heimdal's master key.  The
|      "-d" option can be used on the "kadmin -l dump" to
|      de-encrypt them, but the passwords will not work on the
|      current MIT KDC.
|    
|    To try and deal with the above issues, this patch:
|    - Does not dump the weak keys.
|      If a principal does not have a key for any strong
|      key encryption type, a strong key is generated for it,
|      but is not encrypted in the MIT master key.
|      As such, this principal will need a change_password
|      after being loaded into the MIT KDC.
|    - If there is no modified_by field in the principal's
|      database entry, a fake one is generated.
|    - Re-encrypts the keys in MIT's master key if the argument
|      to "-f" is actually the MIT KDC's master key keytab file
|      and not "MIT" or "Heimdal".
|    To make this work, the command
|    "kadmin -l dump -f .k5.YOUR.REALM mit.dump"
|    must be done on the Heimdal KDC, where .k5.YOUR.REALM
|    is the master key keytab file for the MIT KDC.
|    Then "mit.dump" must be copied to the MIT KDC and
|    loaded into the MIT KDC's database via the command
|    "kdb5_util load -update mit.dump".
|    
|    This patch is currently only tested for the simple
|    setup I am running.
|
|diff --git a/crypto/heimdal/kadmin/dump.c b/crypto/heimdal/kadmin/dump.c
|index 0f2ed7445126..2c302eced210 100644
|--- a/crypto/heimdal/kadmin/dump.c
|+++ b/crypto/heimdal/kadmin/dump.c
--------------------------
Patching file crypto/heimdal/kadmin/dump.c using Plan A...
Hunk #1 failed at 72.
1 out of 1 hunks failed while patching crypto/heimdal/kadmin/dump.c
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/crypto/heimdal/lib/hdb/common.c b/crypto/heimdal/lib/hdb/commo
n.c
|index 90e600521e34..80482e7a4c1c 100644
|--- a/crypto/heimdal/lib/hdb/common.c
|+++ b/crypto/heimdal/lib/hdb/common.c
--------------------------
Patching file crypto/heimdal/lib/hdb/common.c using Plan A...
Hunk #1 failed at 156.
Hunk #2 failed at 181.
2 out of 2 hunks failed while patching crypto/heimdal/lib/hdb/common.c
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/crypto/heimdal/lib/hdb/hdb.h b/crypto/heimdal/lib/hdb/hdb.h
|index 562cceead8ec..4c4c2c2b1a5c 100644
|--- a/crypto/heimdal/lib/hdb/hdb.h
|+++ b/crypto/heimdal/lib/hdb/hdb.h
--------------------------
Patching file crypto/heimdal/lib/hdb/hdb.h using Plan A...
Hunk #1 succeeded at 256.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/crypto/heimdal/lib/hdb/hdb_locl.h b/crypto/heimdal/lib/hdb/hdb
_locl.h
|index cb5040080e4e..5aad504589df 100644
|--- a/crypto/heimdal/lib/hdb/hdb_locl.h
|+++ b/crypto/heimdal/lib/hdb/hdb_locl.h
--------------------------
Patching file crypto/heimdal/lib/hdb/hdb_locl.h using Plan A...
Hunk #1 succeeded at 67 (offset -2 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/crypto/heimdal/lib/hdb/mkey.c b/crypto/heimdal/lib/hdb/mkey.c
|index ff68aa1bb23d..78a9e51a132c 100644
|--- a/crypto/heimdal/lib/hdb/mkey.c
|+++ b/crypto/heimdal/lib/hdb/mkey.c
--------------------------
Patching file crypto/heimdal/lib/hdb/mkey.c using Plan A...
Hunk #1 succeeded at 403 (offset -12 lines).
Hunk #2 succeeded at 433 (offset -12 lines).
Hunk #3 succeeded at 451 with fuzz 2 (offset -12 lines).
Hunk #4 failed at 584.
Hunk #5 failed at 633.
2 out of 5 hunks failed while patching crypto/heimdal/lib/hdb/mkey.c
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/crypto/heimdal/lib/hdb/print.c b/crypto/heimdal/lib/hdb/print.
c
|index 444db39493fc..d5359f538056 100644
|--- a/crypto/heimdal/lib/hdb/print.c
|+++ b/crypto/heimdal/lib/hdb/print.c
--------------------------
Patching file crypto/heimdal/lib/hdb/print.c using Plan A...
No such line 377 in input file, ignoring
Hunk #1 failed at 378.
Hunk #2 failed at 391.
Hunk #3 failed at 418.
Hunk #4 failed at 434.
Hunk #5 failed at 453.
Hunk #6 failed at 470.
Hunk #7 failed at 481.
Hunk #8 failed at 495.
Hunk #9 failed at 531.
9 out of 9 hunks failed while patching crypto/heimdal/lib/hdb/print.c
done
slippy$ 


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e**(i*pi)+1=0