Forum Discussion
Server 2025 Domain Join Error ASN.1
I've been investigating this, and I think I can see where the problem is. Part of domain joining is to get a kerberos ticket from the server. When Windows Server responds to a request for a kerberos ticket, there's an authentication exchange. As part of this, the Server includes information about the expiry of the account's password. This allows the client program (e.g. kinit) to implement a password update process if the user's password is about to expire.
I found that the problem only occurs for accounts where the password is set to never expire - such as Administrator. When I used an account with password expiry enabled, the kerberos transaction works.
It seems that when the password is set to 'never expire', Windows server sends a date way out in the future. With Windows Server 2025, this is in January 2100. This date is beyond the Unix epoch limit in 2030. If the kerberos/samba software on your device was built against libraries that expect dates within the Unix epoch limit, they will throw this error - ASN.1 is a common encoding scheme used to send values between systems that may natively use different ways of recording data types, and so it's the ASN.1 decoding library that's trying to make sense of this future date.
Presumably, older versions of Windows used some more imminent date within the epoch to signal 'non expiry' but now that 2030 is getting closer, that's not going to fly for much longer...
Although it's possible to enable password expiry for user accounts, and work around the issue by making Windows send a closer future date, it doesn't appear to be possible for computer accounts. I haven't found any workaround for it yet. I suspect it'll require a firmware update on your device unless Microsoft decides to provide a backwards-compatible option in a future update.
I was able to confirm this suspicion today when I found out how to decrypt Kerberos packets!
I can clearly see that connected to a Windows 2025 domain, the AS-REP response from the domain controller contains a key-expiration date in 2100 for a computer account (and likely any account with no password expiry).
Reconnecting to a Windows 2022 domain (which works fine) the same exchange returns a key-expiration date in 2037 for a similar account.
When a client program receives that and tries to convert the date in 2100 to a regular system time value, many older systems will fail because their time value in seconds since an epoch start date of 1 Jan 1970 is stored as a signed 32-bit value and that value overflows (after just over 2 billion seconds) in January 2038.
I can see why Microsoft want to future-proof this by choosing a future date, but in doing so they have likely broken a lot of older systems. Perhaps they will reveal that there is a hidden registry key that can revert this new behaviour...