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:r...@pge.com] 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:c.house...@gmail.com] 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:c.house...@gmail.com] 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:c.house...@gmail.com] 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
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
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:c.house...@gmail.com] 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:r...@pge.com] 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:c.house...@gmail.com] 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:c.house...@gmail.com] 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:c.house...@gmail.com] 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
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:c.house...@gmail.com] 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:c.house...@gmail.com] 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
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
No wins server in the local environment. Regarding Kerb lifetime of the remote, there are two remotes in play 1. The remote domain. But the remote domain is not authenticating my VPN session with the remote network. 2. The remote ISA server that is authenticating my VPN session. The problem is that VPN session credentials are being applied to my local servers. So from which platform exactly would you want to see klist information? The ISA server, the remote domain DC, or my local Vista? I've not installed Win2003 RK tools on my local Vista machine. I will say this, everything involving Kerberos is operating at Microsoft-installed defaults. I would not play with such things, and yes, I know the remote well enough to say they did not play with such things. The title of KB 180362 is services and redirected drives. It seems to care more about redirected drives and drive letters, but my problem is not specific to drive letter mappings - if a drive mapped to \\server\share file:///\\server\share is failing, a UNC reference to \\server\share file:///\\server\share is also failing. Meanwhile, I've been actively working with the VPN connected for the last 3 hours and haven't lost any drives mapped to FQDN's I know that any result of less than 24 hours experience is inconclusive, so I'm going to wait until at least Monday p.m. to declare success or failure. Carl From: Michael B. Smith [mailto:mich...@theessentialexchange.com] Sent: Friday, December 12, 2008 3:06 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain What does your wins look like? What's the Kerb lifetime of the remote and are they defaulting to UDP or TCP and what do your tickets look like? (kerbtray and klist are your friends) The title of this KB says services, and it's old (but still valid), but it's about any time you are changing security contexts: http://support.microsoft.com/kb/180362 Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: Carl Houseman [mailto:c.house...@gmail.com] Sent: Friday, December 12, 2008 2:45 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain Well crap. The problem just happened again. Sorry John, looks like you don't get the popcorn. pinging my local AD TLD is hitting the correct server. Big heavy sigh. What else could it be? I guess I'll go with mapping drives to FQDN's and see where that gets me. Carl From: Carl Houseman [mailto:c.house...@gmail.com] Sent: Friday, December 12, 2008 1:29 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain It looks like the problem is solved. I've been reviewing all the responses to see if anyone won the popcorn... :) John Gwinner's answer was the first to call DNS into question and he also described what ended up being the problem - the fact that my AD domain name was being resolved by the remote org's DNS to a public IP. If I'd not been so skeptical I could have solved the problem faster based on his answer. So John, if you want a bag of popcorn, send me your mailing address privately and choose one of these flavors (they're all good!): - Peanut butter and white chocolate - Chocolate chunk and caramel - Milk chocolate and white chocolate Again, thanks to everybody for their comments, and Happy Holidays to all. Carl From: Carl Houseman [mailto:c.house...@gmail.com] 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
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
OK, I don't speak DNS as well as you but I can report my results. I'll let you explain them however you like! My scenario: A local LAN adapter references one Windows AD DNS - TLD= a.com A PPP adapter referencing another Windows AD DNS - TLD= b.com When I start NSLookup, the PPP adapter's DNS is identified. So I know the PPP adapter's DNS is first in line. That being the case, 1. Ping can resolve server.a.com, only defined in a.com's DNS. 2. Ping can resolve server.b.com, only defined in b.com's DNS. Both TLDs also exist in the public DNS world. So the TLDs are resolvable by both DNS's. But server.a.com and server.b.com are not defined in the public DNS's. Based on what you've said, an NXDOMAIN response was not returned - because the domain did exist, only the hostname was not found. Carl -Original Message- From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Friday, December 12, 2008 7:35 PM To: NT System Admin Issues Subject: Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain On Fri, Dec 12, 2008 at 12:37 PM, Carl Houseman c.house...@gmail.com wrote: When there are multiple adapters each with their own DNS, DNS resolution is attempted on each adapter in turn until one resolves it and only fails if none of them resolve it. I believe that is inaccurate. To the best of my knowledge, an NXDOMAIN response from an authoritative nameserver *is* considered a successful result for a DNS query. The query did not fail. The local stub resolver *did* receive an answer. That answer said, I contacted a nameserver which is authoritative for the zone in question, and that nameserver said the domain name you want does not exist. A failure would be a SERVFAIL response from an intermediate full-service resolver, or no response at all (timeout). In every relevant situation I've encountered, observed behavior has corroborated the above. It's the difference between sending an email message and getting a failure notice stating The recipient address does not exist on this server, vs sending an email message and getting a failure notice stating The destination email server could not be reached after several tries; I'm giving up. The former says authoritatively the recipient address is bogus; the message could never be delivered (unless configuration changes). The later just says your message could not be delivered, but it might be a temporary problem. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
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:c.house...@gmail.com] 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/ ~
Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
On Sat, Dec 13, 2008 at 11:01 AM, Carl Houseman c.house...@gmail.com wrote: I'll let you explain them however you like! I don't have enough information to explain anything definitively, I'm afraid. :) A local LAN adapter references one Windows AD DNS - TLD= a.com Just so you know, TLD is Top Level Domain, which means com., net., us., and the like. a.com. or example.com. would be 2LD, Second Level Domain. Based on what you've said, an NXDOMAIN response was not returned - because the domain did exist, only the hostname was not found. At least one of us is confused in the above. :) If I understand what you mean correctly, it sounds like things are working exactly as I described: A query for the 2LD domain returned DNS resource records (domain did exist), but the domain name for the server resulted in NXDOMAIN (hostname was not found). Understand that in DNS, there is no such thing as a hostname. All names are domain names. com. is a domain name. example.com. is a domain name. server.example.com. is a domain name. www.example.com. is a domain name. NXDOMAIN is returned by a nameserver when a query is received for a domain name which said nameserver knows not to exist, regardless of whether said domain is a TLD, 2LD, or the domain name assigned to a server. :) This is in contrast to Active Directory, where a domain name is an entity which groups objects (computers, users, etc.) within an AD forest, but is not itself a single computer. AD clients use DNS domain names to locate AD Domain Controllers. Thus, confusingly, while every AD domain name has a DNS domain name, every AD member computer name has a DNS domain name, too. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
On Sat, Dec 13, 2008 at 12:23 PM, Carl Houseman c.house...@gmail.com wrote: psexec \\server command Couldn't access server: Meanwhile, psexec \\server.mydomain.com worked just fine. Maybe the customer has a wildcard DNS record, or a server or other entity with the same name as server in your local environment? -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
You're still not making sense, to me anyway.
Let me restate our respective claims:
My claim: The first online nameserver of each network adapter is tried, in
turn, until one of them resolves the name.
Your claim: Only the first online nameserver will be attempted to resolve a
name. Once the nameserver of *any* adapter returns an IP address, or an
NXDOMAIN, resolution attempts stop. (if that is not your claim, then I
misread your point a long time ago...)
In my situation:
a.com = local AD TLD, whose AD DNS is ns.a.com, assigned to LAN adapter
b.com = remote AD TLD, whose AD DNS is ns.b.com, assigned to PPP adapter
Both ns.a.com and ns.b.com resolve public names.
Both a.com and b.com are also defined in public DNSs.
Given these results:
1. Ping a.com - public IP of a.com is returned - resolved by ns.b.com
(because ns.a.com would not have returned a public IP).
2. NSLOOKUP server.a.com using ns.b.com - returns NXDOMAIN ('set debug'
tells me so).
3. Ping server.a.com - private IP is returned - resolved by ns.a.com
My conclusions:
b.com's nameservers are tried first due to result (1) above.
a.com's nameservers are resolving names AFTER an NXDOMAIN is returned by
ns.a.com.
This proves my claim as stated above.
I won't belabor the point after your next response, whatever it happens to
be. You may have the last word.
Carl
-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com]
Sent: Saturday, December 13, 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
On Sat, Dec 13, 2008 at 11:01 AM, Carl Houseman c.house...@gmail.com
wrote:
I'll let you explain them however you like!
I don't have enough information to explain anything definitively,
I'm afraid. :)
A local LAN adapter references one Windows AD DNS - TLD= a.com
Just so you know, TLD is Top Level Domain, which means com.,
net., us., and the like. a.com. or example.com. would be 2LD,
Second Level Domain.
Based on what you've said, an NXDOMAIN response was not returned - because
the domain did exist, only the hostname was not found.
At least one of us is confused in the above. :) If I understand
what you mean correctly, it sounds like things are working exactly as
I described: A query for the 2LD domain returned DNS resource records
(domain did exist), but the domain name for the server resulted in
NXDOMAIN (hostname was not found).
Understand that in DNS, there is no such thing as a hostname. All
names are domain names. com. is a domain name. example.com. is a
domain name. server.example.com. is a domain name.
www.example.com. is a domain name. NXDOMAIN is returned by a
nameserver when a query is received for a domain name which said
nameserver knows not to exist, regardless of whether said domain is a
TLD, 2LD, or the domain name assigned to a server. :)
This is in contrast to Active Directory, where a domain name is an
entity which groups objects (computers, users, etc.) within an AD
forest, but is not itself a single computer. AD clients use DNS
domain names to locate AD Domain Controllers. Thus, confusingly,
while every AD domain name has a DNS domain name, every AD member
computer name has a DNS domain name, too.
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
nslookup server.remotetld.com using ns.remotetld.com returns NXDOMAIN. That would suggest no to both of your suppositions. Carl -Original Message- From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Saturday, December 13, 2008 2:37 PM To: NT System Admin Issues Subject: Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain On Sat, Dec 13, 2008 at 12:23 PM, Carl Houseman c.house...@gmail.com wrote: psexec \\server command Couldn't access server: Meanwhile, psexec \\server.mydomain.com worked just fine. Maybe the customer has a wildcard DNS record, or a server or other entity with the same name as server in your local environment? -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
I'm assuming, for the moment, that the internal servers you're having problems reaching are on the same subnet? Yep, no complexity there. Also, I have to question why you have two sets of DNS servers. Why not make static entries in your local DNS for your clients? It's more work up front, but it can be automated, with dnscmd, I think. You make it sound like I did it on purpose, but the other org's DNS is established by default on the PPP adapter when the VPN is connected. And I'd prefer to have their DNS resolution available when I'm connected, vs. other workarounds. A single entry in the hosts files for my AD domain to avoid this problem is a very minor and acceptable workaround. Carl -Original Message- From: Kurt Buff [mailto:kurt.b...@gmail.com] Sent: Thursday, December 11, 2008 8:41 PM To: NT System Admin Issues Subject: Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain On Thu, Dec 11, 2008 at 6:45 AM, Carl Houseman c.house...@gmail.com wrote: Use default gateway on remote network is NOT checked for the VPN TCP/IP configuration. Dang. That eliminates my best guess. I agree with the recommendations about diagnosing in a methodical way. Here are the results. If you don't have a lot of time for reading, skip to the bottom couple paragraphs, there's a new realization there. First, I mapped a total of 6 drives to the 2 local servers in 3 different ways: One to each server with \\servername (this was done by default) One to each server with \\servername.mydomain.com One to each server with \\ip.add.re.ss Excellent! Then I connected the VPN (with VPN gateway server credentials). Then I mapped a drive to a remote AD DC (using remote domain credentials). OK. My IPCONFIG /ALL results showed (truncated to include only relevant info): Windows IP Configuration Primary Dns Suffix . . . . . . . : mydomain.com Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : mydomain.com PPP adapter VPN-to-Customer-Network: Connection-specific DNS Suffix . : Physical Address. . . . . . . . . : Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 10.1.7.33(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 10.1.1.176 10.1.1.172 Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : mydomain.com Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 192.168.55.129(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.55.1 DNS Servers . . . . . . . . . . . : 192.168.55.10 [my DC/Local-DNS] I checked DNS resolution at this time. I could resolve FQDN's of both my domain and the remote domain. I've noticed that, when there are multiple connections each with their own DNS, DNS's of each connection will be tried in turn until one resolves the request. You want to see route print because you still don't trust the gateway setting I already confirmed? Heh. No need to get testy, there youngster... Active Routes (just the important ones): Network DestinationNetmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.55.1 192.168.55.129 25 10.0.0.0255.0.0.0 10.1.5.13510.1.7.33 21 And tracert was giving 1 hop to local servers, 2 hops to remote network servers, such as 10.1.1.172. OK. The first results came 20-30 minutes later, when the first mapped drives were lost. Which ones? Those mapped to \\ip.add.re.ss ! The other 4 were still working. At this point I re-checked pinging by by FQDN to both local and remote servers, and both were working and resolving correctly, even after an ipconfig /flushdns. Tracert unchanged. About 8 hours later, but with no activity, the other mapped drives were still good. I started doing some work and suddenly, the two drives mapped to \\servername were exhibiting the problem AT THE SAME TIME, which is unusual (typically the member server is the first to go by a margin of more than a couple minutes). The drives mapped to \\servername.mydomain.com still worked. Results of ping, tracert, ipconfig, route print, all unchanged. When I went to disconnect (NET USE /D) the drive mapped to my local DC with \\servername, it told me There are open files and/or incomplete directory searches pending on the connection to m:. Curious. I forced it, and tried a net use m: /home to restore it. That failed: The user's home directory could not be determined. My user account specifies \\server\share for my home directory. LIkewise, net use m: \\server\share got The password or user name is invalid for \\servername\share and prompted for a password. It was trying
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
The list of DNS servers that Windows maintains means Ask this server first. If that server *doesn't respond*, ask this other server next. It does *not* mean, Ask this server first. If we don't get an answer we like, ask this other server next. Not exactly true. It is true for multiple DNS's assigned to a single adapter. When there are multiple adapters each with their own DNS, DNS resolution is attempted on each adapter in turn until one resolves it and only fails if none of them resolve it. Carl -Original Message- From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Wednesday, December 10, 2008 9:35 PM To: NT System Admin Issues Subject: Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain On Wed, Dec 10, 2008 at 4:29 PM, Carl Houseman c.house...@gmail.com wrote: The default DNS after connecting (the one that NSLOOKUP identifies) is a server on the client network's in the client's AD domain ... I'd bet money (or, at least, popcorn) that's your problem. The list of DNS servers that Windows maintains means Ask this server first. If that server *doesn't respond*, ask this other server next. It does *not* mean, Ask this server first. If we don't get an answer we like, ask this other server next. What happens to most people is they've got something like corp.example.com which is their Active Directory domain name. However, that domain name is not delegated in the public DNS. example.com exists in the public DNS, but there are no NS records delegating control to your Active Directory DNS servers. In other words, if I sit here on my home PC and type dig corp.example.com., I'm going to get an NXDOMAIN (non-existent domain) response from the nameservers authoritative for example.com. When that happens to your Windows DNS client, *it stops looking*. It takes that non-existent domain message as authoritative (because it is). DNS does *not* then go and try your own corporate DNS servers to see if *they* happen to know about a corp.example.com. Since AD depends on DNS to find and authenticate to domain controllers, if DNS isn't working, everything will fall apart. The varied delays are prolly due to various kinds of caching and timeouts. You can check this theory by running an NSLOOKUP for SRV records associated with the Active Directory domain name. If your own AD domain is corp.example.com, connect with the VPN, then run the command: NSLOOKUP -type=SRV _ldap._tcp.corp.example.com. The _ldap._tcp SRV record is the magic that lets an Active Directory client find the Domain Controller(s) for a domain. It all hinges on that. If this is your problem, you should be able to do something about it, but it's not without complications. On Win XP (I dunno about Vista): 1. Open the Network Connections folder 2. From the menu bar, open the Advanced menu, then choose Advanced Settings 3. Select the Adapters and Bindings tab 4. Look in the Connections list 5. Move the icon for the VPN all the way down to the bottom 6. Move the icon for whatever connects you to your own private network all the way up to the top That will mean your private DNS servers then take precedence over VPN-provided DNS servers. Now, possible complications... Complication #1: It's entirely likely you now won't be able to connect to resources on the customer's network. That's because your own DNS servers will now be telling your computer that *their* network domain name doesn't exist. Solution #1 to complication #1: You might be able to get away with HOSTS and LMHOSTS file entries for the customer servers. Solution #2 to complication #1: If your local DNS servers are running on Win 2003 or later, you can configure selective forwarding, such that your customer's domain name is forwarded to the customer's DNS servers. However, that will require your local DNS servers to be able to reach customer DNS servers via IP, which likely won't work with your VPN. You'd need to configure a VPN gateway for your whole local network. Complication #2: If you use the same VPN for yourself to connect to your own company network, you might find you have the same problem the other way around: When VPN'ing in, you can't resolve your company's private domain. Solution #1 to complication #2: Manually adjust binding order before each connection. Solution #2 to complication #2: HOSTS/LMHOSTS again. Complication #3: If you're using customer-provided VPN software that forces settings upon you, you might not be able to make these adjustments. If so, you'll have to negotiate with your customer. Hope this helps, -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
It looks like the problem is solved. I've been reviewing all the responses to see if anyone won the popcorn... :) John Gwinner's answer was the first to call DNS into question and he also described what ended up being the problem - the fact that my AD domain name was being resolved by the remote org's DNS to a public IP. If I'd not been so skeptical I could have solved the problem faster based on his answer. So John, if you want a bag of popcorn, send me your mailing address privately and choose one of these flavors (they're all good!): - Peanut butter and white chocolate - Chocolate chunk and caramel - Milk chocolate and white chocolate Again, thanks to everybody for their comments, and Happy Holidays to all. Carl From: Carl Houseman [mailto:c.house...@gmail.com] 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/ ~
Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
Carl, Is this what you guys do? Make popcorn? What's the website, I might put an order in too...I love that stuff. Steve On Fri, Dec 12, 2008 at 12:29 PM, Carl Houseman c.house...@gmail.comwrote: It looks like the problem is solved. I've been reviewing all the responses to see if anyone won the popcorn... :) John Gwinner's answer was the first to call DNS into question and he also described what ended up being the problem – the fact that my AD domain name was being resolved by the remote org's DNS to a public IP. If I'd not been so skeptical I could have solved the problem faster based on his answer. So John, if you want a bag of popcorn, send me your mailing address privately and choose one of these flavors (they're all good!): - Peanut butter and white chocolate - Chocolate chunk and caramel - Milk chocolate and white chocolate Again, thanks to everybody for their comments, and Happy Holidays to all. Carl *From:* Carl Houseman [mailto:c.house...@gmail.com] *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/ ~
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
Well crap. The problem just happened again. Sorry John, looks like you don't get the popcorn. pinging my local AD TLD is hitting the correct server. Big heavy sigh. What else could it be? I guess I'll go with mapping drives to FQDN's and see where that gets me. Carl From: Carl Houseman [mailto:c.house...@gmail.com] Sent: Friday, December 12, 2008 1:29 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain It looks like the problem is solved. I've been reviewing all the responses to see if anyone won the popcorn... :) John Gwinner's answer was the first to call DNS into question and he also described what ended up being the problem - the fact that my AD domain name was being resolved by the remote org's DNS to a public IP. If I'd not been so skeptical I could have solved the problem faster based on his answer. So John, if you want a bag of popcorn, send me your mailing address privately and choose one of these flavors (they're all good!): - Peanut butter and white chocolate - Chocolate chunk and caramel - Milk chocolate and white chocolate Again, thanks to everybody for their comments, and Happy Holidays to all. Carl From: Carl Houseman [mailto:c.house...@gmail.com] 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/ ~
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
What does your wins look like? What's the Kerb lifetime of the remote and are they defaulting to UDP or TCP and what do your tickets look like? (kerbtray and klist are your friends) The title of this KB says services, and it's old (but still valid), but it's about any time you are changing security contexts: http://support.microsoft.com/kb/180362 Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael I'll be at TEC'2009! http://www.tec2009.com/vegas/index.php From: Carl Houseman [mailto:c.house...@gmail.com] Sent: Friday, December 12, 2008 2:45 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain Well crap. The problem just happened again. Sorry John, looks like you don't get the popcorn. pinging my local AD TLD is hitting the correct server. Big heavy sigh. What else could it be? I guess I'll go with mapping drives to FQDN's and see where that gets me. Carl From: Carl Houseman [mailto:c.house...@gmail.com] Sent: Friday, December 12, 2008 1:29 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain It looks like the problem is solved. I've been reviewing all the responses to see if anyone won the popcorn... :) John Gwinner's answer was the first to call DNS into question and he also described what ended up being the problem - the fact that my AD domain name was being resolved by the remote org's DNS to a public IP. If I'd not been so skeptical I could have solved the problem faster based on his answer. So John, if you want a bag of popcorn, send me your mailing address privately and choose one of these flavors (they're all good!): - Peanut butter and white chocolate - Chocolate chunk and caramel - Milk chocolate and white chocolate Again, thanks to everybody for their comments, and Happy Holidays to all. Carl From: Carl Houseman [mailto:c.house...@gmail.com] 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
Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
On Fri, Dec 12, 2008 at 12:37 PM, Carl Houseman c.house...@gmail.com wrote: When there are multiple adapters each with their own DNS, DNS resolution is attempted on each adapter in turn until one resolves it and only fails if none of them resolve it. I believe that is inaccurate. To the best of my knowledge, an NXDOMAIN response from an authoritative nameserver *is* considered a successful result for a DNS query. The query did not fail. The local stub resolver *did* receive an answer. That answer said, I contacted a nameserver which is authoritative for the zone in question, and that nameserver said the domain name you want does not exist. A failure would be a SERVFAIL response from an intermediate full-service resolver, or no response at all (timeout). In every relevant situation I've encountered, observed behavior has corroborated the above. It's the difference between sending an email message and getting a failure notice stating The recipient address does not exist on this server, vs sending an email message and getting a failure notice stating The destination email server could not be reached after several tries; I'm giving up. The former says authoritatively the recipient address is bogus; the message could never be delivered (unless configuration changes). The later just says your message could not be delivered, but it might be a temporary problem. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
So, even easier! Set up an authoritative entry in *their* DNS server for your domain, and point the IP addresses in it the way you want. Tastes great, less filling! On Fri, Dec 12, 2008 at 9:30 AM, Carl Houseman c.house...@gmail.com wrote: I'm assuming, for the moment, that the internal servers you're having problems reaching are on the same subnet? Yep, no complexity there. Also, I have to question why you have two sets of DNS servers. Why not make static entries in your local DNS for your clients? It's more work up front, but it can be automated, with dnscmd, I think. You make it sound like I did it on purpose, but the other org's DNS is established by default on the PPP adapter when the VPN is connected. And I'd prefer to have their DNS resolution available when I'm connected, vs. other workarounds. A single entry in the hosts files for my AD domain to avoid this problem is a very minor and acceptable workaround. Carl -Original Message- From: Kurt Buff [mailto:kurt.b...@gmail.com] Sent: Thursday, December 11, 2008 8:41 PM To: NT System Admin Issues Subject: Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain On Thu, Dec 11, 2008 at 6:45 AM, Carl Houseman c.house...@gmail.com wrote: Use default gateway on remote network is NOT checked for the VPN TCP/IP configuration. Dang. That eliminates my best guess. I agree with the recommendations about diagnosing in a methodical way. Here are the results. If you don't have a lot of time for reading, skip to the bottom couple paragraphs, there's a new realization there. First, I mapped a total of 6 drives to the 2 local servers in 3 different ways: One to each server with \\servername (this was done by default) One to each server with \\servername.mydomain.com One to each server with \\ip.add.re.ss Excellent! Then I connected the VPN (with VPN gateway server credentials). Then I mapped a drive to a remote AD DC (using remote domain credentials). OK. My IPCONFIG /ALL results showed (truncated to include only relevant info): Windows IP Configuration Primary Dns Suffix . . . . . . . : mydomain.com Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : mydomain.com PPP adapter VPN-to-Customer-Network: Connection-specific DNS Suffix . : Physical Address. . . . . . . . . : Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 10.1.7.33(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 10.1.1.176 10.1.1.172 Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : mydomain.com Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 192.168.55.129(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.55.1 DNS Servers . . . . . . . . . . . : 192.168.55.10 [my DC/Local-DNS] I checked DNS resolution at this time. I could resolve FQDN's of both my domain and the remote domain. I've noticed that, when there are multiple connections each with their own DNS, DNS's of each connection will be tried in turn until one resolves the request. You want to see route print because you still don't trust the gateway setting I already confirmed? Heh. No need to get testy, there youngster... Active Routes (just the important ones): Network DestinationNetmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.55.1 192.168.55.129 25 10.0.0.0255.0.0.0 10.1.5.13510.1.7.33 21 And tracert was giving 1 hop to local servers, 2 hops to remote network servers, such as 10.1.1.172. OK. The first results came 20-30 minutes later, when the first mapped drives were lost. Which ones? Those mapped to \\ip.add.re.ss ! The other 4 were still working. At this point I re-checked pinging by by FQDN to both local and remote servers, and both were working and resolving correctly, even after an ipconfig /flushdns. Tracert unchanged. About 8 hours later, but with no activity, the other mapped drives were still good. I started doing some work and suddenly, the two drives mapped to \\servername were exhibiting the problem AT THE SAME TIME, which is unusual (typically the member server is the first to go by a margin of more than a couple minutes). The drives mapped to \\servername.mydomain.com still worked. Results of ping, tracert, ipconfig, route print, all unchanged. When I went to disconnect (NET USE /D) the drive mapped to my local DC with \\servername, it told me There are open files and/or incomplete directory searches pending on the connection to m:. Curious. I forced it, and tried a net use m: /home to restore it. That failed
Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
On Wed, Dec 10, 2008 at 11:34 PM, Kurt Buff [EMAIL PROTECTED] wrote: Start at the beginning... When this problem occurs, can you ping the hard-to-reach server by IP address? ... Indeed. It's always a good idea to follow a methodical approach. Work step-by-step to identify what works, and isolate the trouble. However, that being said: From the original description, his mapped drives don't immediately stop working. They're okay for a little while, and fall apart after a few minutes. If he was loosing IP connectivity, he'd loose that right away. Also, the default gateway will only matter if the domain controller or other servers he's trying to reach are not on his local subnet. (Which may be the case, of course; just thought it was worth mentioning.) -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
Then ping the hostnames, see if you can resolve the names. That is my bet. The VPN is taking over your dns/wins. The delay is perhaps the time the resolutions live in your cache before they go poof. -Original Message- From: Ben Scott [mailto:[EMAIL PROTECTED] Sent: Thursday, December 11, 2008 8:25 AM To: NT System Admin Issues Subject: Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain On Wed, Dec 10, 2008 at 11:34 PM, Kurt Buff [EMAIL PROTECTED] wrote: Start at the beginning... When this problem occurs, can you ping the hard-to-reach server by IP address? ... ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/ ~
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
network's DNS... and what will happen if I do that. Hmmm. checking
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage\Bind, I see:
\Device\{1BF6FDBF-63AF-4A12-9A68-BFD7D06BB920}
\Device\NdisWanIp
\Device\{277E3FE6-F44A-473C-B5F1-0F38683D56A1}
\Device\{DBA2C2F4-E6FA-4BC7-8008-0CC46A3A77DA}
I moved NdisWanIP to the bottom of the list. Now, NSLOOKUP is defaulting to
my local DNS server as expected. But, ping mydomain.com is still
resolving to the public IP. IPCONFIG /FLUSHDNS. Ping domain.com. Still
reaching the public IP. Where is this DNS lookup cached? Grrr, Vista has
too many caches!
So let's try a hosts entry for mydomain.com. Ping mydomain.com - now
reaches the correct private IP. But net use m: /home - still fails. net
use m: \\servername\share - still fails. Still cached somewhere?
I'll have to reboot and start again with only the hosts entry for
mydomain.com as the workaround, and see what the results are. More when I
know more. Thanks everybody for your comments.
Carl
-Original Message-
From: Kurt Buff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 11:35 PM
To: NT System Admin Issues
Subject: Re: Lose access to local domain servers when connected w/VPN to
remote / different Windows domain
Start at the beginning...
When this problem occurs, can you ping the hard-to-reach server by IP
address? What does 'ping -a ip.add.re.ss' reveal? If those work, ping
by name, but if those fail, what does tracert reveal? What does
ipconfig /all reveal - as others have voiced, I have my suspicions
about the default gateway being set to the remote network, but first
things first.
Kurt
On Wed, Dec 10, 2008 at 11:28 AM, 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/ ~
Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
On Thu, Dec 11, 2008 at 6:45 AM, Carl Houseman c.house...@gmail.com wrote: Use default gateway on remote network is NOT checked for the VPN TCP/IP configuration. Dang. That eliminates my best guess. I agree with the recommendations about diagnosing in a methodical way. Here are the results. If you don't have a lot of time for reading, skip to the bottom couple paragraphs, there's a new realization there. First, I mapped a total of 6 drives to the 2 local servers in 3 different ways: One to each server with \\servername (this was done by default) One to each server with \\servername.mydomain.com One to each server with \\ip.add.re.ss Excellent! Then I connected the VPN (with VPN gateway server credentials). Then I mapped a drive to a remote AD DC (using remote domain credentials). OK. My IPCONFIG /ALL results showed (truncated to include only relevant info): Windows IP Configuration Primary Dns Suffix . . . . . . . : mydomain.com Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : mydomain.com PPP adapter VPN-to-Customer-Network: Connection-specific DNS Suffix . : Physical Address. . . . . . . . . : Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 10.1.7.33(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 10.1.1.176 10.1.1.172 Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : mydomain.com Autoconfiguration Enabled . . . . : Yes IPv4 Address. . . . . . . . . . . : 192.168.55.129(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.55.1 DNS Servers . . . . . . . . . . . : 192.168.55.10 [my DC/Local-DNS] I checked DNS resolution at this time. I could resolve FQDN's of both my domain and the remote domain. I've noticed that, when there are multiple connections each with their own DNS, DNS's of each connection will be tried in turn until one resolves the request. You want to see route print because you still don't trust the gateway setting I already confirmed? Heh. No need to get testy, there youngster... Active Routes (just the important ones): Network DestinationNetmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.55.1 192.168.55.129 25 10.0.0.0255.0.0.0 10.1.5.13510.1.7.33 21 And tracert was giving 1 hop to local servers, 2 hops to remote network servers, such as 10.1.1.172. OK. The first results came 20-30 minutes later, when the first mapped drives were lost. Which ones? Those mapped to \\ip.add.re.ss ! The other 4 were still working. At this point I re-checked pinging by by FQDN to both local and remote servers, and both were working and resolving correctly, even after an ipconfig /flushdns. Tracert unchanged. About 8 hours later, but with no activity, the other mapped drives were still good. I started doing some work and suddenly, the two drives mapped to \\servername were exhibiting the problem AT THE SAME TIME, which is unusual (typically the member server is the first to go by a margin of more than a couple minutes). The drives mapped to \\servername.mydomain.com still worked. Results of ping, tracert, ipconfig, route print, all unchanged. When I went to disconnect (NET USE /D) the drive mapped to my local DC with \\servername, it told me There are open files and/or incomplete directory searches pending on the connection to m:. Curious. I forced it, and tried a net use m: /home to restore it. That failed: The user's home directory could not be determined. My user account specifies \\server\share for my home directory. LIkewise, net use m: \\server\share got The password or user name is invalid for \\servername\share and prompted for a password. It was trying to use the VPN gateway credentials. I then tried net use m: \\servername.mydomain.com\share and that worked. But it gets weird here. I went into ADUC (from the same Vista machine) and changed my user account profile's home directory to \\servername.mydomain.com\share. I then tried net use m: /home again. The user's home directory could not be determined. Went to another machine where I was already logged on, disconnected m: and then net use m: /home - worked. WTF? This has been interesting experiment, though little is explained. Just to re-cap, through all this, DNS, ping, tracert, route print, ipconfig /all results have remained the same, even after ipconfig /flushdns. One thing that now occurs to me, my AD domain name is also my public domain name (split DNS), with the public one pointing to a public IP for Internet E-mail purposes. So if something was trying to work off that top level name, it would get a
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 serversame 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/ ~
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 serversame 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/ ~
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 serversame 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/ ~
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
Have you tried un-checking the option to Use default gateway on remote network, under the general tab of the advanced tcp/ip settings for the VPN connection? From: Carl Houseman [mailto:[EMAIL PROTECTED] Posted At: Wednesday, December 10, 2008 2:28 PM Posted To: Sunbelt NT Conversation: Lose access to local domain servers when connected w/VPN to remote / different Windows domain 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/ ~
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
All VPN connections are set up that way. Also ISA is not required to provoke the problem. I can get the same thing when SBS 2003 is my VPN gateway. From: Dean Sadler [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 4:10 PM To: NT System Admin Issues Subject: RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain Have you tried un-checking the option to Use default gateway on remote network, under the general tab of the advanced tcp/ip settings for the VPN connection? From: Carl Houseman [mailto:[EMAIL PROTECTED] Posted At: Wednesday, December 10, 2008 2:28 PM Posted To: Sunbelt NT Conversation: Lose access to local domain servers when connected w/VPN to remote / different Windows domain 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/ ~
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
You've tried changing the provider order under advanced networking? I don't terminate to isa boxes but other vpn products (I commonly use Sonicwall) do not have this feature, so it might be something along the ISA lines (AD integrated or RADIUS?) I do work with several ISA boxes and I guess I could try to confirm/repeat the issue. What if you do a net use x: \\localserver\share file:///\\localserver\share /user:[EMAIL PROTECTED] password ?? after you receive that error? Unless the security policy of the domain does not allow that connection (I forget which option it is under Security Policy) you should be able to present different credentials manually. From: Carl Houseman [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 15:30 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 serversame 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/ ~
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 serversame 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
RE: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
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 serversame username and password I presume
Re: Lose access to local domain servers when connected w/VPN to remote / different Windows domain
Start at the beginning... When this problem occurs, can you ping the hard-to-reach server by IP address? What does 'ping -a ip.add.re.ss' reveal? If those work, ping by name, but if those fail, what does tracert reveal? What does ipconfig /all reveal - as others have voiced, I have my suspicions about the default gateway being set to the remote network, but first things first. Kurt On Wed, Dec 10, 2008 at 11:28 AM, 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/ ~
