Windows 11 24H2 Smartcard and Accessing File Share Issues with EventID 40960

EventID 40960 LSA (LsaSrv)

The Security System detected an authentication error for the server cifs/DomainController. The failure code from authentication protocol NTLM was "The authentication failed since NTLM was blocked (0xc00004189)".

After upgrading a domain client from Windows 11 23H2 to 24H2, I encountered an issue logging in with a smartcard. The login itself completes successfully, but once you're in, none of the domain mapped file shares are accessible. Instead, you're repeatedly prompted for the smartcard PIN, and authentication continues to fail.

Interestingly, logging in with a regular username and password works without any problems—domain shares connect as expected and everything functions normally.

The error recorded in the Security event log points to a failure in CIFS (SMB) authentication, specifically due to NTLM being blocked or unavailable.

EventID 40960 LSA (LsaSrv)

The Security System detected an authentication error for the server cifs/DomainController. The failure code from authentication protocol NTLM was "The authentication failed since NTLM was blocked (0xc00004189)".

The environment is a Windows Server 2019 domain where NTLM is still permitted as a fullback when Kerberos fails. The clients and servers are a mix of Windows 11, Server 2019, and Server 2022. Users currently have the option to log in using either their YubiKey smartcards or traditional passwords. However, the plan is to transition fully to smartcard PIN-based logins—eliminating password-based authentication entirely within the next month.

After a little research aka Google, and coming up empty, I didn’t find a definitive answer—but I did come across a few mentions that pointed toward the Security Option “Network security: Configure encryption types allowed for Kerberos.” I checked the setting, and sure enough, it was already configured globally to allow AES128_HMAC and AES256_HMAC_SHA1, so that didn’t appear to be the root cause.

I’d love to say the fix was the result of some deep technical insight or a brilliant deduction, connecting all the dots.

This was a shot-in-the-dark, coffee-fueled “I’ve seen enough weird Windows behavior to get a sense of déjà vu”. No documentation. No forum thread or Google results.

And I hadn’t planned on doing anything more complex than turning on the Xbox and zoning out for a bit. I definitely wasn’t in the mood to wade through GPO settings or start faffing with klist and whatever other diagnostics I'd normally drag out for this kind of thing.

So instead, I just opened up my user account settings, ticked the two checkboxes for “Kerberos AES encryption,” sighed, and hit OK—fully expecting nothing.

And naturally… it worked. I logged with a smartcard and pin all the mapped network drives were present and accessible, then repeated the exercise with other accounts that had failed. The system was back and behaving itself.

I really ought to thank Microsoft for their newfound consistency—consistently giving me fresh new material to blog about. It’s almost heartwarming, really. Takes me right back to the glory days of Windows NT 4, when every new Service Pack was less of an update and more of a creative new way to keep me gainfully employed.