Windows 11 In-Place Upgrade Causes Domain Account Lockouts (Account Lockout Policy) on Some PCs in Corporate Domain Environment

Question

Windows 11 In-Place Upgrade Causes Domain Account Lockouts (Account Lockout Policy) on Some PCs in Corporate Domain Environment

Tam Tran Nhut 30

Hello everyone,

I would like to ask for support regarding an issue that occurred during a Windows 10 to Windows 11 in-place upgrade in a corporate Active Directory domain environment.

We performed a pilot upgrade (one PC per department) on a total of 7 domain-joined PCs:

3 PCs upgraded successfully without any issues

4 PCs started causing frequent domain user account lockouts after upgrading to Windows 11 due to the Account Lockout Policy

Environment Details

All PCs are joined to the company Active Directory domain

Upgrade method: In-place upgrade from Windows 10 Pro to Windows 11

Upgrade was performed while users were logged in with domain user accounts

PCs were upgraded individually on different days (not in bulk)

Problematic PCs appeared randomly and are not related to upgrade order

Issue Description

After upgrading to Windows 11, affected PCs continuously trigger domain account lockouts.

From the Domain Controller Security Event Log (Event ID 4740):

The source computer name always matches the upgraded Windows 11 PCs

Based on log analysis, the lockout attempts appear to be generated by the SYSTEM context, not by users manually entering incorrect passwords

Troubleshooting Already Performed

On the affected PCs, I have tried the following steps:

Checked and cleaned Task Scheduler

Cleared all saved credentials in Credential Manager

Purged Kerberos tickets using klist purge

Deleted user SID profile registry entries

Backed up and removed the user profile folder, then re-created the profile by re-login

Ran system integrity and repair commands:

DISM /Online /Cleanup-Image /RestoreHealth

  `sfc /scannow`
  
  Un-joined and re-joined the PCs to the domain

Unfortunately, none of these actions resolved the issue.

Business Impact

Currently, the only remaining workaround seems to be performing a full Windows OS reset or clean installation on affected PCs.

However, in our production environment we have more than 150 domain-joined PCs, and performing clean installations on all machines would be extremely time-consuming, operationally difficult, and disruptive to daily business activities.

Therefore, we are looking for a proper root-cause solution or Microsoft-supported fix instead of a full OS redeployment.

Questions

Has anyone encountered a similar situation where a Windows 11 in-place upgrade causes domain account lockouts?

Could this issue be related to cached credentials, Windows Hello for Business, Credential Guard, TPM, LSA Protection, or other Windows 11 security architecture changes?

Are there any known Windows 11 upgrade bugs, hotfixes, registry fixes, or diagnostic tools recommended by Microsoft for this scenario?

Any guidance, best practices, or troubleshooting suggestions would be greatly appreciated.

Thank you very much

John Bellendir 0 Reputation points

2026-01-28T17:30:51.0666667+00:00

We have the exact issue on a few customer machines. We are an MSP with ~ 30 customers. We have performed in place upgrades on ~ 200 computers across all customers. This issue has only popped up on a handful of computers that we've upgraded and only 3 of the customers have machines affected. We have not found a solution other than performing a clean installation on the affected machine. We've tried all of the troubleshooting steps you've mentioned.

To add to troubleshooting, we've made sure the machine or users weren't being affected by any group policies at all and that didn't help. We've un-joined the machines from the domain, deleted the computer object and rejoined the machine, that didn't help. Users that are affected can log into other domain computers without issue but when they try to login on the affected machines, they are locked out after the first successful (they are typing the correct password) login attempt and event ID 4740 is logged on the DC. The user will then wait some time and then try again and the computer and the login attempt will succeed. The user account locks on one of the affected machines if the user locks the computer after a successfully login and attempts to unlock it.
Morgan Kay 0 Reputation points

2026-02-10T13:45:12.12+00:00

