The following advice does not help you to 'purge or empty Windows Explorer’s network username and sharename cache' (as you asked). But it will allow you to connect to (essentially) the same share or the same server using a different username.
The trick is to use the IP address of the remote server.
(Also,
if it's Samba on the remote side,
- you could setup smb.conf to contain
netbios aliases = firstname, secondname, thirdname and you'll have even more options
if it's a Windows AD member server on the remote side,
- you could create a different 'Domain Name Alias' for your server,
and you'll have even more options. In all these situations, the connecting client will behave as if it connected to a different server.)
The NTLM authentication fallback is a symptom. The real problem is why is Kerberos failing.
This sounds like a classic case of the impersonation level that is obtained is insufficient to perform the requested activity. Using delegation with Kerberos, if the machine or process that is impersonating does not have an "Impersonation" token, but instead a lower token such as "Identity", requesting Kerberos authentication to access resources on using another identity will fail.
There are four types of impersonation tokens:
Anonymous
Identity
Impersonation
Delegation
"Impersonation" allows impersonation to access resources on the same machine where the process performing the impersonation is located. In cases where the process performing the impersonation is accessing resources on a different computer than where the impersonation is being performed, a "Delegation" token is required. This typically requires the TCB privilege (Act as part of the operating system).
TokenImpersonationLevel Enumeration
http://msdn.microsoft.com/en-us/library/system.security.principal.tokenimpersonationlevel%28v=vs.80%29.aspx
Note that DCOM in Windows XP/Server 2003 the Default Impersonation Level is "Identity". This means the process may not be able access resources while impersonating another identity. You may want to experiment with the machine-wide or process level security configuration to find what works. You may find that you need to enable encryption to connect to some resources. Configuring one service the same as the other may not be an apples - apples comparison.
Connecting Between Different Operating Systems
http://msdn.microsoft.com/en-us/library/aa389284%28v=vs.85%29.aspx
Setting System-Wide Security Using DCOMCNFG
http://msdn.microsoft.com/en-us/library/ms680051%28v=vs.85%29.aspx
Setting the Default Process Security Level Using C++
http://msdn.microsoft.com/en-us/library/aa393617%28v=vs.85%29.aspx
Best Answer
Let's get started:
"By Design"... or more specifically, "pass-through authentication".
Because this is what it's designed to do. When Windows attempts to access a network resource, and the resource requires authentication, it sends through its current username and password. The receiving computer then authenticates this and returns success or failure. (This is really, really simplified, it doesn't actually broadcast your password but I'm going to KISS).
Honestly, this isn't what you want. Mainly because the user will just then type their username and password into the credentials box, and then get the same access they would have had previously. Instead, you should be applying security on the shares/resources to ensure that only the people you want to have access have access.