Remote accessing file shares problem

Here's a story:

Client logs into a domain laptop in the office, which generates the cached
set of credentials for their domain user account.

Client travels off-site and successfully logs into the laptop with cached
credentials.

Client connects to the VPN

Client attempts to access a network share which is located at the office,
for which they have permissions, which firewall rules allow, and which works
when the Client is onsite. Permissions to this share are granted via the
clients domain account.

Client is prompted for username/password for the fileshare. Client enters
“domain\username� and their password. The following error is received:

---
“The user name you typed is the same as the user name you logged in with.
That user name has already been tried. A domain controller cannot be found to
verify that user name.�
---

However, if “username@domain_name.com� is used as the user name, the login
works.

If we add entries to the LMHOSTS file of the client pointing to the domain
controllers, the client is able to access the share without being prompted
for a username/password. ***This is the desired result*** However, I’m
certainly not getting into the business of maintaining LMHosts files on all
clients.

I can telnet, via the VPN connection, to ports 53 and 445 on each DC.

What is causing this condition? I do not think that the client, using cached
domain credentials, should be prompted for a username/password at all when
accessing domain resources. Further, the fact that “domain\user� does _not_
work and “user@domain� _does_ is very curious.

"NRC Help" <(E-Mail Removed)> wrote in message
news:33E3ABD9-FAF2-40FA-8E79-(E-Mail Removed)...
> Client is prompted for username/password for the fileshare. Client enters
> "domain\username" and their password. The following error is received:
>
> ---
> "The user name you typed is the same as the user name you logged in with.
> That user name has already been tried. A domain controller cannot be found
> to
> verify that user name."
>
> What is causing this condition? I do not think that the client, using
> cached
> domain credentials, should be prompted for a username/password at all when
> accessing domain resources. Further, the fact that "domain\user" does
> _not_
> work and "user@domain" _does_ is very curious.

Forget the LMHOST file and put them back the way they were.

In the Configuration of the Dialup Connection (the VPN Connection)
statically give it the DNS and WINS (if you have WINS) for the LAN.
Normally DHCP would give these but some VPN "Devices" won't give the Clients
that,...they only give the IP# and mask.

It is also a good thing if the users enable the checkbox seen at the
Ctrl-Alt-Del prompt that says "Log in with dialup connection". This causes
the machine to enable the VPN first,...then log the user into the
machine,..which creates the same effect as logging into the Domain locally.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

Thanks for the strong reply. Of course the LMHosts file is in no way an end
solution, simply a means to troubleshoot at this point.

Reading your post, I assume you're working with the MS VPN client. However,
I'm working with the Cisco VPN client, and the concentrator is outside of my
control. Any tips on the client end before I go digging?

Thanks.

"Phillip Windell" wrote:

> "NRC Help" <(E-Mail Removed)> wrote in message
> news:33E3ABD9-FAF2-40FA-8E79-(E-Mail Removed)...
> > Client is prompted for username/password for the fileshare. Client enters
> > "domain\username" and their password. The following error is received:
> >
> > ---
> > "The user name you typed is the same as the user name you logged in with.
> > That user name has already been tried. A domain controller cannot be found
> > to
> > verify that user name."
> >
> > What is causing this condition? I do not think that the client, using
> > cached
> > domain credentials, should be prompted for a username/password at all when
> > accessing domain resources. Further, the fact that "domain\user" does
> > _not_
> > work and "user@domain" _does_ is very curious.
>
> Forget the LMHOST file and put them back the way they were.
>
> In the Configuration of the Dialup Connection (the VPN Connection)
> statically give it the DNS and WINS (if you have WINS) for the LAN.
> Normally DHCP would give these but some VPN "Devices" won't give the Clients
> that,...they only give the IP# and mask.
>
> It is also a good thing if the users enable the checkbox seen at the
> Ctrl-Alt-Del prompt that says "Log in with dialup connection". This causes
> the machine to enable the VPN first,...then log the user into the
> machine,..which creates the same effect as logging into the Domain locally.
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
>
>

