Hello Erin Teu
We have the same exact problem after updating our DC's to 2025. The Problem can be seen on Windows 10 22H2 PC's as well. Besides the machine password expiration issue, we ran into a problem where our two Cisco radius servers are no longer able to succesfully negotiate with 2025 DC's.
Cisco Support has identified the problem and it points down to a Microsoft kerberos bug. See the reply from Cisco Support below.
Hello, Team
I hope you are doing well today!
My name is Abdullah Lodhi and I am with Cisco Systems AAA team and I will be working on your case SR 698715209.
I have gone through the case notes and I am looking into this issue. So this bug is for Windows Server when it is 2025 the integration with ISE is failing due to a microsoft check. It has been traced back to the krb5 library in the ADRT in the gmt_mktime.c file in the krb5int_gmt_mktime function. In it, there is an explicit check to see if the received timestamp is after the year 2038 and if so, the assert fails and returns -1. The function is called by the asn1_decode_generaltime function in the asn1_decode.c file which then returns the LW_ERROR_KRB5_ASN1_BAD_TIMEFORMAT error.
This flow is triggered by the first TGT obtaining during kerberos. In the AS-REP, AD 2025 sends a default expiry time of year 2100 (expiry time of the session key that is used to encrypt the traffic between the client and the KDC) and when processing this response the ADRT eventually gets to parsing the expiry date and throws the LW_ERROR_KRB5_ASN1_BAD_TIMEFORMAT error.
As from our side the only workaround is to revert back to 2022 Windows AD as there is no fix from Cisco as the issue is on Microsoft Side and we are pending a fix from them. Please let me know if you have any questions in regards to the bug, if not please let me know if we can proceed with case closure.
Thank you,
Until Microsoft releases a fix to our problem, i will set the password expiration date in the meantime to infinit.
Best regards
Christian