From nobody Mon Sep 08 20:23:53 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cLJM13Dx1z674Nc for ; Mon, 08 Sep 2025 20:23:57 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cLJM05Mczz41cm; Mon, 08 Sep 2025 20:23:56 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=permerror reason="p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com" header.from=cschubert.com (policy=permerror); spf=pass (mx1.freebsd.org: domain of cy.schubert@cschubert.com designates 3.97.99.33 as permitted sender) smtp.mailfrom=cy.schubert@cschubert.com Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTPS id vaosucQCl5MqyviP6u3iek; Mon, 08 Sep 2025 20:23:56 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id viP4uBD6dl5eGviP5uvjUI; Mon, 08 Sep 2025 20:23:55 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=EO6l0EZC c=1 sm=1 tr=0 ts=68bf3b5b a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=yJojWOMRYYMA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=pGLkceISAAAA:8 a=i1fwTJ2rAAAA:8 a=zdPUvaFGAAAA:8 a=04oDvr9pAAAA:8 a=hF2rLc1pAAAA:8 a=YxBL1-UpAAAA:8 a=n6Wa5QzOHJnW4xFBhNcA:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=fvD0gfNcX4AKPV7IvcuC:22 a=sT4bYkpex2i6d5iwGOJT:22 a=O9OM7dhJW_8Hj9EqqvKN:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy.cwsent.com [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 900C8160; Mon, 08 Sep 2025 13:23:53 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 854F9286; Mon, 08 Sep 2025 13:23:53 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Rick Macklem cc: Cy Schubert , Gleb Smirnoff , freebsd-current@freebsd.org Subject: Re: heimdal -> MIT kdc migration In-reply-to: References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> <20250903043714.370F5311@slippy.cwsent.com> Comments: In-reply-to Rick Macklem message dated "Mon, 08 Sep 2025 13:08:16 -0700." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Sep 2025 13:23:53 -0700 Message-Id: <20250908202353.854F9286@slippy.cwsent.com> X-CMAE-Envelope: MS4xfBlNogMJGZFRbM30CWEcj+w+GexMqNPWIfG2GHbZ+E/4QXGZFGeVJWBunjr2A3+72/MYPi1HAk8MQHi/o8xnbApYkkC+OJGmjZ0iIsZ0waYfDM7wINPX e5a78F+TNJVFay/y4ZyMIeSkYY8fefvh1wZkDFA7F5egniFvtkmYBrBUKHnvIUlfgh3Ws2RyFzIaMgtgJOh8heUSDUf4VyEL1hHhVamvc3pR1oep76Fy0DwM eP1/UNhBaOWfsEUwR2Bhhh3qNIb+37WNlK5O30rCUHo= X-Spamd-Bar: - X-Spamd-Result: default: False [-1.76 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; MV_CASE(0.50)[]; RWL_MAILSPIKE_EXCELLENT(-0.40)[3.97.99.33:from]; R_SPF_ALLOW(-0.20)[+ip4:3.97.99.32/31]; RCVD_IN_DNSWL_LOW(-0.10)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; DMARC_BAD_POLICY(0.00)[cschubert.com : p tag has invalid value: quarantine rua=mailto:p[ostmaster@cschubert.com]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4cLJM05Mczz41cm In message , Rick Macklem writes: > On Wed, Sep 3, 2025 at 8:28=E2=80=AFAM Rick Macklem > wrote: > > > > On Tue, Sep 2, 2025 at 10:10=E2=80=AFPM Rick Macklem com> wrote: > > > > > > On Tue, Sep 2, 2025 at 9:37=E2=80=AFPM Cy Schubert rt.com> wrote: > > > > > > > > In message gmail.c > > > > om> > > > > , Rick Macklem writes: > > > > > On Sun, Aug 31, 2025 at 5:58=3DE2=3D80=3DAFPM Rick Macklem cklem@gmail.co=3D > > > > > m> wrote: > > > > > > > > > > > > On Sun, Aug 31, 2025 at 5:41=3DE2=3D80=3DAFPM Rick Macklem macklem@gmail.=3D > > > > > com> wrote: > > > > > > > > > > > > > > On Sat, Aug 30, 2025 at 9:47=3DE2=3D80=3DAFPM Rick Macklem k.macklem@gmai=3D > > > > > l.com> wrote: > > > > > > > > > > > > > > > > On Sat, Aug 30, 2025 at 4:22=3DE2=3D80=3DAFPM Rick Macklem ick.macklem@gm=3D > > > > > ail.com> wrote: > > > > > > > > > > > > > > > > > > On Sat, Aug 30, 2025 at 8:56=3DE2=3D80=3DAFAM Rick Macklem = > > > > > gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > On Fri, Aug 29, 2025 at 1:05=3DE2=3D80=3DAFPM Rick Mackle= > m > > > > m@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > On Fri, Aug 29, 2025 at 7:43=3DE2=3D80=3DAFAM Rick Mack= > lem > > > > lem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 8:39=3DE2=3D80=3DAFPM Rick Ma= > cklem > > > > cklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=3DE2=3D80=3DAFPM Rick = > Macklem > > > > macklem@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=3DE2=3D80=3DAFAM Gle= > b Smirnoff > > > > 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 " 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 |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 FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0