Any Resolution to this issue? We are experiencing the exact same
problem.

Thanks,

Jason

Jason,

Sorry for the slow reply.

No, we have not reached or received a resolution. Using a VPN client other
than the provided Cisco client is not an option, but it's the best solution
offered.

I'm more than happy to compare notes with you and maybe we can work it out
or even get some MVPs to pick up on it. If you want, go ahead and post your
notes in the original thread and we'll start there.

Thanks,

Tony

"Jason Cornell" wrote:

> Any Resolution to this issue? We are experiencing the exact same
> problem.
>
> Thanks,
>
> Jason
>
>

Vincent,

I never properly replied here. I'll apologize for that, but the reason I
didn't reply was that you're going down this "Microsoft Products Only" road,
which is a world we don't live in.

>>1. What is the OS of the VPN Server ? Windows 2000 or Windows 2003 or
third-party ? (Cisco?)

1A: Cisco

>>2. If it is Windows 2000 or Windows 2003 server, is it in the domain?

2A: No.

>>3. When you log on to the VPN server, did you use the domain user account?
If not, which account?

3A: It's not the users' domain account. The account being used is maintained
outside of our systems, as is the VPN concentrator.


>> 1. Build up a VPN Server on a Windows 2003 server
1A: That's not incredibly realistic in our situation. We already have VPN
services available, and free resources need to be allocated to different
projects.

>> 2. Build a VPN session (MS client) from a computer which is in the LAN.
2A: I don't understand the solution here. Can you extrapolate?

>>3. Check if you can access the shared resource
3A: I'm not sure I understand your question. Yes, the resource can
ultimately be accessed, but the user must provide login credentials - which
they shouldn't have to b/c they're already using cached credentials - *AND*
they must use their UPN when authenticating. 'domain\username' is not valid
(and should be, IMO).

Thanks,

Tony

"Vincent Xu [MSFT]" wrote:

