This is more of a curiosity then a real problem, I am just to lazy to reboot or log off my laptop.

I have connected to a network share on a Windows server with domain credentials from a non-domain Windows 7 machine, I didn't mark the option to remember the password.

The share is let's say \\\folder.

I have changed the password for that domain account in the meantime, and now when I try to access that share I get the following error:

Logon failure: unknown user name or bad password

I have tried the following on the client side:

  • deleting cached credentials in Credential Manager
  • running net use delete
  • running net session \\ip.of.the.server /delete gives me "A session does not exist with that computer name."
  • running net use \\\folder /u:DOMAIN\USER password gives me "The command completed successfully.", but I still get the same unknown user name or bad password when trying to access the share from Windows Explorer
  • mapping the share as a network drive from GUI, but then I get

    The network folder specified is currently mapped using a different user name and password.
    To connect using a different user name and password, first disconnect any existing mappings to this network share.

  • running net use to see connections, I get that there are no connections in the list
  • killing explorer.exe and starting it again.

I have tried the following on the server side:

  • going to Computer Management > Shared folders > Sessions to kill the session with my username
  • rebooting the server

I have managed to access the share using the domain name instead of the IP address, but I am curios.

Does anybody know any way how to delete the cached credentials in this case? Where are credentials cached when you don't mark the remember password option when accessing the share, they are not shown in Credential Manager and there is no mapping shown when you run net use.

  • 1
    You'd need to kill the session at the server side through computer management on the server itself unless I'm missing something in your question. – TheCleaner Nov 22 '12 at 23:14
  • 1
    The question is how to do this on a client side on the Win7 machine, when you don't have privileges on server to kill a session. I'm curios where are the credentials cached on a client side in this case – rAlen Nov 22 '12 at 23:17
  • You've done what can be done from the client side. The only thing remaining is the cached session on the server side. If you don't have privileges on the server, then the question belongs on superuser.com and not SF. Short of rebooting, which you already specified. – TheCleaner Nov 23 '12 at 4:26
  • 1
    I played a little with server side over the night, server side doesn't play any role in this caching, i tried going to sessions in computer management and even rebooting the server, like i side not really a problem more a curiosity, it seem that in cases like this you either have to switch from ip to domain name or vice versa, or rebooting or logging of the computer – rAlen Nov 23 '12 at 8:59
  • If you've done "net use" by itself and nothing is in the list and you've done everything else mentioned I don't know why it would still persist...sorry. – TheCleaner Nov 23 '12 at 17:19

To delete all network authentication

C:\> net use * /d

To view current network connection

C:\> net use 


I tested in Windows 7 SP1 64 Bits, 100% WORK

After run the command, you need to go to task manager delete the explorer.exe , then reopen the application again.

To open the application, go to RUN, enter explorer.exe

Now you are fully clear the connection information in the session.

  • 5
    This is likely to fix the asker's issue. However note that you are not deleting "cached credentials" but connection information in your session - you should update your answer to reduce possible confusion. Killing explorer.exe is rather necessary on newer Windows clients as it seems to hold connections / sessions to the server without them appearing in the "net use" list. – the-wabbit Mar 27 '13 at 10:05
  • Thank for the correction. Yes, Windows 7 got this issue hold the connections / sessions. However, it also will auto remove it, but I am not sure the duration. The best way is just kill the explorer. Fast and easy. – Shiro Mar 29 '13 at 8:47
  • 1
    +1 for the tip about re-starting explorer.exe – Babblo Mar 5 '15 at 5:41
  • 3
    "IMPORTANT NOTE" part is the answer. – elsadek Jan 11 '16 at 6:29
  • 1
    @Shiro, sure! What I meant by "remembers password" is that it still allows me to visit the share without asking the password again. I am fully aware of the Credentials Manager. Meanwhile I also learned, that instead of restarting explorer.exe in my case I had to wait for 2 minutes for windows to forget the login information. – Johu Jun 6 '18 at 9:14

I know this is old, but in case anyone reads this in the future....

The next time this occurs I have found the best way to get rid of the credentials is to open an elevated command prompt and type in:

net use \\server\share /delete

then type in:

klist purge

