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 <[email protected]>wrote: > 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:[email protected]] > *Sent:* Wednesday, December 10, 2008 2:28 PM > *To:* NT System Admin Issues > *Subject:* Lose access to local domain servers when connected w/VPN to > remote / different Windows domain > > > > This problem has bothered me a long time, and happens daily. It's so > bothersome, I'll send some Dale & Thomas popcorn to the first person who can > come up with a solution or a tip that quickly (without many hours of effort > on my part) leads to a solution. Advice such as "call Microsoft" does not > qualify for the popcorn! > > > > Past history: The problem was seen for Windows XP but seems to be worse > under Vista. In fact I wrote about it in reference to XP to this list a > year or two ago without any resolution. Certainly what I'm doing here can't > be that unique, aside from relying on Microsoft-based VPN solutions... > (kindly withhold comments on the worthiness of those solutions). > > > > Goes like this: > > > > In my local office, there are two 2003 servers – member and domain > controller. My everyday Vista SP1 is joined to that domain. I have drives > mapped to both servers. > > > > I use an L2TP/IPSEC VPN connection to connect to a client's network. The > client's VPN gateway is ISA 2006, joined to the client's Windows domain, but > I authenticate for the purpose of the VPN connection using a local username > on the ISA server. We'll call the ISA server "ISAVPN" in further > discussion. > > > > What happens: Sooner or later I will be unable to access the drives mapped > to my local domain's servers (UNC references to those servers also fail). > The error returned when just trying to do anything at the CMD prompt > defaulted to a mapped drive on either server is: > > > > Logon failure: unknown user name or bad password. > > > > Once I disconnect from ISAVPN, at the very same CMD prompt, I again and > immediately have access to files on my local servers. > > > > This seems to affect access to the member server a short time after > connecting to ISAVPN. Access to files on the domain controller usually > keeps working much longer, but eventually I lose it as well. This behavior > has guaranteed repeatability 100% of the time. > > > > I should note that the domain controller's mapped drive is "available > offline" but Vista does not switch to offline because of this problem. > > > > Looking in the security event log of the server, I see events 529 and 680 > (source Security), in pairs, related to the login failure, with the 529 > having the most information: > > > > Logon Failure: > > Reason: Unknown user name or bad password > > User Name: local_username_on_ISAVPN > > Domain: ISAVPN > > Logon Type: 3 > > Logon Process: NtLmSsp > > Authentication Package: NTLM > > Workstation Name: MYVISTAPC > > > > My take on it: At some point, SMB access has to re-authenticate and is > using the more recent credentials from the VPN connection to talk to my > local servers. I'm guessing binding order somewhere is the problem, but > where can I find and fix this binding order? A permanent one-time solution > would be nice, but it's OK if I have to fix it every time after making the > VPN connection. > > > > thanks all, > > Carl > > > > > > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
