It's just a console command in 2K3 & above so it should be easy to do. C:\Windows\System32\CMDKEY /delete /ras
Easy for me to say cuz I'm not doing it J Also came across a post from MS that said to use UseRasCredentials=0 in the .pbk file that contains the entry that you dial. From: Carl Houseman [mailto:[email protected]] Sent: Wednesday, December 17, 2008 10:53 AM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain Thanks Bob, hadn't run into that widget before. Now can I automatically run it from a post-VPN-connection script without going through all the CMAK nonsense? From: Free, Bob [mailto:[email protected]] Sent: Tuesday, December 16, 2008 3:50 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain > Anybody know of a way to script the removal of something from the saved passwords list? I haven't followed this whole thread but the answer to that particular question, cmdkey may be your friend here. It has a switch for deleting RAS credentials that I've seen mentioned being used for situations similar to yours. From: Carl Houseman [mailto:[email protected]] Sent: Monday, December 15, 2008 9:28 AM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain I'm starting to connect the dots here, I think. I noticed when I 'control userpasswords2' and click Advanced and Manage Passwords, while the VPN is connected, at the top of the saved passwords list is ... <Dialup Session> If I disconnect the VPN, <Dialup Session> disappears from this list. If I delete <Dialup Session> from the saved passwords list, the problem goes away (the VPN is still connected). Anybody know of a way to script the removal of something from the saved passwords list? Meanwhile, I haven't had a failure when drives are mapped to FQDNs. I'm still thinking that somewhere, Vista is bypassing the hosts file entry I made for my TLD and still uses DNS to resolve it (a security measure, hosts file not trustworthy, etc.). And then it thinks that the credentials for the connection that resolved the DNS should be used to re-authenticate. On that basis, I could script a change to the adapter order. Or just use the FQDN's for drive mapping I supposed. I don't like any of these solutions that much. The FQDN's are the least effort, but have a side effect - e.g. \\server <file:///\\server> is trusted to execute a .vbs script without prompting, but \\servername.mydomain.com <file:///\\servername.mydomain.com> always prompts. Even when servername.mydomain.com is added to Intranet or Trusted zones, it still prompts. Carl From: Carl Houseman [mailto:[email protected]] Sent: Saturday, December 13, 2008 12:24 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain Here's a new way I can see this problem... I don't know if this would have happened before the reboot, but I rebooted the DC in my local environment (it's the only DC). Following that, from the Vista machine I wanted to run something on the DC.... I typed psexec \\server <file:///\\server> command Response: Couldn't access server: Logon failure: unknown user name or bad password. Login failures on server showed the attempted use of the VPN credentials - by psexec (no other explanation for those events). Meanwhile, psexec \\server.mydomain.com <file:///\\server.mydomain.com> worked just fine. Still no problem pinging \\server <file:///\\server> , keeping in mind, my local AD TLD is in the DNS suffix search list. And still no problem with the drives mapped to FQDN's on the DC that rebooted. So it's a NETBIOS thing, maybe, except that I've seen drives that were mapped to \\ip.ad.dr.ess stop working with the same wrong-credentials login failure. Carl From: Carl Houseman [mailto:[email protected]] Sent: Wednesday, December 10, 2008 2:28 PM To: NT System Admin Issues Subject: Lose access to local domain servers when connected w/VPN to remote / different Windows domain 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/> ~