> Hi,
>
> I agree with you we'd better narrow down this issue.
>
> 1. What is the OS of the VPN Server ? Windows 2000 or Windows 2003 or
> third-party ? (Cisco?)
>
> 2. If it is Windows 2000 or Windows 2003 server, is it in the domain?
>
> 3. When you log on to the VPN server, did you use the domain user account?
> If not, which account?
>
> If possible (I strongly recommend you to do this):
>
> 1. Build up a VPN Server on a Windows 2003 server
> 2. Build a VPN session (MS client) from a computer which is in the LAN.
> 3. Check if you can access the shared resource.
>
> Thanks.
>
> Best regards,
>
> Vincent Xu
> Microsoft Online Partner Support
>
> ================================================== ====
> Get Secure! - www.microsoft.com/security
> ================================================== ====
> When responding to posts, please "Reply to Group" via your newsreader so
> that others
> may learn and benefit from this issue.
> ================================================== ====
> This posting is provided "AS IS" with no warranties,and confers no rights.
> ================================================== ====
>
>
>
> --------------------
> >>Thread-Topic: Remote accessing file shares problem
> >>thread-index: AcakVCo8jB3YclTKRYm19KaylpNVyA==
> >>X-WBNR-Posting-Host: 35.8.207.90
> >>From: =?Utf-8?B?TlJDIEhlbHA=?= <(E-Mail Removed)>
> >>References: <33E3ABD9-FAF2-40FA-8E79-(E-Mail Removed)>
> <O6$(E-Mail Removed)>
> <85068CF5-1ABC-4F55-9240-(E-Mail Removed)>
> <BN#cKE#(E-Mail Removed)>
> >>Subject: Re: Remote accessing file shares problem
> >>Date: Mon, 10 Jul 2006 12:08:01 -0700
> >>Lines: 148
> >>Message-ID: <31E02744-EA8C-487D-9A79-(E-Mail Removed)>
> >>MIME-Version: 1.0
> >>Content-Type: text/plain;
> >> charset="Utf-8"
> >>Content-Transfer-Encoding: 7bit
> >>X-Newsreader: Microsoft CDO for Windows 2000
> >>Content-Class: urn:content-classes:message
> >>Importance: normal
> >>Priority: normal
> >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
> >>Newsgroups: microsoft.public.windows.server.networking
> >>Path: TK2MSFTNGXA01.phx.gbl
> >>Xref: TK2MSFTNGXA01.phx.gbl
> microsoft.public.windows.server.networking:40257
> >>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250
> >>X-Tomcat-NG: microsoft.public.windows.server.networking
> >>
> >>1. I belive it does, but we have very limited ability to customize it's
> >>functionality since we don't maintain the concentrator (I believe).
> >>
> >>2. I agree that when the UPN is used it should contact the DC - but it
> >>should also contact the DC when domain\username is used.
> >>
> >>3. Before....? Yes. Afterwards too. Same results.
> >>
> >>4. This is a recent change though. What changed and why? I agree that
> there
> >>could be something changed in our environment, but help isolating that
> would
> >>be nice.
> >>
> >>5. Since I don't have controll/access to the concentrator, that won't do
> me
> >>much good.
> >>
> >>Thanks for the help though.
> >>
> >>
> >>"Vincent Xu [MSFT]" wrote:
> >>
> >>> Hi,
> >>>
> >>> I have following thoughts:
> >>>
> >>> 1. Did the Cisco client has the similar function as MS VPN client that
> "Log
> >>> in with dialup connection"?
> >>>
> >>> 2. When you use UPN name to verify the user name & password, I think it
> >>> should contacted the GC. That's why it is logged on successfully.
> >>>
> >>> 3. As you said, you modified the LMhost file, did you restart the
> computer
> >>> before you modify it?
> >>>
> >>> 4. As we know, when you logged on as cached credential and later
> attempts
> >>> to establish a VPN connection to the network and enters credentials, no
> >>> interactive logon is attempted. Thus, no access token was made. That is
> why
> >>> you are prompted to ask for user name and password later.
> >>>
> >>> 5. As I said in Point 1, you can try to contact Cisco to see if their
> >>> client has the function.
> >>>
> >>> I hope the information helps. Let me know if you still have concerns.
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Vincent Xu
> >>> Microsoft Online Partner Support
> >>>
> >>> ================================================== ====
> >>> Get Secure! - www.microsoft.com/security
> >>> ================================================== ====
> >>> When responding to posts, please "Reply to Group" via your newsreader
> so
> >>> that others
> >>> may learn and benefit from this issue.
> >>> ================================================== ====
> >>> This posting is provided "AS IS" with no warranties,and confers no
> rights.
> >>> ================================================== ====
> >>>
> >>>
> >>>
> >>> --------------------
> >>> >>Thread-Topic: Remote accessing file shares problem
> >>> >>thread-index: AcaiHALt+aGbGzv4TRqcBDNsVC72xA==
> >>> >>X-WBNR-Posting-Host: 67.172.94.222
> >>> >>From: =?Utf-8?B?TlJDIEhlbHA=?= <(E-Mail Removed)>
> >>> >>References: <33E3ABD9-FAF2-40FA-8E79-(E-Mail Removed)>
> >>> <O6$(E-Mail Removed)>
> >>> >>Subject: Re: Remote accessing file shares problem
> >>> >>Date: Fri, 7 Jul 2006 16:21:01 -0700
> >>> >>Lines: 47
> >>> >>Message-ID: <85068CF5-1ABC-4F55-9240-(E-Mail Removed)>
> >>> >>MIME-Version: 1.0
> >>> >>Content-Type: text/plain;
> >>> >> charset="Utf-8"
> >>> >>Content-Transfer-Encoding: 7bit
> >>> >>X-Newsreader: Microsoft CDO for Windows 2000
> >>> >>Content-Class: urn:content-classes:message
> >>> >>Importance: normal
> >>> >>Priority: normal
> >>> >>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
> >>> >>Newsgroups: microsoft.public.windows.server.networking
> >>> >>Path: TK2MSFTNGXA01.phx.gbl
> >>> >>Xref: TK2MSFTNGXA01.phx.gbl
> >>> microsoft.public.windows.server.networking:40182
> >>> >>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250
> >>> >>X-Tomcat-NG: microsoft.public.windows.server.networking
> >>> >>
> >>> >>Thanks for the strong reply. Of course the LMHosts file is in no way
> an
> >>> end
> >>> >>solution, simply a means to troubleshoot at this point.
> >>> >>
> >>> >>Reading your post, I assume you're working with the MS VPN client.
> >>> However,
> >>> >>I'm working with the Cisco VPN client, and the concentrator is
> outside of
> >>> my
> >>> >>control. Any tips on the client end before I go digging?
> >>> >>
> >>> >>Thanks.
> >>> >>
> >>> >>"Phillip Windell" wrote:
> >>> >>
> >>> >>> "NRC Help" <(E-Mail Removed)> wrote in message
> >>> >>> news:33E3ABD9-FAF2-40FA-8E79-(E-Mail Removed)...
> >>> >>> > Client is prompted for username/password for the fileshare.
> Client
> >>> enters
> >>> >>> > "domain\username" and their password. The following error is
> received:
> >>> >>> >
> >>> >>> > ---
> >>> >>> > "The user name you typed is the same as the user name you logged
> in
> >>> with.
> >>> >>> > That user name has already been tried. A domain controller cannot
> be
> >>> found
> >>> >>> > to
> >>> >>> > verify that user name."
> >>> >>> >
> >>> >>> > What is causing this condition? I do not think that the client,
> using
> >>> >>> > cached
> >>> >>> > domain credentials, should be prompted for a username/password at
> all
> >>> when
> >>> >>> > accessing domain resources. Further, the fact that "domain\user"
> does
> >>> >>> > _not_
> >>> >>> > work and "user@domain" _does_ is very curious.
> >>> >>>
> >>> >>> Forget the LMHOST file and put them back the way they were.
> >>> >>>
> >>> >>> In the Configuration of the Dialup Connection (the VPN Connection)
> >>> >>> statically give it the DNS and WINS (if you have WINS) for the LAN.
> >>> >>> Normally DHCP would give these but some VPN "Devices" won't give
> the
> >>> Clients
> >>> >>> that,...they only give the IP# and mask.
> >>> >>>
> >>> >>> It is also a good thing if the users enable the checkbox seen at
> the
> >>> >>> Ctrl-Alt-Del prompt that says "Log in with dialup connection".
> This
> >>> causes
> >>> >>> the machine to enable the VPN first,...then log the user into the
> >>> >>> machine,..which creates the same effect as logging into the Domain
> >>> locally.
> >>> >>>
> >>> >>> --
> >>> >>> Phillip Windell [MCP, MVP, CCNA]
> >>> >>> www.wandtv.com
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>
> >>>
> >>>
> >>
>
>

Tony,

No problem. Did you happen to add additional domain controllers to
your environment? If so after you connect via VPN do an nslookup with
debug on and query _ldap._tcp.YOURFQDN so if your AD domain FQDN is
Domain1.AD.int you would do an nslookup for _ldap._tcp.domain1.ad.int

Steps:
1. nslookup
2. set debug
3. _ldap._tcp.domain1.ad.int

Look through the reply from DNS and see if you get a truncated answer
near the bottom. That is what we are getting and narrowed it down to
be that DNS uses UDP until the packet size gets too big and then it
switches to TCP but the Cisco VPN client doesn't handle the switch
properly. Since the clients don't get the DCs back they can't get a
Kerberos ticket and that is where the problems start. We have a case
open with Cisco TAC and are awaiting a response on the apparent bug in
the VPN Client. When I get a resolution from them I will post it for
you.

Let me know if you are getting the truncated answer due to added DCs
like we are. It is an interesting bug which I figured a large
organization would have run into before now.

Jason



NRC Help wrote:
> Jason,
>
> Sorry for the slow reply.
>
> No, we have not reached or received a resolution. Using a VPN client other
> than the provided Cisco client is not an option, but it's the best solution
> offered.
>
> I'm more than happy to compare notes with you and maybe we can work it out
> or even get some MVPs to pick up on it. If you want, go ahead and post your
> notes in the original thread and we'll start there.
>
> Thanks,
>
> Tony
>
> "Jason Cornell" wrote:
>
> > Any Resolution to this issue? We are experiencing the exact same
> > problem.
> >
> > Thanks,
> >
> > Jason
> >
> >