This sounds very similar to something that my org has been seeing as well. However, our devices are NOT AD joined - they are azure AD joined. No computer objects in AD, and they are managed with intune. We sync AD users to entra. We started seeing this pop up within weeks of deploying windows 11 devices.

Our users commonly see this after unlocking the device from sleep. No password changes recently, no cached credentials in cred man. Scheduled tasks have been ruled out because when a task fails with a stale user credential, it logs a 4625 to the client. In all of these cases, there is not a single 4625 bad logon event, client or DC side.

One thing we have noticed is that after successful login to the PC, within about 30 seconds (on average), the device sends 5+ bad kerberos pre-auths (event ID 4771 subcode 0x18) in less than one second - this locks the account per our policy. The device throws that windows needs the user to lock and sign in with the current credential. If the users follow the prompt and something unlocks the account (admin or user via self service), they are fine, and then they might never have the issue again. Is this similar to what you've been seeing log pattern wise?
John Bellendir 0 Reputation points

2026-03-26T14:19:48.71+00:00

OK, I have an update from our end. I've installed Windows 11 Pro fresh on new SSD's for all 4 "affected" machines at one client location. I even named them something different than the previous computer name. The same users still get locked out. I'm really at a loss as to why a windows 11 upgrade on one computer would cause a domain user account to lock with ID 4740 even if they enter the correct password. It's as if the actual Domain account is affected somehow. The next step is to create new domain accounts (with different account names) for these users I guess. Once I get around to doing that I'll post the result. Edit!

scratch the above test for now..

So for some reason I didn't realize a bunch of articles with a similar problem was relevant. At one of my client locations, they have a Domain. They also have hosted exchange email (not o365 though although I'm not sure that matters). The email name is the same as the AD login name for the 3 users where the accounts lockout. Well, all those articles describe a scenario where if the machine has 24H2 or 25H2 installed and the cred manager has the hosted exchange creds stored where the email name is the same as the AD user's account name, The stored cred for Exchange in the cred manager will lock the AD account when they launch outlook because the passwords are different. I guess the problem is that Windows 11 is ignoring the domain in this scenario. Meaning the domain for the email address is different than the AD domain but it's ignoring that part when authenticating. Anyway, I'm testing with the 3 users I mentioned. I changed their AD account names. So now it shouldn't lock out the accounts because the AD user name and the email name are different. Let's see if it works!

1 answer

Your answer

John Bellendir 0 Reputation points

2026-01-28T17:30:51.0666667+00:00

We have the exact issue on a few customer machines. We are an MSP with ~ 30 customers. We have performed in place upgrades on ~ 200 computers across all customers. This issue has only popped up on a handful of computers that we've upgraded and only 3 of the customers have machines affected. We have not found a solution other than performing a clean installation on the affected machine. We've tried all of the troubleshooting steps you've mentioned.

To add to troubleshooting, we've made sure the machine or users weren't being affected by any group policies at all and that didn't help. We've un-joined the machines from the domain, deleted the computer object and rejoined the machine, that didn't help. Users that are affected can log into other domain computers without issue but when they try to login on the affected machines, they are locked out after the first successful (they are typing the correct password) login attempt and event ID 4740 is logged on the DC. The user will then wait some time and then try again and the computer and the login attempt will succeed. The user account locks on one of the affected machines if the user locks the computer after a successfully login and attempts to unlock it.
Morgan Kay 0 Reputation points

2026-02-10T13:45:12.12+00:00

This sounds very similar to something that my org has been seeing as well. However, our devices are NOT AD joined - they are azure AD joined. No computer objects in AD, and they are managed with intune. We sync AD users to entra. We started seeing this pop up within weeks of deploying windows 11 devices.

Our users commonly see this after unlocking the device from sleep. No password changes recently, no cached credentials in cred man. Scheduled tasks have been ruled out because when a task fails with a stale user credential, it logs a 4625 to the client. In all of these cases, there is not a single 4625 bad logon event, client or DC side.