I tried it with both command individually and they do not work alone. You have to first remove the connection if it exists. Then remove the Kerberos authentication ticket from the machine. I had an incident like yours where the connection no longer existed but the Kerberos ticket had not expired yet, so when I went back in and had not logged off of the machine it would use my previously entered credentials. By purging the ticket it prompted for credentials again.

  • 3
    This! This should be the accepted answer. No rebooting or kludging around with killing processes in the task manager. Simple and effective. – dhj Jul 8 '15 at 16:24
  • 1
    I agree -- the Kerberos purge is an effective punch. Just be aware that it's a sledgehammer, i.e. you're killing all of your client's Kerb tickets, not just for that one particular server/share! – NateJ May 10 '16 at 16:33
  • You can probably add also /y switch to skip answering the [Y/N] question. – prot Nov 30 '16 at 7:09
  • The combination of these two commands still does not work on Windows 8.1. – Johu Jun 5 '18 at 15:33
  • 1
    Meanwhile I also learned, that instead of restarting klist purge in my case I had to wait for 2 minutes for windows to forget the login information. I wish there was an instant method. – Johu Jun 6 '18 at 9:15

Go to the control panel -> User accounts -> click on your name -> to the left click on "credentials" (or manage your credentials). All the used network credentials will be there.

  • I have said in the question that I tried using the Credential Manager, I didn't use the remeber password option, and it seems that in this case the credentials are not there – rAlen Nov 22 '12 at 23:20
  • did you try using the net use with the password on the command line also ? I know this is not secure but it might overwrite the caches password. I'm not on a windows machine right now so I can't test – Goez Nov 22 '12 at 23:22
  • yes i tried net use \\share /u:domain\user and it would always gave me an error, the windows obviously sees the share as mapped but it is not showing it when i run net use, i get that there are no connections in list (see also the error i gui in the question) – rAlen Nov 22 '12 at 23:24
  • 1
    Yes i tried net use \\share /u:domain\user password, I get the command completed successfully, i got error before because i made a mistake in my share name, nevertheless even after i get the completed successfully I still get unkown user or bad password when i try to access the share by IP from windows explorer. net session gives me that there is no session with that computer name – rAlen Nov 22 '12 at 23:35
  • 1
    This is the only thing that worked for me. – Robert Noack Sep 1 '17 at 17:59

The following should do what you want.

C:\> net use \\server\share /d
C:\> net use \\server\ipc$ /d
  • 2
    Thank you! Nowhere in the GUI did Windows 8 make this apparent. Restarting the lanmanworkstation and others in services.msc helped nothing, as neither did restarting smbd, mucking with smbpasswd, etc. on the Linux Samba server. – Marcos May 30 '14 at 15:12
  • 1
    Note that smbstatus on a Linux box will let you see which PIDs go with which users, and you can kill those specifically to disconnect them. – mikebabcock Jun 18 '14 at 18:44

I have managed to access the share using the domain name instead of the IP, but I am curios.

This is a sign of bad client side cache and usually relates with netbios.

Try to restart the below list of services and if need, kill explorer, start the task manager and start it again via the task manager file->run entry, as explorer may also be caching things from those services.

I don't know exactly what is the failing service on your side, so you can try this this list, one at time to see if it works:

-TCP/IP NetBIOS Helper (can even be off if you add your machines to the DNS/host file)
-Workstation    <---   TRY THIS ONE FIRST
-computer browse
-net logon
-rpc service

if it works, report back what was the service, so others can try it directly

good luck

  • 3
    +1 Restarting the Workstation service was enough to resolve it for me. – Drew Chapin Sep 23 '13 at 18:13
  • 2
    restarting is a stupid solution. – Talespin_Kit Mar 28 '14 at 14:24
  • 3
    @Talespin_Kit I agree that it is stupid, but welcome to windows! If you have a better option to clean windows client cache, feel free to post it here. :) – higuita Mar 31 '14 at 17:34
  • Thanks, @druciferre. Workstation restart worked for me on a Windows Server 2012 R2 (i.e., Windows 8.1) install. The NET USE command (my old standby) of course did not. – Jason Dec 11 '14 at 15:37

Let's say your server name is BIGSERVER and your user account is bigjim. You already logged in once so you'll need to delete the cached credentials.

These are found in :

[Windows 8] Windows key > Control panel > User accounts > Manage your credentials > Windows credentials > Remove server credentials.

Now restart explorer.exe

Access your server from windows explorer using \BIGSERVER\bigjim

As user, use BIGSERVER\bigjim (remember to use capital letters)

Not the answer you're looking for? Browse other questions tagged or ask your own question.