Jason,

The plot thickens. The below nslookup text was taken while connected via the
Cisco VPN. At this point the client still needs to login with their UPN.
You’re theory makes sense, though I cannot find the ‘truncated’ request in
the NSLookup reply. Hence I copied the whole thing for you.

There haven’t been any DC changes since the problem started, though we have
added removed several over the course of time.

Just to clarify my setup: I work at a college within a large university. For
simply, we could picture the networks as three consecutive rings.

1. The innermost ring would be “our� (college-level) network, which contains
our domain and it’s own DNS & DHCP servers. Naturally, accessing the NetBIOS
share from this point works seamlessly. The same _ldap._tcp.fqdn results in
“Name: _ldap._tcp.fqdn�

2. The next ring out would be the university’s public network, running their
DNS & DHCP servers. Here, the clients still work properly. HOWEVER, the same
_ldap._tcp.fqdn results in “*** serv1.cl.university.dns.name can't find
_ldap._tcp.college.dns.name: Non-existent domain�

3. The third ring out is traffic *from* the VPN concentrator, still using
the same DNS servers as ring #2. This is where we fail. The ldap debug
statement returns the same value as #2.

College.dns.name = inner ring FQDN
University.dns.name = rings 2 & 3 FQDN

***Notice the double FQDN.FQDN reply in the first answer…

C:\>nslookup
Default Server: serv1.cl.university.dns.name
Address: x.x.x.x

> set debug
> _ldap._tcp.college.dns.name
Server: serv1.cl.university.dns.name
Address: x.x.x.x

------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion
avail.
questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS:
_ldap._tcp.college.dns.name.college.dns.name, type = A, class = IN
AUTHORITY RECORDS:
-> university.dns.name
ttl = 86400 (1 day)
primary name server = serv1.cl.university.dns.name
responsible mail addr = hostmaster.university.dns.name
serial = 2006073100
refresh = 900 (15 mins)
retry = 450 (7 mins 30 secs)
expire = 604800 (7 days)
default TTL = 86400 (1 day)

------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion
avail.
questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS:
_ldap._tcp.college.dns.name.university.dns.name, type = A, class = IN
AUTHORITY RECORDS:
-> university.dns.name
ttl = 86400 (1 day)
primary name server = serv1.cl.university.dns.name
responsible mail addr = hostmaster.university.dns.name
serial = 2006073100
refresh = 900 (15 mins)
retry = 450 (7 mins 30 secs)
expire = 604800 (7 days)
default TTL = 86400 (1 day)

------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 4, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion
avail.
questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS:
_ldap._tcp.college.dns.name, type = A, class = IN
AUTHORITY RECORDS:
-> university.dns.name
ttl = 86400 (1 day)
primary name server = serv1.cl.university.dns.name
responsible mail addr = hostmaster.university.dns.name
serial = 2006073100
refresh = 900 (15 mins)
retry = 450 (7 mins 30 secs)
expire = 604800 (7 days)
default TTL = 86400 (1 day)

------------
*** serv1.cl.university.dns.name can't find _ldap._tcp.college.dns.name:
Non-existent domain


"Jason Cornell" wrote:

