Remote accessing file shares problem

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" <NRC_Support DeleteThis @nospam.postalias> wrote in message
> news:33E3ABD9-FAF2-40FA-8E79-C9A771968E8D@microsoft.com...
> > 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
>
>
>
 >> Stay informed about: Remote accessing file shares problem 

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=?= <NRC_Support.DeleteThis@nospam.postalias>
>>References: <33E3ABD9-FAF2-40FA-8E79-C9A771968E8D.DeleteThis@microsoft.com>
<O6$kVQgoGHA.4240@TK2MSFTNGP05.phx.gbl>
>>Subject: Re: Remote accessing file shares problem
>>Date: Fri, 7 Jul 2006 16:21:01 -0700
>>Lines: 47
>>Message-ID: <85068CF5-1ABC-4F55-9240-32AACC70F75E.DeleteThis@microsoft.com>
>>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" <NRC_Support.DeleteThis@nospam.postalias> wrote in message
>>> news:33E3ABD9-FAF2-40FA-8E79-C9A771968E8D@microsoft.com...
>>> > 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
>>>
>>>
>>>
>>
 >> Stay informed about: Remote accessing file shares problem 

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=?= <NRC_Support.RemoveThis@nospam.postalias>
> >>References: <33E3ABD9-FAF2-40FA-8E79-C9A771968E8D.RemoveThis@microsoft.com>
> <O6$kVQgoGHA.4240@TK2MSFTNGP05.phx.gbl>
> >>Subject: Re: Remote accessing file shares problem
> >>Date: Fri, 7 Jul 2006 16:21:01 -0700
> >>Lines: 47
> >>Message-ID: <85068CF5-1ABC-4F55-9240-32AACC70F75E.RemoveThis@microsoft.com>
> >>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" <NRC_Support.RemoveThis@nospam.postalias> wrote in message
> >>> news:33E3ABD9-FAF2-40FA-8E79-C9A771968E8D@microsoft.com...
> >>> > 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
> >>>
> >>>
> >>>
> >>
>
>
 >> Stay informed about: Remote accessing file shares problem 

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=?= <NRC_Support RemoveThis @nospam.postalias>
>>References: <33E3ABD9-FAF2-40FA-8E79-C9A771968E8D RemoveThis @microsoft.com>
<O6$kVQgoGHA.4240@TK2MSFTNGP05.phx.gbl>
<85068CF5-1ABC-4F55-9240-32AACC70F75E RemoveThis @microsoft.com>
<BN#cKE#oGHA.6028@TK2MSFTNGXA01.phx.gbl>
>>Subject: Re: Remote accessing file shares problem
>>Date: Mon, 10 Jul 2006 12:08:01 -0700
>>Lines: 148
>>Message-ID: <31E02744-EA8C-487D-9A79-215F640002B9 RemoveThis @microsoft.com>
>>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=?= <NRC_Support RemoveThis @nospam.postalias>
>>> >>References: <33E3ABD9-FAF2-40FA-8E79-C9A771968E8D RemoveThis @microsoft.com>
>>> <O6$kVQgoGHA.4240@TK2MSFTNGP05.phx.gbl>
>>> >>Subject: Re: Remote accessing file shares problem
>>> >>Date: Fri, 7 Jul 2006 16:21:01 -0700
>>> >>Lines: 47
>>> >>Message-ID: <85068CF5-1ABC-4F55-9240-32AACC70F75E RemoveThis @microsoft.com>
>>> >>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" <NRC_Support RemoveThis @nospam.postalias> wrote in message
>>> >>> news:33E3ABD9-FAF2-40FA-8E79-C9A771968E8D@microsoft.com...
>>> >>> > 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
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>>
>>>
>>
 >> Stay informed about: Remote accessing file shares problem 

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

Thanks,

Jason
 >> Stay informed about: Remote accessing file shares problem 

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
>
>
 >> Stay informed about: Remote accessing file shares problem 

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=?= <NRC_Support.TakeThisOut@nospam.postalias>
> >>References: <33E3ABD9-FAF2-40FA-8E79-C9A771968E8D.TakeThisOut@microsoft.com>
> <O6$kVQgoGHA.4240@TK2MSFTNGP05.phx.gbl>
> <85068CF5-1ABC-4F55-9240-32AACC70F75E.TakeThisOut@microsoft.com>
> <BN#cKE#oGHA.6028@TK2MSFTNGXA01.phx.gbl>
> >>Subject: Re: Remote accessing file shares problem
> >>Date: Mon, 10 Jul 2006 12:08:01 -0700
> >>Lines: 148
> >>Message-ID: <31E02744-EA8C-487D-9A79-215F640002B9.TakeThisOut@microsoft.com>
> >>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=?= <NRC_Support.TakeThisOut@nospam.postalias>
> >>> >>References: <33E3ABD9-FAF2-40FA-8E79-C9A771968E8D.TakeThisOut@microsoft.com>
> >>> <O6$kVQgoGHA.4240@TK2MSFTNGP05.phx.gbl>
> >>> >>Subject: Re: Remote accessing file shares problem
> >>> >>Date: Fri, 7 Jul 2006 16:21:01 -0700
> >>> >>Lines: 47
> >>> >>Message-ID: <85068CF5-1ABC-4F55-9240-32AACC70F75E.TakeThisOut@microsoft.com>
> >>> >>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" <NRC_Support.TakeThisOut@nospam.postalias> wrote in message
> >>> >>> news:33E3ABD9-FAF2-40FA-8E79-C9A771968E8D@microsoft.com...
> >>> >>> > 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
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>
> >>>
> >>>
> >>
>
>
 >> Stay informed about: Remote accessing file shares problem 

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
> >
> >
 >> Stay informed about: Remote accessing file shares problem 

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
> > >
> > >
>
>
 >> Stay informed about: Remote accessing file shares problem 

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=?= <NRC_Support RemoveThis @nospam.postalias>
>>References: <33E3ABD9-FAF2-40FA-8E79-C9A771968E8D RemoveThis @microsoft.com>
<O6$kVQgoGHA.4240@TK2MSFTNGP05.phx.gbl>
<85068CF5-1ABC-4F55-9240-32AACC70F75E RemoveThis @microsoft.com>
<BN#cKE#oGHA.6028@TK2MSFTNGXA01.phx.gbl>
<31E02744-EA8C-487D-9A79-215F640002B9 RemoveThis @microsoft.com>
<E6DSekLpGHA.2028 RemoveThis @TK2MSFTNGXA01.phx.gbl>
<1153947843.981000.269400 RemoveThis @h48g2000cwc.googlegroups.com>
<A5D8EDB6-B053-4440-8251-477E34035356 RemoveThis @microsoft.com>
<1154356608.204796.41550 RemoveThis @i3g2000cwc.googlegroups.com>
>>Subject: Re: Remote accessing file shares problem
>>Date: Mon, 31 Jul 2006 12:36:03 -0700
>>Lines: 172
>>Message-ID: <33AF8318-2706-416C-8334-55E1FBCA04F4 RemoveThis @microsoft.com>
>>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
>>>
>>>