I've been dealing with a bizarre issue in my network where authentication failures are occurring in exact 37-minute cycles. This has been ongoing for three months, affecting about 5-10 users daily across two sites with 800 clients and multiple Domain Controllers (DCs). Despite running various diagnostics, I can't pinpoint the source of the problem.
Here are the details of my environment:
- Four Domain Controllers running Windows Server 2019, two at each site connected via a 1Gbps MPLS.
- ~800 Windows 10/11 clients.
- Azure AD Connect for hybrid identity, all DCs as Global Catalogs, and functional level 2016.
Users report that they receive "wrong password" errors but can usually log in successfully on retry. I've logged extensive Kerberos events and discovered that failures happen in 37-minute intervals.
I've ruled out several potential causes like time synchronization, replication delays, Kerberos policy configurations, and more. Strangely, this pattern began on the day I added a new Domain Controller (DC04), but after demoting and removing it, the issue persisted.
I'm at my wits' end and considering whether there's an obscure timer or scheduled task causing this. Anyone have insights or have dealt with anything similar?
5 Answers
Have you tried enabling detailed logging for netlogon and Kerberos on your DCs? It could provide insights into why you're getting those pre-authentication failures at that exact interval. Capturing network packets during those times could also be revealing.
Since you're seeing unique patterns, have you checked for any periodic changes in Kerberos encryption types after recent patches? Sometimes, an overlooked Kerberos maintenance task could be involved.
Have you looked into Azure AD Connect? Its sync interval is about 30 minutes, so there could be some interference there. You might want to adjust the sync schedule to see if that impacts the issue.
That's a good point! I've typically noticed it taking about 35-40 minutes for delta syncs, might be worth checking that.
Have you thought about powering off each of your DCs independently for at least 90 minutes? If it's truly a 37-minute cycle, isolating a potentially faulty DC might reveal something. It could be that one specific DC is causing the failures, even if it's not the one you recently decommissioned.
I recommend looking for any scheduled tasks that may be present. Years ago, I encountered a similar issue in a Citrix environment where a residual scheduled task caused seemingly random corruption events based on really bizarre timing. So, definitely worth a check.
That’s true! I hadn’t fully explored Kerberos tasks yet; I'll dig into that.