Context: I map a cifs share in windows using NTLMv2 authentication, as the legacy server doesn't support kerberos. I am not prompted for login:

net use S: \\server.domain.com\share /persistent:yes
The command completed successfully.

This is fine until I change my password. Windows seems to continue to attempt to connect with the old credentials, even after logging off and back on or restarting multiple times. The only thing I've discovered works is using a different host name for the connection:

:: After changing password, restarting, and logging in with updated password
net use S: \\server.domain.com\share /persistent:yes
Enter the user name for 'server.domain.com'
:: running credentials failed, 'access denied' message logged on server

:: Manually entering credentials works:
net use S: \\server.domain.com\share /persistent:yes
Enter the user name for 'server.domain.com': DomainUser
Enter the password for 'DomainUser' to connect to 'server.domain.com':
The command completed successfully.

:: Using a different host name works
net use S: \\\share /persistent:yes
The command completed successfully.

The issue eventually "goes away," but I assume the NTLM token/session/key for that device just expires at some point, and windows is forced to create a new one. Or maybe there's another explanation for this? I looked at the following already:

  • Everything I found about NTLMv2 says nothing should stick around after a reboot
  • SMB allows for caching files, but I haven't found a way to clear it without disabling it in the registry
  • I double-checked for kerberos tokens with klist and for anything in Credential Manager
  • net only saves credentials if you specify /SaveCred, and would be removed with /delete anyways.

I want to understand what function could be causing this behavior, or narrow it down to some sort of bug. Any ideas?

Edit: After some fiddling with wireshark, I've identified that it's held together by strings:

  • the server is advertising that it supports kerberos (though under normal circumstances kerberos tickets are not created).
  • The client actually attempts to get a kerberos ticket, but fails due to not supporting the encryption type. It falls back to ntlm and that works...
  • For some reason I haven't figured out yet, attempting to connect with expired credentials causes the client to start succeeding at getting kerberos tokens, which is not correct.
  • The server cannot authenticate the user with the token, so it denies access.

3 Answers 3


The credentials are probably stored in the Credentials Manager, delete the old credentials and Windows will ask the password again (or edit the credential and provide the new password in the Credential Manager directly).

  • My Windows Credentials list inside Credential Manager is unfortunately entirely empty, though that makes it easy to rule out.
    – Cpt.Whale
    Commented Mar 25, 2021 at 22:05

Running net use * /delete in Powershell saved me in a similar situation. I had previously tried other commands to no avail.

  • This does not work for me either - I do have other drives mapped, but clearing everything this way doesn't seem to have improved things.
    – Cpt.Whale
    Commented Mar 26, 2021 at 13:15

I had a similar problem and forced windows 10 to forget the cached password by using a username that doesn't exist. Here's some pseudocode for a server called server.local. Many of the steps might not be needed depending on your situation:

  1. clear explicit cached credentials:
    cmdkey /delete:server.local
  2. delete all net connections:
    net use /d \server.local
  3. Check there's no more connections:
    net use
  4. Force windows to connect with invalid username and CTRL-C when it gets stuck:
    net use \server.local\share /user:garbageuser
  5. Connect using the correct user again.
    cmdkey /add:server.local /pass /user:correctuser
    net use \server.local\share
  6. Now Windows File Explorer will be able to connect again.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .