UPDATE: Microsoft released cumulative update 3097617, available here, which includes a potential fix for this issue. The updated file has the following properties:
I’ve installed the update now and have removed the “Do not require Kerberos pre-authentication” checkbox on my user object in ADUC, and will report back to validate whether this has resolved the issue for me.
UPDATE 2: This has definitely resolved my issue. No account lockouts, no corrupt machine credentials, no prompts in IE against Sharepoint sites, etc. Looks like this is actually resolved now!
So, I’ve been running Windows 10 since the Tech Previews, all through the Insider Builds up to “RTM” build 10240. Starting at build 10162, my domain user account started getting randomly and sporadically locked out from the domain without me having mistyped the password — in 99% of cases, the account would get locked out at a period of time where I wasn’t even at the machine, and it was sitting locked. Additionally, most times I unlocked my machine I would be prompted that “Windows needs your current credentials, please lock this workstation and unlock using your most recent password or smart card.” If I didn’t lock and unlock my workstation quickly, my account would almost guaranteed be locked out.
After a LOT of troubleshooting — Account Lockout tools from MS, NetLogon debugging, and the Netwrix Account Lockout Examiner (really nice tool if you’ve never used it), I still ended up coming up mostly blank. The best info I could glean was that SVCHOST.EXE (LocalSystemNetworkRestricted) was the process that was continually locking my account, and that it was executing from my Windows 10 laptop.
To troubleshoot, I did all of the basic things:
- Clear all credentials in the credential manager
- Completely rebuild Outlook/MAPI profile
- Completely rebuild User Profile
- Dis-join and re-join my computer to the domain
- Nuke machine from orbit and re-image without USMT
- Validate that I did not have any incorrect logon hours configured on my user account
- Validate that my user account was not configured to require DES Kerberos authentication
None of that helped at all, at which point I started enabling the deeper debug logging for Netlogon, ensuring our DCs were auditing failed password attempts, and then spent some time capturing data. Even with all that, I still was not able to uncover the root cause.
More digging on forums after my latest troubleshooting foray and I found the three following forum links that show identical issues to mine, with several proposed workarounds:
With some help from those forum posts, I did more digging on my DCs and did uncover Event ID 4771 being thrown from time to time, with the following specifics:
Kerberos pre-authentication failed. Account Information: Security ID: -USERNAME REMOVED- Account Name: -USERNAME REMOVED- Service Information: Service Name: krbtgt/-DOMAIN REMOVED- Network Information: Client Address: ::ffff:-IP REMOVED- Client Port: 51865 Additional Information: Ticket Options: 0x40810010 Failure Code: 0x18 Pre-Authentication Type: 2 Certificate Information: Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint: Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options and failure codes are defined in RFC 4120. If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.
This event occurred and corresponded both in time/date to when my user account got locked out, and also in quantity of bad password requests. For example, this does not 100% of the time lock my account out. Sometimes, I’m just prompted to re-enter my credentials, at which point I can check and see that there are x number of bad passwords logged against the DC.
In the example above, I saw 7 bad passwords logged against the DC, and also 7 instances of the 4771 Event ID (all done in less than a second), which corresponded directly to the last bad password time. Doing some more digging in the forum posts uncovered the following site which has deep information about the failure codes generated by Kerberos:
As you can see, the failure code indicated by my 4771 is that the “Pre-authentication information is invalid”. In general, this is logged when someone puts in a bad password. In this case, however, this is being logged by my computer autonomously as it attempts Kerberos authentication when I am unlocking the workstation.
The present workaround for this (which is mildly insecure, so I hope Microsoft resolves this issue soon …) is to place a check in the checkbox on the affected user account removing the requirement for Kerberos pre-authentication. The exact text of the box to check is “Do not require Kerberos preauthentication”.
Once I enabled that on my account, the account lockouts have subsided (so far, anyways … but the verdict is still out I suppose), but in doing so I have sacrificed a small amount of security, as Kerberos preauthentication is an important security function provided.
In any case, because it took so long to trail this down and because there were so few people posting about it, I figured I’d document as thoroughly as I could at present and get it posted in hopes of helping anyone else having the same issues.