leninkster

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.