> Tony,
>
> No problem. Did you happen to add additional domain controllers to
> your environment? If so after you connect via VPN do an nslookup with
> debug on and query _ldap._tcp.YOURFQDN so if your AD domain FQDN is
> Domain1.AD.int you would do an nslookup for _ldap._tcp.domain1.ad.int
>
> Steps:
> 1. nslookup
> 2. set debug
> 3. _ldap._tcp.domain1.ad.int
>
> Look through the reply from DNS and see if you get a truncated answer
> near the bottom. That is what we are getting and narrowed it down to
> be that DNS uses UDP until the packet size gets too big and then it
> switches to TCP but the Cisco VPN client doesn't handle the switch
> properly. Since the clients don't get the DCs back they can't get a
> Kerberos ticket and that is where the problems start. We have a case
> open with Cisco TAC and are awaiting a response on the apparent bug in
> the VPN Client. When I get a resolution from them I will post it for
> you.
>
> Let me know if you are getting the truncated answer due to added DCs
> like we are. It is an interesting bug which I figured a large
> organization would have run into before now.
>
> Jason
>
>
>
> NRC Help wrote:
> > Jason,
> >
> > Sorry for the slow reply.
> >
> > No, we have not reached or received a resolution. Using a VPN client other
> > than the provided Cisco client is not an option, but it's the best solution
> > offered.
> >
> > I'm more than happy to compare notes with you and maybe we can work it out
> > or even get some MVPs to pick up on it. If you want, go ahead and post your
> > notes in the original thread and we'll start there.
> >
> > Thanks,
> >
> > Tony
> >
> > "Jason Cornell" wrote:
> >
> > > Any Resolution to this issue? We are experiencing the exact same
> > > problem.
> > >
> > > Thanks,
> > >
> > > Jason
> > >
> > >
>
>

Hi,

First, as best practise, we recommend our customer logon on remotely via
local user account and after established a VPN session, you can access
domain share by enter domain user name and password.

Second, if you are using a Windows Server as VPN server and joined into
domain, properly, you will use domain user account to authenticate. In this
case, you don't have to enter user name and password again when you access
domain shared resource. However, you are using Cisco VPN server & Cisco VPN
client, it properly will not use domain account for authenticate(This is
sure). That's the hardest point for me to troubleshoot this issue. And that
is why I ask you to set up a Windows Server as VPN server for
troubleshooting.

I know it can be inconvenient to set up a Windows VPN server, therefore,
I'd like to suggest you take following two suggestions:

1. Log on as local user account and enter user name & password when access
shared resource.
2. Check following security policy: Windows Settings --> Security Settings
--> Local Policies --> Security Options
-->
Network access: Do not allow storage of credentials or .NET Passports for
network
Authentication

If the network access is disabled.

3. From the nslookup result, the name resolution seemed to have some
problem. You should double check if _ldap._Tcp.dns.name exists. I'd like to
know : the user account belongs to which domain? the shared resource
belongs to wihch domain? Are they in the same domain?


Best regards,

Vincent Xu
Microsoft Online Partner Support

================================================== ====
Get Secure! - www.microsoft.com/security
================================================== ====
When responding to posts, please "Reply to Group" via your newsreader so
that others
may learn and benefit from this issue.
================================================== ====
This posting is provided "AS IS" with no warranties,and confers no rights.
================================================== ====



