The Nubus/UCS specific password checking overlay "k5pwd" for OpenLDAP currently can't handle new hash types calculated with the algorithms "aes128-cts-hmac-sha256-128" (19) and "aes256-cts-hmac-sha384-192" (20). Those are generated by Windows Server 2025 (in addition to the aes256-cts-hmac-sha1-96 (18) and aes128-cts-hmac-sha1-96 (17)). Context: When the AD-Connector reads Kerberos hashes from AD, it doesn't get the "usual" crypt hash stored in the OpenLDAP attribute userPassword. Instead, it writes "{K5KEY}" into it and later, when a user does a plain (non-SASL) LDAP bind, we use a password scheme overlay ("k5pwd") to check the given password against the Kerberos hashes instead.
Created attachment 11373 [details] sha384.py (simple reproducer) The attached script compares the keys we extracted for a test account from MS2025 with the values that Heimdal kerberos generates in UCS 5.2-3. The output shows that the values for the new key types (20 and 19) differ, while the earlier key types match: root@primary20:~# ./sha384.py krb5_keytype: aes256-cts-hmac-sha384-192 (20) keyblock : b'rHQjdh9AhEBnNCSGfHddqarFB8DpvtdkYrmEvOopJ6U=' keyblock (ms2025): b'7ITiJ+rgloeXxg8kzBu4IQF9HVk3iDdD/X8NwRE23hA=' krb5_keytype: aes128-cts-hmac-sha256-128 (19) keyblock : b'IpCfn4pai1hB6VKTX5FouQ==' keyblock (ms2025): b'vVrcCdVSvlTEVWY1X/tUlA==' krb5_keytype: aes256-cts-hmac-sha1-96 (18) keyblock : b'gc/4K0t4lsFJB5brLd1tsvF2A0Upc4/O6BJQj/R4ySY=' keyblock (ms2025): b'gc/4K0t4lsFJB5brLd1tsvF2A0Upc4/O6BJQj/R4ySY=' krb5_keytype: aes128-cts-hmac-sha1-96 (17) keyblock : b'Fg/L2ZBBSnwAo5hlLK/a5Q==' keyblock (ms2025): b'Fg/L2ZBBSnwAo5hlLK/a5Q==' krb5_keytype: arcfour-hmac-md5 (23) keyblock : b'jOEz7XXzMgkpwd/vzCt3NQ==' keyblock (ms2025): b'jOEz7XXzMgkpwd/vzCt3NQ==' # as NThash: b'8CE133ED75F3320929C1DFEFCC2B7735' Could also be a bug in MS (but unlikely) https://techcommunity.microsoft.com/discussions/windowsserver/add-support-for-sha-2-and-sha3-in-supported-kerberos-encryption-types/3961272
Ah to make Heimdal calulate te new key types I has to adjust the krb5.conf by setting: ucr set kerberos/defaults/enctypes/permitted='aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 arcfour-hmac-md5' kerberos/defaults/enctypes/tgs='aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 arcfour-hmac-md5' kerberos/defaults/enctypes/tkt='aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 arcfour-hmac-md5'
We don't seem to be alone with kerbores and windows server 2025 issues: https://github.com/geekwolf-cloud/geekwolf.comments/issues/36#issuecomment-2657391220 ttps://gitlab.freedesktop.org/realmd/adcli/-/issues/40
Could theoretically also be a bug in "keyblock_raw_new" in base/univention-python-heimdal/keyblock.c but IIRC the Samba team supported us implementing it and it looks fairly generic. We use that function in the AD-Connector when re-marshalling the key data from the MS data structure. Jürns Comment 3 leads to https://hachyderm.io/@SteveSyfuhs/113652185587416636 , so it may also be an MS issue after all. We tested with an AWS EC2 instance.
One thing we could improve in k5pwd is to iterate over the hash types and pick one that is in the "permitted_enctypes". That would allow fixing this by adjusting the UCR-Variable and restarting slapd w/o needing to sort out broken krb5Key values.
Ah, I think I've understood the origin of the problem and how to fix it in our OpenLDAP password schema module "k5pwd". The examples in RFC 8009 use 32768 iterations for sha256 and sha384 while for the AES sha1 keys the default is 4096 iterations. This is reflected here in Heimdal: * https://github.com/samba-team/samba/blob/master/third_party/heimdal/lib/krb5/salt-aes-sha2.c#L36 vs * https://github.com/samba-team/samba/blob/master/third_party/heimdal/lib/krb5/salt-aes-sha1.c#L36 But Microsoft seems to use 4096 iterations also for the sha256 and sha384 (which kind of makes sense, because their `default_iteration_count` field in supplementalCredentials is defined across all key types). After reconfiguring the AD KDC of a MS Server 2025 via registry to use 32786 iterations it generated the same key hashes as Heimdal for the new key types (but then the classic AES SHA1 hashes are wrong). I think I know how to fix this in function k5key_chk in 12_k5pwd.quilt in ucs-patches, by calling krb5_string_to_key_data_salt_opaque directly (instead of krb5_string_to_key_salt) and passing the iterations (read from supplementalCredentials field "default_iteration_count", but basically that's 4096). And to be interoperable with MS 2025 we should also adjust the function keyblock_new in base/univention-python-heimdal/keyblock.c in a similar way, to allow passing the iterations. But then, MS doesn't allow us to send AES hashes to them anyway... but we want to play nice.
Via Bug 57747 we adjusted the AD-Connector to only sync the "permitted enctypes" (listed in /etc/krb5.keytab and informed by a UCR variable), so this issue is currently circumvented. https://git.knut.univention.de/univention/dev/ucs/-/issues/3266 has pointers to patches that need to be made to fix this issue (see Comment 6).