Impossible to log into a MS AD 2025 from a 32-bit GSSAPI system

[Arnaud Bouchez]

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".