[German]Recently a blog reader left a comment within this blog, dealing with an issue in Windows 11 24H2 combined with Microsoft Outlook and Exchange. He noticed that user accounts in the Active Directory are being blocked suddenly on a recurring basis? Searching the web, it seems it's not an isolated case. But I got an explanation and a fix from a German blog reader.
A reader reported a problem
Blog reader CR left thic comment here in the blog and wrote, that he had noticed strange behavior in an AD domain with Windows 11 24H2 as a client. AD user accounts are occasionally blocked. He writes that it seems to him that this only happens when the lock screen of this user is active.
The reader asked whether others had also observed this. In fact, another English-speaking blog reader got in touch to confirm this observation. Both readers later linked to a discussion in the Spiceworks community, where even more users are discussing this problem.
Discussion in the Spiceworks community
In the Spiceworks community there is the post Win11 24H2 update + Outlook client + Exchange account = repetitive AD account locked from October 15, 2024, where someone describes his observation.
He observed that several users had their AD accounts blocked. On the domain controller (DC) in question, there are events with the ID 4740, the source of which comes from the user's PC.
After a lengthy analysis, it turned out that all three affected users were using Windows 11 24H2 Pro, an installed Outlook client (Office 365 desktop suite) and an Exchange account.
Is Outlook involved?
The administrator concerned then ran a more detailed test and re-enabled the blocked AD account for the user. At the same time, the user was prohibited from using Microsoft Outlook during the test period.
No AD account lockout occurred for several hours. As soon as the user reopens Outlook on their PC, the block reappears in less than 2 minutes.
Further user observations, no solution
In the above mentioned Spiceworks community thread, the thread starter describes everything he tested and didn't find the root cause. In the meantime, the thread starter has clearly confirmed that it is probably only related to Windows 11 24H2. A user who was previously running Windows 11 23H2 without any problems updated to 24H2 despite warnings. Since then, the AD account of the client in question (on which Outlook and an Exchange account are also configured) has been locked.
An explanation and some solutions
I wrote in the German edition of this blog post the other day, the only way to solve the problem was to roll back to Windows 11 23H2, as the AD account lockout has not yet been observed there.
But after I asked my German blog readers, if anyone is affected, I got several confirmations (also from German reader Nicolai, who also posted in the Spiceworks community). Nicolai wrote (I've translated his text):
I was one of the people who posted in the Spiceworks thread, the one who "found" the alternate login version by accident when I checked with a technician from the service provider who runs our Exchange. I had 3 accounts that had worked their way up to the "10 times wrong password" lockout in just a few minutes.
So I can confirm the problem in the context of 24H2 with Exchange running in a different domain.
After changing the domain entry for the user data, the problem no longer occurred for any of the 3 users, although frankly I have no idea why that should have made a significant difference.
And I got an answer with an explanation from German reader Rick, who wrote the following (I've translated the German text):
I can also confirm this. The classic case is when you use Hosted Exchange and the user name of the Active Directory is the same as the first part of the e-mail address (i.e. before the @), then Outlook (!) tries to login to the domain controller with the first part of the e-mail address + the saved Exchange password in the Active Directory. This fails, of course, and at some point the AD user is blocked, because a lockout is set in AD after x failed login attempts.
Rick proposed the following steps for a workaround:
1) Disable AD lockout for users
2) Use a different user name in AD for the affected users
Hope that helps affected people to solve this issue. Currently there is a further discussion in my German blog post, dealing with the circumstances of the issue (deepl.com could help to translate the comments).
