Re: heimdal -> MIT kdc migration
- Reply: Rick Macklem : "Re: heimdal -> MIT kdc migration"
- In reply to: Rick Macklem : "Re: heimdal -> MIT kdc migration"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 30 Aug 2025 15:56:21 UTC
On Fri, Aug 29, 2025 at 1:05 PM Rick Macklem <rick.macklem@gmail.com> wrote: > > On Fri, Aug 29, 2025 at 7:43 AM Rick Macklem <rick.macklem@gmail.com> wrote: > > > > On Wed, Aug 27, 2025 at 8:39 PM Rick Macklem <rick.macklem@gmail.com> wrote: > > > > > > On Wed, Aug 27, 2025 at 7:43 PM Rick Macklem <rick.macklem@gmail.com> wrote: > > > > > > > > On Tue, Aug 26, 2025 at 9:35 AM Gleb Smirnoff <glebius@freebsd.org> wrote: > > > > > > > > > > On Tue, Aug 26, 2025 at 08:31:13AM -0700, Gleb Smirnoff wrote: > > > > > 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 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 passwords. > > > > > 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 compile. 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 merged 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. When run correctly, > > > > > it successfully produced something that looks like a correct dump in MIT format. > > > > > I haven't yet tried to load it into MIT kdc yet, though. > > > Oh, and one more thing... > > > - If there are keys for old encryption types like des.. or arcfour.. > > > 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 <principal> > > > - if old keys are listed in Keytypes: > > > del_enctype <principal> <enctypes> > > > 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.local 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 above 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 passwords 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 specified, > > > > 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 _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 the "key" > > > > argument being the master key for the MIT database. (It it 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 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 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 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 <mit-master-key-file>" instead > > of "-f MIT" it re-encrypts the keys in MIT's master key. (I hope 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 principals 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 have > > 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 push" > a patch involving 4 files. It failed after over an hour with an unexpected > 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 to-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 others > > know how to build it, feel free to test, rick > > > > > > > > > > rick > > > > > > > > > > > > > > -- > > > > > Gleb Smirnoff