My co-worker experienced this exact problem when he moved to Vista and was connecting to his home VPN connection (a non-Microsoft VPN end-point, I believe it was a DDWRT-based router, but still using PPTP). After a random amount of time his mapped network drives would cease to authenticate. He had to disconnect, open the shares, then reconnect to the VPN to get the behavior to stop temporarily. He investigated it some and said that he found wide reports of problems but no solutions. He has since moved back to Windows XP (it was a deal breaker for him, it seems) and has not had the problem since. He noted that during his testing that the VPN username and password combination relative to his domain username and password combination had no bearing on the occurrence of the problem and suspected that it was, instead, from an inability of the system to actually determine which credentials the resource needed so it gave the most recent ones.
Have you tried adding the network shares using their FQDN (in hopes that the system would see that and then use credentials for that domain vs. the other)? ----- Sidebar for John Gwinner's DNS comments The workaround in http://support.microsoft.com/kb/311218 has resolved those issues on our Windows XP SP2 machines beautifully. Our users were having issues accessing internal resources by name while on the VPN. It was sporadic and inconsistent. It seemed to depend on the state of their DNS Cache and if the system had to look up the address it was using their router/modem's DNS servers instead of the ones provided by our network. With the ISP's now responding to DNS requests that don't actually have domains (ala the 'DNS Redirection Search Feature') it was never failing and thus never trying the secondary DNS servers. I've found that you need to reconnect to the VPN after you make the registry change and you may also have to clear your DNS cache. I have not had to reboot for this to take effect. So far it has been a one-time change and not (as I had feared) a per-connection change. From: Carl Houseman [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 4:30 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain The default DNS after connecting (the one that NSLOOKUP identifies) is a server on the client network's in the client's AD domain, which has a completely different set of authentication credentials - different from my local domain, and different from the VPN gateway. Just to re-cap... 1. I authenticate to my local domain first on logging into Windows. 2. Then I authenticate to the remote VPN gateway server via the VPN connection. 3. Then I authenticate to the remote Windows servers by supplying a 3rd set of credentials on the NET USE command line. If anything, I'd expect that the more recent credentials - from item (3) - would be attempted for re-authentication to my local domain. But no, it's the ones from the VPN connection (2), that get tried. So I'm highly doubtful of a DNS issue, but there's one scenario I haven't tried in attempt to prove it, and that would be to map a drive using the local server's IP address and see if that also goes away when the ones mapped by name go away. I will give that a try ASAP... Carl From: John Gwinner [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 3:57 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain Is it a default gateway issue? ISA 2004 can force you to use the default gateway on the remote side. Also, is it a DNS issue? When you connect to a VPN, even one that forces default gateway behavior, the DNS order might be wrong. Apparently it's a 50/50 issue which DNS server will reply first. I have this problem on my own side, my internal servers have 'corp.com' DNS settings that resolve to 192.168.x.x. numbers, but when you connect to the VPN, you get a 66.150.x.x number - outside the firewall, even though you are on the VPN. If this is the problem, maybe your DNS gets confused and your local DC suddenly gets reached via a public IP, which is blocked. I assume the subnets are separate, i.e. you aren't both using 192.168.0.X. == John == From: Carl Houseman [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 12:30 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain No, the usernames and passwords are different, and they must remain that way. Carl From: Steve Ens [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 2:35 PM To: NT System Admin Issues Subject: Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain You do have a local account on the remote server....same username and password I presume? On Wed, Dec 10, 2008 at 1:28 PM, Carl Houseman <[EMAIL PROTECTED]> wrote: This problem has bothered me a long time, and happens daily. It's so bothersome, I'll send some Dale & Thomas popcorn to the first person who can come up with a solution or a tip that quickly (without many hours of effort on my part) leads to a solution. Advice such as "call Microsoft" does not qualify for the popcorn! Past history: The problem was seen for Windows XP but seems to be worse under Vista. In fact I wrote about it in reference to XP to this list a year or two ago without any resolution. Certainly what I'm doing here can't be that unique, aside from relying on Microsoft-based VPN solutions... (kindly withhold comments on the worthiness of those solutions). Goes like this: In my local office, there are two 2003 servers - member and domain controller. My everyday Vista SP1 is joined to that domain. I have drives mapped to both servers. I use an L2TP/IPSEC VPN connection to connect to a client's network. The client's VPN gateway is ISA 2006, joined to the client's Windows domain, but I authenticate for the purpose of the VPN connection using a local username on the ISA server. We'll call the ISA server "ISAVPN" in further discussion. What happens: Sooner or later I will be unable to access the drives mapped to my local domain's servers (UNC references to those servers also fail). The error returned when just trying to do anything at the CMD prompt defaulted to a mapped drive on either server is: Logon failure: unknown user name or bad password. Once I disconnect from ISAVPN, at the very same CMD prompt, I again and immediately have access to files on my local servers. This seems to affect access to the member server a short time after connecting to ISAVPN. Access to files on the domain controller usually keeps working much longer, but eventually I lose it as well. This behavior has guaranteed repeatability 100% of the time. I should note that the domain controller's mapped drive is "available offline" but Vista does not switch to offline because of this problem. Looking in the security event log of the server, I see events 529 and 680 (source Security), in pairs, related to the login failure, with the 529 having the most information: Logon Failure: Reason: Unknown user name or bad password User Name: local_username_on_ISAVPN Domain: ISAVPN Logon Type: 3 Logon Process: NtLmSsp Authentication Package: NTLM Workstation Name: MYVISTAPC My take on it: At some point, SMB access has to re-authenticate and is using the more recent credentials from the VPN connection to talk to my local servers. I'm guessing binding order somewhere is the problem, but where can I find and fix this binding order? A permanent one-time solution would be nice, but it's OK if I have to fix it every time after making the VPN connection. thanks all, Carl ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
