From abz at mailo.com  Wed Jul  2 12:32:43 2025
From: abz at mailo.com (Arnaud Bouchez)
Date: Wed, 2 Jul 2025 18:32:43 +0200
Subject: Impossible to log into a MS AD 2025 from a 32-bit GSSAPI system
Message-ID: <7200ec9f-1c14-48c4-8502-ba675ff848c3@mailo.com>

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



From kenh at cmf.nrl.navy.mil  Wed Jul  2 14:47:52 2025
From: kenh at cmf.nrl.navy.mil (Ken Hornstein)
Date: Wed, 02 Jul 2025 14:47:52 -0400
Subject: Impossible to log into a MS AD 2025 from a 32-bit GSSAPI system
In-Reply-To: <7200ec9f-1c14-48c4-8502-ba675ff848c3@mailo.com>
References: <7200ec9f-1c14-48c4-8502-ba675ff848c3@mailo.com>
Message-ID: <202507021847.562IlrTk026734@hedwig.cmf.nrl.navy.mil>

>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

Interestingly enough, I used to have the reverse problem.  Specifically,
we had one user who used one system (pre-Unix MacOS Kerberos client)
which had an epoch before the usual 1-1-1970, and for reasons I never
quite understood their time got reset a LOT to this epoch value.  When
they would try to authenticate we'd get this error on the KDC, but then
the request was dropped so they saw it as "couldn't contact any KDC".
Drove me nuts until I figured it out.

Personally I think your workaround is fine; I am not sure what systems
with a 32-bit time_t are supposed to do after Y2038 anyway.

--Ken