One thing we have noticed is that after successful login to the PC, within about 30 seconds (on average), the device sends 5+ bad kerberos pre-auths (event ID 4771 subcode 0x18) in less than one second - this locks the account per our policy. The device throws that windows needs the user to lock and sign in with the current credential. If the users follow the prompt and something unlocks the account (admin or user via self service), they are fine, and then they might never have the issue again. Is this similar to what you've been seeing log pattern wise?
John Bellendir 0 Reputation points

2026-03-26T14:19:48.71+00:00

OK, I have an update from our end. I've installed Windows 11 Pro fresh on new SSD's for all 4 "affected" machines at one client location. I even named them something different than the previous computer name. The same users still get locked out. I'm really at a loss as to why a windows 11 upgrade on one computer would cause a domain user account to lock with ID 4740 even if they enter the correct password. It's as if the actual Domain account is affected somehow. The next step is to create new domain accounts (with different account names) for these users I guess. Once I get around to doing that I'll post the result. Edit!

scratch the above test for now..

So for some reason I didn't realize a bunch of articles with a similar problem was relevant. At one of my client locations, they have a Domain. They also have hosted exchange email (not o365 though although I'm not sure that matters). The email name is the same as the AD login name for the 3 users where the accounts lockout. Well, all those articles describe a scenario where if the machine has 24H2 or 25H2 installed and the cred manager has the hosted exchange creds stored where the email name is the same as the AD user's account name, The stored cred for Exchange in the cred manager will lock the AD account when they launch outlook because the passwords are different. I guess the problem is that Windows 11 is ignoring the domain in this scenario. Meaning the domain for the email address is different than the AD domain but it's ignoring that part when authenticating. Anyway, I'm testing with the 3 users I mentioned. I changed their AD account names. So now it shouldn't lock out the accounts because the AD user name and the email name are different. Let's see if it works!

Answer 1

The issue you're experiencing with domain account lockouts after upgrading to Windows 11 could be related to several factors, particularly concerning how Windows 11 handles credentials and security policies. Here are some considerations and troubleshooting steps based on your description:

Account Lockout Policy: Windows 11 may be triggering account lockouts due to the way it handles cached credentials or other security features. The default account lockout threshold in a managed domain is typically set to lock accounts after a certain number of failed login attempts (e.g., 5 bad password attempts within 2 minutes). This is designed to protect against brute-force attacks.
Cached Credentials: If the upgraded PCs are using old or cached credentials that are no longer valid, this could lead to repeated lockout attempts. It's good that you've cleared saved credentials in the Credential Manager, but ensure that no applications are trying to authenticate using outdated credentials.
Windows Hello for Business and Credential Guard: These features could also be influencing the behavior of account logins. If any of the PCs were using Windows Hello or Credential Guard prior to the upgrade, ensure that these settings are properly configured post-upgrade.
Event Log Analysis: Since you've noted that the lockout attempts are generated by the SYSTEM context, it may be beneficial to further analyze the security event logs for any specific applications or services that may be attempting to authenticate using the domain account. Look for patterns or specific services that might be causing the lockouts.
Network and Security Configuration: Ensure that there are no changes in network security configurations or group policies that might affect how authentication is handled post-upgrade. Sometimes, security policies can inadvertently cause issues with account authentication.
Known Issues and Fixes: While there may not be a specific hotfix for this issue, keeping Windows 11 updated is crucial, as Microsoft frequently releases updates that address bugs and improve security features. Check for any updates or patches that might relate to account lockout issues.
Testing in a Controlled Environment: If possible, replicate the issue in a controlled environment to better understand the root cause. This could involve testing with different configurations or user accounts to see if the problem persists.

Given the complexity of the issue and the potential impact on your organization, it may also be beneficial to reach out to Microsoft support for further assistance, especially if this is affecting multiple machines in your domain.

References: