Purge cached credentials used to access a Samba server

[Ignatius]

I have configured an Ubuntu Server with Samba in a workgroup. When I opened Computer on a Windows 7 Pro client, I saw the Ubuntu server listed under "Network". I accessed the Ubuntu share by typing \\UbuntuServer\share in the location bar and it asked me for the user credentials on the Ubuntu server as it should. I connected successfully. I did not create a mapped drive via "net use ..." etc.

 

I closed the share then opened Computer again and the Ubuntu server and it's share were visible. The server and share details were cached, along with the username and password. How do I remove them from the Windows 7 client? I've tried:

 

1. Credential Manager in Control Panel, but nothing was listed there

2. run rundll32.exe keymgr.dll, KRShowKeyMgr showed nothing stored

3. net use * /delete returned "There are no entries in the list" (I know I didn't map a drive but some sites suggested trying this)

4. net session returned "There are no entries in the list"

5. I've disabled Network Discovery then re-enabled it but the Ubuntu server and it's shared folder popped up again

 

Surely this is a security flaw? If I go to someone's PC and access the share by entering my credentials, there must be a way of purging them, otherwise the user would be able to access everything in the share to which I had access from their PC.

[leninkster]

I have configured an Ubuntu Server with Samba in a workgroup. When I opened Computer on a Windows 7 Pro client, I saw the Ubuntu server listed under "Network". I accessed the Ubuntu share by typing \\UbuntuServer\share in the location bar and it asked me for the user credentials on the Ubuntu server as it should. I connected successfully. I did not create a mapped drive via "net use ..." etc.

 

I closed the share then opened Computer again and the Ubuntu server and it's share were visible. The server and share details were cached, along with the username and password. How do I remove them from the Windows 7 client? I've tried:

 

1. Credential Manager in Control Panel, but nothing was listed there

2. run rundll32.exe keymgr.dll, KRShowKeyMgr showed nothing stored

3. net use * /delete returned "There are no entries in the list" (I know I didn't map a drive but some sites suggested trying this)

4. net session returned "There are no entries in the list"

5. I've disabled Network Discovery then re-enabled it but the Ubuntu server and it's shared folder popped up again

 

Surely this is a security flaw? If I go to someone's PC and access the share by entering my credentials, there must be a way of purging them, otherwise the user would be able to access everything in the share to which I had access from their PC.

 

I had a similar issue, where I have two Active Directory domains with an outbound trust From B-A. Logging onto domain A allows automatic authentication into B, but not the other way round. Creating a manual temporary share to access some resources on A seemed to be cached with no way of identifying where these credentials were cached, as per your investigation.

 

The "Cure" for me in this case (I could not logout/login or reboot the server because of production jobs) was to identify from the target server in domain "A" what credentials were holding the shares open. In Windows this is done with an MMC snap-in for shares. For Linux (SAMBA Server) you can use smbstatus.

 

Once you have got the credentials of the "offending" account you go back to the Windows server and from the control panel select "Stored User Names and Passwords". It will be empty, so create a stored username and password that matches the Account part of the credentials BUT AN INVALID PASSWORD AND DOMAIN. e.g. If the user account was JBLOGGS and the domain was DOM1 and password SECUREME then in the account and password boxes put DUFF\JBLOGGS.

 

This will error. It is important that this errors as this is what seems to clear the account part of the cache. The re-enter the Credetials with the correct Domain and account (i.e. DOM!\JBLOGGS) but an invalid password e.g. dfkjhsfdghldkf.

 

Then ensure all maps are disconnected to the target server/resource for the user from this server/resource and try to remap the resources on the server. You will be asked for a username and password. DO NOT ENTER THESE.

 

Cancel the remap, remove the stored credentials and the automatic credential store will have been cleared.

 

It's tortuous, but works every time, doesn't require a logout, reboot or registry edit.

 

The full fix is to put two GPOs in the Windows server that disables domain credentials caching, and force Domain Controller lookup for each authentication. This unfortunately does require a reboot.

Edited September 12, 2012 by leninkster
typo