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 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/> ~
