Hello,
Another Windows Server 2025 Active Directory issue.
"For accounts with no password expiry, we moved the Kerberos expiry out
to 2100, so that our products will continue working past 2037."
Source:
https://techcommunity.microsoft.com/discussions/windowsserverinsiders/server-2025-domain-join-error-asn-1/4351355/replies/4384450
Sounds like a killer changed from Microsoft. Not a very kind move with
our POSIX systems.
In short, from a 32-bit client (tested on both x86 and armf), a kinit
with such a user account fails with the message:
ASN.1 failed call to system time library while getting initial
credentials
So we can't authenticate to this MS AD 2025 from a 32-bit POSIX system.
No problem with 64-bit systems (tested on both x86_64 and aarch64).
And in fact, over ASN.1 the date is in YYYYMMDDhhmmssZ format, something
like 21003112000000Z, which seems to trigger a 32-bit overflow because
time_t is defined as a signed int, and such value is decoded as <0 on
unsigned arithmetic.
The code in src/util/support/gmt_mktime.c seems correct, it uses 32-bit unsigned value for its calculation, or the timegm() system function.
The problem seems to be that time_t is a signed int, and on a 32-bit
system, the value is too big.
IMHO we could just fix it at ASCII level, since fixing time_t is likely
to be out of scope.
If YYYY > 2038, we could just put 2038 in the first 4 chars, then decode
this time. It will be wrong, but valid.
See function k5_asn1_decode_generaltime() in
https://github.com/krb5/krb5/blob/master/src/lib/krb5/asn.1/asn1_encode.c#L241
Perhaps there is a better workaround.
Arnaud
PS: someone feel free to react to my previous message about krb5_change_password- could never hurt to adapt our client code base to
MS AD 2025 "features".
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)