--------------------
>>Thread-Topic: Remote accessing file shares problem
>>thread-index: Aca02I8dTpdMf+5QRy2d2GTsqJfS+Q==
>>X-WBNR-Posting-Host: 35.8.132.246
>>From: =?Utf-8?B?TlJDIEhlbHA=?= <(E-Mail Removed)>
>>References: <33E3ABD9-FAF2-40FA-8E79-(E-Mail Removed)>
<O6$(E-Mail Removed)>
<85068CF5-1ABC-4F55-9240-(E-Mail Removed)>
<BN#cKE#(E-Mail Removed)>
<31E02744-EA8C-487D-9A79-(E-Mail Removed)>
<(E-Mail Removed)>
<(E-Mail Removed) .com>
<A5D8EDB6-B053-4440-8251-(E-Mail Removed)>
<(E-Mail Removed) om>
>>Subject: Re: Remote accessing file shares problem
>>Date: Mon, 31 Jul 2006 12:36:03 -0700
>>Lines: 172
>>Message-ID: <33AF8318-2706-416C-8334-(E-Mail Removed)>
>>MIME-Version: 1.0
>>Content-Type: text/plain;
>> charset="Utf-8"
>>Content-Transfer-Encoding: 8bit
>>X-Newsreader: Microsoft CDO for Windows 2000
>>Content-Class: urn:content-classes:message
>>Importance: normal
>>Priority: normal
>>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
>>Newsgroups: microsoft.public.windows.server.networking
>>Path: TK2MSFTNGXA01.phx.gbl
>>Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.windows.server.networking:40868
>>NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250
>>X-Tomcat-NG: microsoft.public.windows.server.networking
>>
>>Jason,
>>
>>The plot thickens. The below nslookup text was taken while connected via
the
>>Cisco VPN. At this point the client still needs to login with their UPN.
>>You’re theory makes sense, though I cannot find the ‘
truncated�request in
>>the NSLookup reply. Hence I copied the whole thing for you.
>>
>>There haven’t been any DC changes since the problem started, though we
have
>>added removed several over the course of time.
>>
>>Just to clarify my setup: I work at a college within a large university.
For
>>simply, we could picture the networks as three consecutive rings.
>>
>>1. The innermost ring would be “our�(college-level) network, which
contains
>>our domain and it’s own DNS & DHCP servers. Naturally, accessing the
NetBIOS
>>share from this point works seamlessly. The same _ldap._tcp.fqdn results
in
>>“Name: _ldap._tcp.fqdn�

>>2. The next ring out would be the university’s public network, running
their
>>DNS & DHCP servers. Here, the clients still work properly. HOWEVER, the
same
>>_ldap._tcp.fqdn results in �** serv1.cl.university.dns.name can't find
>>_ldap._tcp.college.dns.name: Non-existent domain�

>>3. The third ring out is traffic *from* the VPN concentrator, still using
>>the same DNS servers as ring #2. This is where we fail. The ldap debug
>>statement returns the same value as #2.
>>
>>College.dns.name = inner ring FQDN
>>University.dns.name = rings 2 & 3 FQDN
>>
>>***Notice the double FQDN.FQDN reply in the first answer�

