Re: heimdal -> MIT kdc migration
- In reply to: Cy Schubert : "Re: heimdal -> MIT kdc migration"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 08 Sep 2025 22:31:38 UTC
On Mon, Sep 8, 2025 at 1:23 PM Cy Schubert <Cy.Schubert@cschubert.com> wrote: > > 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? It applies on top of glebius@'s branch. I think you can get it by.. git clone https://github.com/glebius/FreeBSD - and then git checkout kadmin-dump-MIT and then the patch should apply on top of that. I built it via "make buildworld" with WITHOUT_MITKRB5="yes" in my /etc/src.conf. (It took days because I couldn't figure out how to get a universe machine to build it?) rick > > 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 > >