From nobody Mon Sep 08 20:08:16 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 4cLJ1H4RfMz6739j for ; Mon, 08 Sep 2025 20:08:35 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 4cLJ1G5wzgz4007; Mon, 08 Sep 2025 20:08:34 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b="EPG76BD/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::531 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-623720201fdso4918224a12.1; Mon, 08 Sep 2025 13:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757362108; x=1757966908; 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=fvL0bwGQKiX8F7Z1co0r00QQVuaZSyI98NSlR8YgmvE=; b=EPG76BD/ZeW6nGlFMhjEuO1UpvuyEoigQiWRYqNaKdwGz1lrvfI9vC0FV4UfIZKooD tyQVQzRwYpu71JpikCTVxIajM0U564jyuQlEz9aDeeat19V/t9fe1qBfRxPq3rr6QsT0 jSgv0zoXhzogQw9rGmiC8pzdpXia+Vf7LYUXtuM09A3rNuvUQ9hfZtgeFg8PoWzR2unq plmM6Q401FIVeYWQL0lbOfDkuz3Tcop7F/Ve19heSMUf3w8fNVbmU7fThAuSL25QDXv5 LYb5F50dhO5egktYzntEQ3NYy6QjneMlEi0GtNxCa73AxvFQXHTM7v6fQpZzbS4tI628 +utw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757362108; x=1757966908; 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=fvL0bwGQKiX8F7Z1co0r00QQVuaZSyI98NSlR8YgmvE=; b=fL348RIini3Wm/Jb2rU19A2bJ6xS+war+tQ1vf4eQ/f9qLCudnNDZ3ptrrCoxs3btL hzbxKg2wEPjj6fBprz330pZxP8b19XlN6KTA227KSgrp+vXqtBDlo1Tj3S5LQJofGeH5 ygOG0bCsw6vtCE1aQ3VlUFYaymnRNLHYr0roZOBgsKMaZFfhRP3RuqfQeKzQzksHU945 k94j3lx3rCfAx7akASxDO9RZezNXwZNQfM9LOd93Are0yMb906VDk+Ep33ZOLU4kM+dr XdTPoDkT1vo9iGflls3xftHyS2MqdoN+f45pN38/yLoLGIhk8N/f4BcvsdNdi/NVCD17 MULw== X-Forwarded-Encrypted: i=1; AJvYcCU6byep05VMmo+W3XAckAuBNavrNVKRXrw8f52FhrCU1x6iG4JDan6VZQRxA0I8hWv2v/2HV5ttpDzj3oO1Cxw=@freebsd.org X-Gm-Message-State: AOJu0YzeAvberx+hCnvCVY0pSbGUY2Fu0rSguD2lZrjeXmIForWNb64g 4pGznVdlSEvdi3Q5V/3zBeqxhxmG1gTfj7rQJohhXlOQdzC93OmU6pXjm46Ty2weXIiE4PyO0bx O4XlbKG2Vdi2o3v6RsmrOfOXwW6aj4AQn X-Gm-Gg: ASbGncspeyEFhXiRjqa3bwZnT6wWVPdLozJT+3DmnCG2zzuc7rCQZ4pqP8K286bFGNs Dw2iWYKEpjmborkjs2NCGZscK5Fw5LGTL26e260d/mxOognGIGcE0kfvf9Hiucia5QmjABafEhY gcesCYZzA3GCHkiVC/CQB6GD6eECh2PqXnm5WeY9XDHyBtO5nS+wEJGmUjrHWkH9g9IXhk4TT+D VpOsxtD+wlzaOQ6n3k6sa1Tn0Xb24MuLZ4uXgM= X-Google-Smtp-Source: AGHT+IGVGtKAhBr6+vFeAZjjKkngd0etrR6IvDE6lAY6yE41XiFJ7IG3RpWI2t1YhC6cXMQslT9+y1zUFqbXXf1JxvQ= X-Received: by 2002:a05:6402:40c2:b0:62a:f712:3986 with SMTP id 4fb4d7f45d1cf-62af7123bc9mr2101171a12.10.1757362107998; Mon, 08 Sep 2025 13:08:27 -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> <20250903043714.370F5311@slippy.cwsent.com> In-Reply-To: From: Rick Macklem Date: Mon, 8 Sep 2025 13:08:16 -0700 X-Gm-Features: AS18NWD2lMFHD8vSpEVzdLQqtkBo9-rq4XM_s7aG9NRLZK4ufeHZkbfcW6pBXA8 Message-ID: Subject: Re: heimdal -> MIT kdc migration To: Cy Schubert Cc: Gleb Smirnoff , freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_ENVFROM(0.00)[gmail.com]; 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::531:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4cLJ1G5wzgz4007 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 wrote: > > > > On Tue, Sep 2, 2025 at 9:37=E2=80=AFPM Cy Schubert wrote: > > > > > > In message > > om> > > > , Rick Macklem writes: > > > > On Sun, Aug 31, 2025 at 5:58=3DE2=3D80=3DAFPM Rick Macklem > > > m> wrote: > > > > > > > > > > On Sun, Aug 31, 2025 at 5:41=3DE2=3D80=3DAFPM Rick Macklem > > > com> wrote: > > > > > > > > > > > > On Sat, Aug 30, 2025 at 9:47=3DE2=3D80=3DAFPM Rick Macklem > > > l.com> wrote: > > > > > > > > > > > > > > On Sat, Aug 30, 2025 at 4:22=3DE2=3D80=3DAFPM Rick Macklem > > > 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. > Also, someone needs to document this. > The Handbook section does a nice job of explaining > the setup of a Heimdal KDC, but has nothing w.r.t. > setting up an MIT KDC nor converting the KDC database > over to it. > > rick > > > > > > > I think the problem is with OpenSSL 3.5. With the legacy provider loa= ded in > > > OpenSSL 3.5 I get, > > > > > > test3# openssl list -providers > > > Providers: > > > default > > > name: OpenSSL Default Provider > > > version: 3.5.1 > > > status: active > > > test3# > > > > > > Whereas in 3.0 I get, > > > > > > bob# openssl list -providers > > > Providers: > > > default > > > name: OpenSSL Default Provider > > > version: 3.0.16 > > > status: active > > > legacy > > > name: OpenSSL Legacy Provider > > > version: 3.0.16 > > > status: active > > > bob# > > > > > > Some symbol must be missing. > > Ok, I seem to have missed something here? > > Just in case it wasn't clear, I was referring to testing of the > > kadmin patches for the old Heimdal, so that the KDC database > > can be moved to an MIT KDC and still work. > > > > rick > > > > > > > > > > > -- > > > Cheers, > > > Cy Schubert > > > FreeBSD UNIX: Web: https://FreeBSD.org > > > NTP: Web: https://nwtime.org > > > > > > e**(i*pi)+1=3D0 > > > > > >