>>C:\>nslookup
>>Default Server: serv1.cl.university.dns.name
>>Address: x.x.x.x
>>
>>> set debug
>>> _ldap._tcp.college.dns.name
>>Server: serv1.cl.university.dns.name
>>Address: x.x.x.x
>>
>>------------
>>Got answer:
>> HEADER:
>> opcode = QUERY, id = 2, rcode = NXDOMAIN
>> header flags: response, auth. answer, want recursion, recursion
>>avail.
>> questions = 1, answers = 0, authority records = 1, additional
= 0
>>
>> QUESTIONS:
>> _ldap._tcp.college.dns.name.college.dns.name, type = A, class = IN
>> AUTHORITY RECORDS:
>> -> university.dns.name
>> ttl = 86400 (1 day)
>> primary name server = serv1.cl.university.dns.name
>> responsible mail addr = hostmaster.university.dns.name
>> serial = 2006073100
>> refresh = 900 (15 mins)
>> retry = 450 (7 mins 30 secs)
>> expire = 604800 (7 days)
>> default TTL = 86400 (1 day)
>>
>>------------
>>------------
>>Got answer:
>> HEADER:
>> opcode = QUERY, id = 3, rcode = NXDOMAIN
>> header flags: response, auth. answer, want recursion, recursion
>>avail.
>> questions = 1, answers = 0, authority records = 1, additional
= 0
>>
>> QUESTIONS:
>> _ldap._tcp.college.dns.name.university.dns.name, type = A, class
= IN
>> AUTHORITY RECORDS:
>> -> university.dns.name
>> ttl = 86400 (1 day)
>> primary name server = serv1.cl.university.dns.name
>> responsible mail addr = hostmaster.university.dns.name
>> serial = 2006073100
>> refresh = 900 (15 mins)
>> retry = 450 (7 mins 30 secs)
>> expire = 604800 (7 days)
>> default TTL = 86400 (1 day)
>>
>>------------
>>------------
>>Got answer:
>> HEADER:
>> opcode = QUERY, id = 4, rcode = NXDOMAIN
>> header flags: response, auth. answer, want recursion, recursion
>>avail.
>> questions = 1, answers = 0, authority records = 1, additional
= 0
>>
>> QUESTIONS:
>> _ldap._tcp.college.dns.name, type = A, class = IN
>> AUTHORITY RECORDS:
>> -> university.dns.name
>> ttl = 86400 (1 day)
>> primary name server = serv1.cl.university.dns.name
>> responsible mail addr = hostmaster.university.dns.name
>> serial = 2006073100
>> refresh = 900 (15 mins)
>> retry = 450 (7 mins 30 secs)
>> expire = 604800 (7 days)
>> default TTL = 86400 (1 day)
>>
>>------------
>>*** serv1.cl.university.dns.name can't find _ldap._tcp.college.dns.name:
>>Non-existent domain
>>
>>
>>"Jason Cornell" wrote:
>>
>>> Tony,
>>>
>>> No problem. Did you happen to add additional domain controllers to
>>> your environment? If so after you connect via VPN do an nslookup with
>>> debug on and query _ldap._tcp.YOURFQDN so if your AD domain FQDN is
>>> Domain1.AD.int you would do an nslookup for _ldap._tcp.domain1.ad.int
>>>
>>> Steps:
>>> 1. nslookup
>>> 2. set debug
>>> 3. _ldap._tcp.domain1.ad.int
>>>
>>> Look through the reply from DNS and see if you get a truncated answer
>>> near the bottom. That is what we are getting and narrowed it down to
>>> be that DNS uses UDP until the packet size gets too big and then it
>>> switches to TCP but the Cisco VPN client doesn't handle the switch
>>> properly. Since the clients don't get the DCs back they can't get a
>>> Kerberos ticket and that is where the problems start. We have a case
>>> open with Cisco TAC and are awaiting a response on the apparent bug in
>>> the VPN Client. When I get a resolution from them I will post it for
>>> you.
>>>
>>> Let me know if you are getting the truncated answer due to added DCs
>>> like we are. It is an interesting bug which I figured a large
>>> organization would have run into before now.
>>>
>>> Jason
>>>
>>>
>>>
>>> NRC Help wrote:
>>> > Jason,
>>> >
>>> > Sorry for the slow reply.
>>> >
>>> > No, we have not reached or received a resolution. Using a VPN client
other
>>> > than the provided Cisco client is not an option, but it's the best
solution
>>> > offered.
>>> >
>>> > I'm more than happy to compare notes with you and maybe we can work
it out
>>> > or even get some MVPs to pick up on it. If you want, go ahead and
post your
>>> > notes in the original thread and we'll start there.
>>> >
>>> > Thanks,
>>> >
>>> > Tony
>>> >
>>> > "Jason Cornell" wrote:
>>> >
>>> > > Any Resolution to this issue? We are experiencing the exact same
>>> > > problem.
>>> > >
>>> > > Thanks,
>>> > >
>>> > > Jason
>>> > >
>>> > >
>>>
>>>
>>

Vincent,

The problem isn’t that it’s inconvenient to setup a Windows VPN server, but
instead that you’re pushing the Windows VPN server as the only solution.
While I don’t feel that having users log on with a local user account, then
the VPN, and then to the domain is a desirable configuration, I also don’t
think the MS VPN server is the only way to accomplish the goal. Even so,
could you kindly provide a link to a MS document citing the above as a best
practice? Maybe I’ll be enlightened.

#2 – The cited Network Access policy is not configured.

#3 – Yes – the user account, workstation, and member server all belong to
the same domain.

Personally, I think it would be most fruitful to work towards understanding
the Cisco VPN issue as it pertains to Windows Domain resources. If you do not
have an interest in working towards that goal, then so be it. Jason has taken
the initiative, and I will contribute whatever information I can to help him.

Jason -

I know you have a TAC case open, but do you happen to have a thread going in
the Cisco support forums too? I'd like thread information if you do - I can
post over there as well.