From nobody Mon Sep 01 00:41:45 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 4cFVSZ5SQ9z65S5b for ; Mon, 01 Sep 2025 00:42:06 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 4cFVSZ02yFz4Mg5; Mon, 01 Sep 2025 00:42:05 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=DNr1Jf3E; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-61cb4374d2fso5312637a12.2; Sun, 31 Aug 2025 17:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756687318; x=1757292118; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QT2RAk2cN+XkoS6hsh8ecS70ykt3m3+EtxtglhBTySo=; b=DNr1Jf3Ez6+zjzo7P8stUIbHniSHMds4NmevdcDAhDWJ9PnmKZlVxnlRqF2IenFeBf E2gJuuEvU4VbF7SYB3KaRFHgIOSZU/ffIK19yD55Hrx4TOt53QQGtswKrzkW70qDKB28 kAHanOj/LOX0bVX4MkjttBvJMQWY9K3hmqVQi+CSr9FgpQWlA1/kFPiklcX9t5yzUN+/ KmqNmINMNwuIUc9c/O8DEM/ykj7uH+1jDgGQNLPkqPVefzDcM1zawjiN82VBGApefnqS ev/16bRe2sqljctszZbyL1u3adxDV7C/+XDtpMYy/I6cm9mMSXNnzrDM4z1AcdxNv+F9 U8IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756687318; x=1757292118; h=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=QT2RAk2cN+XkoS6hsh8ecS70ykt3m3+EtxtglhBTySo=; b=JWiB39w0nFANhFprFXOISBO7CAogAOeELrK+frx+3a/2Vq/EF10mSnejIZO4yzYzzA fbUIIvoRN2H5HCHl2MqlFizEoFl1douyzve//vvI3AioTdQz7z1tfQv/NkqphcPAx24E uEqTHgPyIb87LcmJNtmm8P5BEtaSkECGfYsAZlDdfkFhR9gWMU96R4dDR3O9x26/I1Hm 1PPCrXlqk6uGLO8rRPy6ot31fNCzEMZ1xhgZ0OaM9XX8LU4DW0B4BEZvMHw3xEqiX+ar mtw692fekH1N9pGUrUpSY3HYcE2eq5qipV/a3OtH6mKizgk5hvA+bk8rZIWBYKH1FB3Z 5qmQ== X-Forwarded-Encrypted: i=1; AJvYcCVUDqHNcwikHMMRdAufD0X21LCRe3BfjGS1+aTxChMQNyYvMy5BTDYXWZOs3lDiCNWEz2OKkEERKmGj94Bdk7E=@freebsd.org X-Gm-Message-State: AOJu0YzBshES7d4FvbNracFh23KismAGCbf9JGDaG3OQnuLPzTBVFYFe jn0OBPkKAsmtH7LN7nPutDa3Tx0G5x1Tal/dph2QZ+9LipRWja/IRpA31X73H1OXSs5TusxIdFf TmGIinTGhQQp4NF5taS2y7uiboRZtLLu9UzM= X-Gm-Gg: ASbGnct2JcJzdxCwoGKi9vQtNMuyCYDB7yviVCFF5r7Cz21OJ5QMQlpHaSrHnc/Q86T pVOM2w95YpSe+vmv9+2r+y+2YlQ7B7FQs2WiEwmzq/Otm1vhTaVRMkSt9YxtMBXOOjNY3wxN6mV 8bWiQULvFMNrWJJK+G4L2hGjJ4HevG3mqr3UkLjng3qRAozN1FJaIa9nrekreK4E27E91w1Scyf /tK5HmPP5RZuzpqc3NY5hjNEOXk6+t13FXyL+Ih/quZd1TDSA== X-Google-Smtp-Source: AGHT+IFGCH02Iy92hGbSSKa0zMs2+jAaEIuXv9LKNd/wK8lQ6qIywwdX6Ru9io6fN2Bpk6oScuZ5v9KWAXFJVwnCfQQ= X-Received: by 2002:a05:6402:51c8:b0:61e:3b86:aaba with SMTP id 4fb4d7f45d1cf-61e3b86ab31mr2781085a12.30.1756687317394; Sun, 31 Aug 2025 17:41:57 -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:41:45 -0700 X-Gm-Features: Ac12FXxvp3Awea9-fovvi3JrzHpW4OJevPMAQjOqkW96Elb3s2WyZDjnC3n8O1c Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Gleb Smirnoff Cc: Cy Schubert , freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="000000000000898d10063db2a36f" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.995]; 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)[multipart/mixed,text/plain]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~,3:~,4:~]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; 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]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cFVSZ02yFz4Mg5 --000000000000898d10063db2a36f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wro= te: > > > > > > > > T> On Tue, Aug 26, 2025 at 08:13:26AM -0700, Rick Macklem w= rote: > > > > > > > > T> R> Ok. If you install FreeBSD-13.5 and then "pkg install= heimdal", you get a > > > > > > > > T> R> working Heimdal-7.8 in ports. > > > > > > > > T> R> > > > > > > > > T> R> Now, I have another challenge. Fixing the master pass= words. > > > > > > > > T> R> I'll work on it later to-day. > > > > > > > > T> > > > > > > > > T> I have applied two commits from Heimdal from 2012 that a= dd 'kadmin dump -f MIT' > > > > > > > > T> feature to our base heimdal and polished them to compile= . So far it doesn't > > > > > > > > T> work yet, either create an empty dump or create a core d= ump, instead of > > > > > > > > T> database dump :) I'll see how difficult it is going to f= urther 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 merge= d to FreeBSD 14.4. > > > > > > > > > > > > > > > > Good news. In the above paragraph I was testing my change = incorrectly - threw > > > > > > > > the new binary on a system running unpatched libraries. Wh= en run correctly, > > > > > > > > it successfully produced something that looks like a correc= t 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 encryption = 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 m= ust > > be changed before it works. > > --> This is the same behaviour as you get if you use Heimdal-7.8 to do = 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 mas= ter > > key to see why it ends up at 62bytes and whether that can be 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?). > > > > Or do we just say "When you convert the KDC database, all the passwords > > 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. 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 arcf= our.. > > > > > > in the MIT dump, > > > > > > those will screw up the load. (You can check and delete them = 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 put = them in the dump. > > > > > > > > > > > > rick > > > > > > ps: If you don't do this, when you "get_principal" in kadmin.lo= cal on > > > > > > the MIT KDC > > > > > > system, it will give you a "Database record is incomplete= or corrupted..". > > > > > > > > > > > > > > > > > > > > > > I will finalize the branch promptly and share it. The abov= e experience also > > > > > > > > indicated that I need to do a library version bump. > > > > > > > I don't know if you are enthusiastic about pursuing this, but= hopefully this > > > > > > > works and gets the principals in (although I doubt the passwo= rds will > > > > > > > work without changing them). > > > > > > > > > > > > > > To get the passwords to work, I think the following *might* d= o it: > > > > > > > - If you look in the Heimdal sources, when "--decrypt" is spe= cified, > > > > > > > I think it finds its way down into a function called hdb_un= seal_key_mkey() > > > > > > > which decrypts the key using the master key by calling _hdb= _mkey_decrypt(). > > > > > > > To get the passwords to work, I think the call to _hdb_mkey= _decrypt() would > > > > > > > need to be followed by a call to _hdb_mkey_encrypt() with t= he "key" > > > > > > > argument being the master key for the MIT database. (It it = a keytab > > > > > > > entry called /var/db/krb5kdc/.k5.YOUR.REALM created when yo= u do a > > > > > > > "kdb5_util create -s" on the system that will be the MIT KD= C.) > > > > > > > - Just to make it even more fun, there is a flag called HDB= _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_key_= mkey(), > > > > > > > but hopefully that won't be a problem? > > > > > > > > > > > > > > I think hdb_read_master_key() can be used to read in the MIT = 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 b= uildworld" > > > > > > > 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 have = forked > > > > > glebius@'s github and added some code to... > > > > > - Not dump the weak encryption keys (they just cause MIT's kadmin= .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 hop= e that will > > > > > make the passwords work. > > > > > (Basically, someone will "kdb5_util create -s" on the MIT KDC s= ystem > > > > > and then copy the /var/db/krbkdc/.k5.YOUR.REALM file over to t= he > > > > > Heimdal KDC system and do "kadmin -l dump -f <.k5-filename> mi= t.dump" > > > > > then copy "mit.dump" over to the MIT KDC system and > > > > > "kdb5_util load -update mit.dump". Then, hopefully, the princi= pals 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 hav= e > > > > > trouble finding it, just let me know.) > > > > Actually, it hasn't made it there yet. For some reason (I think it = is > > > > glebius@s large # of branches) it takes a very long time to "git pu= sh" > > > > a patch involving 4 files. It failed after over an hour with an une= xpected > > > > 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 branch= . > > > The patch is here. (For some reason, I couldn't push so I deleted the > > > 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 t= o-day, rick > > > > > > > > > > > Meanwhile I've given up trying to build it on a universe system and > > > > 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 o= thers > > > > > know how to build it, feel free to test, rick > > > > > > > > > > > > > > > > > > > rick > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Gleb Smirnoff --000000000000898d10063db2a36f Content-Type: application/octet-stream; name="kadm5.acl" Content-Disposition: attachment; filename="kadm5.acl" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mf0e8riu0 Ki9hZG1pbkBIT01FLlJJQ0sJKgo= --000000000000898d10063db2a36f Content-Type: application/octet-stream; name="krb5.conf" Content-Disposition: attachment; filename="krb5.conf" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mf0e93d01 W2xpYmRlZmF1bHRzXQoJZGVmYXVsdF9yZWFsbSA9IEhPTUUuUklDSwoKW3JlYWxtc10KCUhPTUUu UklDSyA9IHsKCQlrZGMgPSAxOTIuMTY4LjEuMTUKCQlhZG1pbl9zZXJ2ZXIgPSAxOTIuMTY4LjEu MTUKCX0KCltkb21haW5fcmVhbG1dCgkuaG9tZS5yaWNrID0gSE9NRS5SSUNLCgpbbG9nZ2luZ10K CWtkYyA9IEZJTEU6L3Zhci9sb2cva3JiNWtkYy5sb2cKCWFkbWluX3NlcnZlciA9IEZJTEU6L3Zh ci9sb2cva2FkbWluLmxvZwoJZGVmYXVsdCA9IEZJTEU6L3Zhci9sb2cva3JiNWxpYi5sb2cKCg== --000000000000898d10063db2a36f Content-Type: application/octet-stream; name="kdc.conf" Content-Disposition: attachment; filename="kdc.conf" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mf0e9fki2 W2tkY2RlZmF1bHRzXQoJa2RjX2xpc3RlbiA9IDg4CglrZGNfdGNwX2xpc3RlbiA9IDg4CglkZWZh dWx0X3JlYWxtID0gSE9NRS5SSUNLCgpbcmVhbG1zXQoJSE9NRS5SSUNLID0gewoJCWRhdGFiYXNl X25hbWUgPSAvdmFyL2RiL2tyYjVrZGMvcHJpbmNpcGFsCgkJYWNsX2ZpbGUgPSAvdmFyL2RiL2ty YjVrZGMva2FkbTUuYWNsCgkJa2V5X3N0YXNoX2ZpbGUgPSAvdmFyL2RiL2tyYjVrZGMvLms1LkhP TUUuUklDSwoJCWtkY19saXN0ZW4gPSA4OAoJCWtkY190Y3BfbGlzdGVuID0gODgKCQltYXhfbGlm ZSA9IDEwaCAwbSAwcwoJCW1heF9yZW5ld2FibGVfbGlmZSA9IDdkIDBoIDBtIDBzCgl9Cg== --000000000000898d10063db2a36f--