From nobody Mon Sep 01 00:58:40 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 4cFVr40tmbz65T5W for ; Mon, 01 Sep 2025 00:59:00 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cFVr334j9z4PcT; Mon, 01 Sep 2025 00:58:59 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="C4GB/C4K"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-6188b5ad4f0so4967663a12.0; Sun, 31 Aug 2025 17:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756688333; x=1757293133; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RsDA0Gd/BPYH72IV0x+kMgqdbZSmyJPPBHdeYpaJExQ=; b=C4GB/C4K+zWfILUU9w7KmeZuRITtIGWEDM9Zixji0mTkt+aFNWqOfbAM5T00S+7Uag A3AcdqxxDOo+V1zSIfLYTX6/plOFOSSUpiytTME4+nXY0bEzWH4QcyyJ+Uh7oLV+rkWM 3KCIGOD6wliG1xo22RH/TDfZ6UAC8vF6rnOhYjcyiVwboRrfBBiDRiT7sTxews3ml5SU IbU7TUmrRm2mlMyUNI0JvISkUSlZgpPGMnNouw1X4P3P2Fbijluv3SUYYXgq2AGmDy+P GEFBdnlVfwehllP8H7MeXfBFJtp0zDjq8OcbsDD2P46idBjOU/IQ+rMew0G3qv9G2G/k sxkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756688333; x=1757293133; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RsDA0Gd/BPYH72IV0x+kMgqdbZSmyJPPBHdeYpaJExQ=; b=R/YbGlQ6xCNDfhR+zaM98fTN9PYRpWiapzAntlGfpw37YwywwxrXcIulqgGMqpyHE1 Njg9T26nC/ApFE10hwzTvnjy4eCB6kJm7LJHnK4m8xxbl/dumcK6trtszI8lQT//4rVX p/FmE7RsPH+WZAQPBH5omehyzMJtKaaZ9xYNhNHLT+7LDZvnaIPconhiiF3/7GthLKLl AOjUfL01p4K7/XejyEERBSCS/v0+mKCwfouyzr0WAToRfWYzk0uLDRGH5zyFZso2qwDR Aa3HG/EQmP0EGsuapxvwfXWS4/SKBaINBhtRMyiJQRL/Ikh8n+TNXLLbRTEFf5xImspQ J+/A== X-Forwarded-Encrypted: i=1; AJvYcCXGM8VUcBfaq/dvs2wxy9dbQYe0wCrVBAlMmdEGje6Vm1vfKo4M+O/oPMny2zPL9O1kyBoGrFMYQgymeC+0EkY=@freebsd.org X-Gm-Message-State: AOJu0Yybx0BYGDzDMM4tnX92jkUDSj8P7j1GD18GkFVaJ+k8hbS0huw1 6OJK6Hxb+mECKMiIcJd/2dhIv/b0RueXGQp11buVbKeASUvf3FmnFSvAj6xMq14dUsNJ3g+BlXm 8fo6qFkkYT8KF2Q7Txg91qJGCjSX0g9MZ X-Gm-Gg: ASbGncsO/2XT9UbsVkUNjdlF+rwdoXIbEoDnevsJaekCKEOoCEj9bkb9Uq1dGeJcRjX JPMFtzF5DU3NDuIxCts7MQf3dqI1H06y0C/waQcT0xWTY6t9N/Pa5Z5DpUMGVVrLtGWMunEt20/ tWNczFvHxMIOV19SBToucWVlq7yW1+YdtndjgT/zhuhGWsg/tQBylnOtTjikrgIQeT0sUdNzoLx 4dkfhAaihK80UOO2qf8IVaOklssftIMOsoqzTl47HLdBMDT8w== X-Google-Smtp-Source: AGHT+IHjvqG9piytpNS1Y/uKgmUzBH3DvtAoyqxs5RVQ+R/dpKZJBb5enG67v0rpcjcS39k2Aahi3vfE4QbPlKY77mI= X-Received: by 2002:a05:6402:5252:b0:61d:12df:75c7 with SMTP id 4fb4d7f45d1cf-61d26ec99d9mr5659429a12.35.1756688332497; Sun, 31 Aug 2025 17:58:52 -0700 (PDT) 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 References: <56dd78c6-a53a-4c4c-989a-335cc5fed405@FreeBSD.org> <1578a4eac5402d0496d8989e5258bc78@Leidinger.net> In-Reply-To: From: Rick Macklem Date: Sun, 31 Aug 2025 17:58:40 -0700 X-Gm-Features: Ac12FXwf7ywG04qM3PavrWluHLw7W7qivrrf-exg79Px8ZKgdGG3ObGaO79Ttn4 Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cFVr334j9z4PcT On Sun, Aug 31, 2025 at 5:41=E2=80=AFPM Rick Macklem wrote: > > On Sat, Aug 30, 2025 at 9:47=E2=80=AFPM Rick Macklem wrote: > > > > On Sat, Aug 30, 2025 at 4:22=E2=80=AFPM Rick Macklem wrote: > > > > > > On Sat, Aug 30, 2025 at 8:56=E2=80=AFAM Rick Macklem wrote: > > > > > > > > On Fri, Aug 29, 2025 at 1:05=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > On Fri, Aug 29, 2025 at 7:43=E2=80=AFAM Rick Macklem wrote: > > > > > > > > > > > > On Wed, Aug 27, 2025 at 8:39=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > > > > > On Wed, Aug 27, 2025 at 7:43=E2=80=AFPM Rick Macklem wrote: > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 9:35=E2=80=AFAM Gleb Smirnoff wrote: > > > > > > > > > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff w= rote: > > > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem= wrote: > > > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg insta= ll heimdal", you get a > > > > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > > > > T> R> > > > > > > > > > T> R> Now, I have another challenge. Fixing the master pa= sswords. > > > > > > > > > T> R> I'll work on it later to-day. > > > > > > > > > T> > > > > > > > > > T> I have applied two commits from Heimdal from 2012 that= add 'kadmin dump -f MIT' > > > > > > > > > T> feature to our base heimdal and polished them to compi= le. So far it doesn't > > > > > > > > > T> work yet, either create an empty dump or create a core= dump, instead of > > > > > > > > > T> database dump :) I'll see how difficult it is going to= further resolve that to > > > > > > > > > T> a working condition. If I succeed, then having 'dump -= f MIT' in base without > > > > > > > > > T> any ports would be the best solution. Can also be mer= ged to FreeBSD 14.4. > > > > > > > > > > > > > > > > > > Good news. In the above paragraph I was testing my chang= e incorrectly - threw > > > > > > > > > the new binary on a system running unpatched libraries. = When run correctly, > > > > > > > > > it successfully produced something that looks like a corr= ect dump in MIT format. > > > > > > > > > I haven't yet tried to load it into MIT kdc yet, though. > > > Well, would you like the not so bad news or the bad news??;-) > > > Your patch works, in that it produces a dump that "kdb5_util load > > > -update" can load. > > > After loading, if the principal only has keys for the newer encryptio= n types of > > > aes256-cts-hmac-sha1-96 > > > aes128-cts-hmac-sha1-96 > > > then you can look at the principal via kadmin.local, but the password= must > > > be changed before it works. > > > --> This is the same behaviour as you get if you use Heimdal-7.8 to d= o the > > > dump conversion. > > > So far, so good... > > > > > > Now, the not so good news. Once you update the Heimdal libraries > > > (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 where 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 KDC > > > 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-ecrypting > > > it. (I'll try and find where the MIT code encrypts a key in a m= aster > > > key to see why it ends up at 62bytes and whether that can be do= ne > > > 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?). > > > > > > Or do we just say "When you convert the KDC database, all the passwor= ds > > > 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 keys 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 records > > don't end up "incomplete or corrupted" when you try to do something > > 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 if > > 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, just ignore > them.;-) > > The patch is at: > https://people.freebsd.org/~rmacklem/kadmin.patch > > It goes on top of glebius@'s kadmin-dump-MIT branch of > https://github.com/glebius/FreeBSD. > > Once built with "WITHOUT_MITKRB5=3D"yes" in /etc/src.conf > and installed, there is a new option for "kadmin -l dump" called > "-f" and my patch modifies "-f" so it can take a filename instead > of "MIT" or "Heimdal". > > Here's how you test it (once your Heimdal KDC system has > been patched): > On the MIT KDC system: > # mkdir /var/db/krb5kdc <-- maybe the installer should do this? > - copy kdc.conf and kadm5.acl into this directory and edit them > for your Realm, etc. > - copy an MIT krb5.conf in /etc/krb5.conf and edit this one as well. > (I've attached the three files I use as very basic examples.) > Once you've done this: > # kdb5_util create -s > should work. > > Now, copy /var/db/krb5kdc/.k5.YOUR.REALM over to the > Heimdal KDC system. > Then go to the Heimdal KDC system and... > # kadmin -l dump -f .k5.YOUR.REALM mit.dump > Now, copy mit.dump over to the MIT KDC system and > on the MIT KDC system... > # kdb5_util load -update mit.dump > > And, at least if the principals on the Heimdal KDC > have keys for at least one of: > aes256-cts-hmac-sha1-96 > aes128-cts-hmac-sha1-96 > they should work. Maybe there should be an additional option on "kadmin -l dump" that allows weak encryption keys through. (I'm not sure if you can still enable them in the MIT KDC?) This is a little more work than it sounds, since you need to pass the info into entry2mit_string_int() and it currently does not have any argument for stuff like flags. The problem is that, if you let them through (as in onto the mit.dump) and they are not enabled for the KDC, kadmin.local will report the principal entry as "incomplete or corrupted" and you cannot do anything with it. rick > > For principals that do not have keys for either of > the above two etypes, you should still be able to > see the principal via "get_principal " in > kadmin.local. > If you can see it, a change_password in kadmin.local > should get it working. > > Hopefully people with Heimdal KDCs can test this? > > rick > > > > > > > > > > > > rick > > > > > > > > > > Oh, and one more thing... > > > > > > > - If there are keys for old encryption types like des.. or ar= cfour.. > > > > > > > in the MIT dump, > > > > > > > those will screw up the load. (You can check and delete the= m in the > > > > > > > Heimdal-1.5.2 > > > > > > > kdc system via.. > > > > > > > # kadmin -l > > > > > > > get > > > > > > > - if old keys are listed in Keytypes: > > > > > > > del_enctype > > > > > > > exit > > > > > > > > > > > > > > Ideally the conversion code would skip over these and not pu= t them in the dump. > > > > > > > > > > > > > > rick > > > > > > > ps: If you don't do this, when you "get_principal" in kadmin.= local on > > > > > > > the MIT KDC > > > > > > > system, it will give you a "Database record is incomple= te or corrupted..". > > > > > > > > > > > > > > > > > > > > > > > > > I will finalize the branch promptly and share it. The ab= ove experience also > > > > > > > > > indicated that I need to do a library version bump. > > > > > > > > I don't know if you are enthusiastic about pursuing this, b= ut hopefully this > > > > > > > > works and gets the principals in (although I doubt the pass= words will > > > > > > > > work without changing them). > > > > > > > > > > > > > > > > To get the passwords to work, I think the following *might*= do it: > > > > > > > > - If you look in the Heimdal sources, when "--decrypt" is s= pecified, > > > > > > > > I think it finds its way down into a function called hdb_= unseal_key_mkey() > > > > > > > > which decrypts the key using the master key by calling _h= db_mkey_decrypt(). > > > > > > > > To get the passwords to work, I think the call to _hdb_mk= ey_decrypt() would > > > > > > > > need to be followed by a call to _hdb_mkey_encrypt() with= the "key" > > > > > > > > argument being the master key for the MIT database. (It i= t a keytab > > > > > > > > entry called /var/db/krb5kdc/.k5.YOUR.REALM created when = you do a > > > > > > > > "kdb5_util create -s" on the system that will be the MIT = KDC.) > > > > > > > > - Just to make it even more fun, there is a flag called H= DB_KU_MKEY > > > > > > > > which is set to the Heimdal way and not for the MIT way= (whatever > > > > > > > > that really means?). > > > > > > > > - There is also some stuff about padding in hdb_unseal_ke= y_mkey(), > > > > > > > > but hopefully that won't be a problem? > > > > > > > > > > > > > > > > I think hdb_read_master_key() can be used to read in the MI= T master > > > > > > > > key from the file you provide as an argument to it. > > > > > > > > > > > > > > > > This all is just a hunch, based on what I've seen so far. > > > > > > > > > > > > > > > > I'll admit since the hardware I have takes forever to "make= buildworld" > > > > > > > > and I don't know a quick way to build/test these changes, I= 'm not > > > > > > > > inspired to try it. > > > > > > Although not inspired, I have taken a stab at it. > > > > > > I am still trying to figure out how to build/test it, but I hav= e forked > > > > > > glebius@'s github and added some code to... > > > > > > - Not dump the weak encryption keys (they just cause MIT's kadm= in.local > > > > > > to complain that the principal's database entry is corrupted. > > > > > > - If the argument to "kadmin -l dump" is "-f " instead > > > > > > of "-f MIT" it re-encrypts the keys in MIT's master key. (I h= ope that will > > > > > > make the passwords work. > > > > > > (Basically, someone will "kdb5_util create -s" on the MIT KDC= system > > > > > > and then copy the /var/db/krbkdc/.k5.YOUR.REALM file over to= the > > > > > > Heimdal KDC system and do "kadmin -l dump -f <.k5-filename> = mit.dump" > > > > > > then copy "mit.dump" over to the MIT KDC system and > > > > > > "kdb5_util load -update mit.dump". Then, hopefully, the prin= cipals will > > > > > > work??) > > > > > > > > > > > > Anyhow, it is currently sitting here: > > > > > > github.com/rmacklem/FreeBSD in the kadmin-dump-MIT branch. > > > > > > (I'm as unconversant with git and github as anyone, so if you h= ave > > > > > > trouble finding it, just let me know.) > > > > > Actually, it hasn't made it there yet. For some reason (I think i= t is > > > > > glebius@s large # of branches) it takes a very long time to "git = push" > > > > > a patch involving 4 files. It failed after over an hour with an u= nexpected > > > > > TCP disconnect. I am running it again. > > > > > > > > > > I will stick the patch here, in case the push fails again. > > > > > (It needs to be applied on top of glebius@'s kadmin-dump-MIT bran= ch. > > > > The patch is here. (For some reason, I couldn't push so I deleted t= he > > > > github fork.) > > > > https://people.freebsd.org/~rmacklem/kadmin.patch > > > > > > > > I haven't yet been able to test it, but will be able to do so later= to-day, rick > > > > > > > > > > > > > > Meanwhile I've given up trying to build it on a universe system a= nd > > > > > an now trying the "make buildworld" locally. This will take days, > > > > > so I guess I'll go do something else.;-) > > > > > > > > > > rick > > > > > > > > > > > > > > > > > I'll keep updating this github fork as I get to test it, but if= others > > > > > > know how to build it, feel free to test, rick > > > > > > > > > > > > > > > > > > > > > > rick > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gleb Smirnoff