I'm curious if anyone has dealt with issues regarding the KRBTGT password rollover process affecting Exchange authentication. I followed the standard script from zjorz on GitHub to perform this rollover. After running it, I did the usual checks on Active Directory health, logged into servers, rebooted a couple of systems, and didn't notice any immediate problems. However, about 10 hours post-rollover, my Outlook (both desktop and mobile) began facing authentication failures with our four-node Exchange 2016 servers, though OWA was still working fine. A reboot of each Exchange server seemed to resolve the issue at that time, but it cropped up again around 10 hours later, requiring a reboot of just one server. The event logs noted error code 4625 "An account failed to log on." I'm hesitant to rerun the script until I fully understand if there's a connection between this password rollover and the authentication errors since most posts I've seen suggest it's a smooth process. We didn't have any problems with the same procedure six months ago.
4 Answers
It sounds like you might be facing a different issue unrelated to the password rollover. I'd advise checking your authentication logs. If you only reset the password once, it’s possible the secondary password on the account is still valid and stored, which could be why you weren't experiencing issues at first.
Make sure everyone's time settings are correct—check your Domain Controllers, Exchange servers, and workstations. Also, verify if replication is functioning smoothly. You can use the KLIST command to check which Kerberos tickets are expiring and address any issues there.
It’s supposed to be a straightforward process, so this situation is definitely unusual. If I were you, I’d try reproducing the issue in a lab environment with a fresh setup (domain, Exchange, etc.) and then gradually introduce your production configurations to see if you can replicate the problem. If you can reproduce it in the lab, you’re on the right track. If there’s a defect in the code, reach out to Microsoft support; they might refund your support cost if it’s proven to be a defect.
Setting up a lab does take time, especially if we need to wait 10 hours to see if it causes a similar issue. Still, it might just be necessary to isolate the problem.
Quick question—are any of your Domain Controllers running 2025? That could have implications on authentication as well.
Totally agree! Just seems odd since everything went smoothly right after the first run. The timing of the issues is what's curious—hitting around 10 hours after. A few more experienced team members are diving into the authentication logs to see what’s up.