Forum Discussion
Server 2025 Domain Join Error ASN.1
hallo
we wanna join an appliance (cisco ISE) to our domain/forest and get an error. Domain Controllers was updated from Server 2022 to Server 2025 preview it was ok with the appliance in ad.
With Server 2025 final we get this error:
Test Name :Kerberos test obtaining join point TGT
Description :Tests TGT Obtaining in joint point
Instance :CCLOUD-AD
Status :Failed
Start Time :10:13:54 22.11.2024 MET
End Time :10:13:54 22.11.2024 MET
Duration :<1 sec
Result and Remedy...
Could not obtain TGT : ASN.1 failed call to system time library. Check Kerberos related AD configuration
What we done in troubleshooting, yet:
DNS Resoluion works. domain is resolvable
NTP is ok and correct time from pdc and synced to all other DCs and Clients/Servers
domain join user credentials and permission are correct
We tested also with an Domain Admin User/Cred
Container/OU and Computer Object Permissions/Owner rights are set to the join account.
Delete and let the Appliance create a new Object did not work
can anyone help with ideas?
9 Replies
MSBernsteinMicrosoft
RichBaldry I'm impressed with your investigative work on this! It helped me to have a fruitful conversation with the engineering team. Your intuition is correct: we are quite concerned about the 2037 limit, which is not very far away. For accounts with no password expiry, we moved the Kerberos expiry out to 2100, so that our products will continue working past 2037. But sone devices do not handle dates properly past 2037.
Our recommendation would be for Cisco and other vendors to update their software to be able to handle dates past 2037 properly -- for the same reason, because 2037 is not so far away. I'm not sure I would call this a ping-pong game -- we all have to work together to handle the 32-bit date limit.
Alternatively, having regular password rotation regimes is a best practice, so enabling password expiry and rotating passwords on a regular basis will both solve this issue and improve your security.I understand. I do work for a vendor with a product similar to Cisco's and we are now making plans to update our Kerberos builds to use 64 bit date values so that the ASN.1 conversion doesn't fail.
Regarding the regular password rotation, this advice is unfortunately no good for situations where it's actually a computer account that is authenticating, as is the case for our device. As far as I can tell it's actually not possible to set an expiry date on a Computer account.
Fixing on our side it is certainly our goal for a long term solution, but I know not all vendors and devices will be able to do the same. In the meantime, a way to revert this on the Windows side would certainly be helpful.
Unfortunately no more information than this from the CISCO side. https://bst.cisco.com/quickview/bug/CSCwn62873
Feels like it will be a ping-pong game between Microsoft and third-party vendors.
Any news from Microsoft when it comes to this issue? Is it planned to be fixed in the February patch routine?
Experiencing a similar issue when attempting to join a host to a Windows Server 2025 domain. "ASN.1 failed call to system time library". If I manually point it to a Windows Server 2022 domain controller, it is able to join the domain without issue.
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.
Thank you for your help. The password never expires uncheck worked for me.
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...
any luck with this, getting a similar error with a firewall trying to authenticate to an upgraded windows 2025 domain
