Remote accessing file shares problem

Discussion in 'Server Networking' started by NRC Help, Jul 7, 2006.

  1. NRC Help

    NRC Help Guest

    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 “[email protected]_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 “[email protected]†_does_ is very curious.
     
    NRC Help, Jul 7, 2006
    #1
    1. Advertisements

  2. 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, Jul 7, 2006
    #2
    1. Advertisements

  3. NRC Help

    NRC Help Guest

    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.
     
    NRC Help, Jul 8, 2006
    #3
  4. Ahhh....Sorry. I afraid you couldn't even drag me "kicking & screaming" to
    use the Cisco VPN Client". I don't think I can help you with that. You'll
    probably have to turn to Cisco Product Support,...although there may be some
    here that have dealt with it. Hang around ans see what replies you get.

    --
    Phillip Windell [MCP, MVP, CCNA]
    www.wandtv.com
    -----------------------------------------------------
    Understanding the ISA 2004 Access Rule Processing
    http://www.isaserver.org/articles/ISA2004_AccessRules.html

    Troubleshooting Client Authentication on Access Rules in ISA Server 2004
    http://download.microsoft.com/download/9/1/8/918ed2d3-71d0-40ed-8e6d-fd6eeb6cfa07/ts_rules.doc

    Microsoft Internet Security & Acceleration Server: Guidance
    http://www.microsoft.com/isaserver/techinfo/Guidance/2004.asp
    http://www.microsoft.com/isaserver/techinfo/Guidance/2000.asp

    Microsoft Internet Security & Acceleration Server: Partners
    http://www.microsoft.com/isaserver/partners/default.asp

    Deployment Guidelines for ISA Server 2004 Enterprise Edition
    http://www.microsoft.com/technet/prodtechnol/isa/2004/deploy/dgisaserver.mspx
    -----------------------------------------------------
     
    Phillip Windell, Jul 10, 2006
    #4
  5. 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.
    ======================================================



    --------------------
     
    Vincent Xu [MSFT], Jul 10, 2006
    #5
  6. NRC Help

    NRC Help Guest

    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.
     
    NRC Help, Jul 10, 2006
    #6
  7. 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.
    ======================================================



    --------------------
     
    Vincent Xu [MSFT], Jul 11, 2006
    #7
  8. NRC Help

    NRC Help Guest

    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
     
    NRC Help, Jul 31, 2006
    #8
  9. NRC Help

    NRC Help Guest

    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.
    third-party ? (Cisco?)

    1A: Cisco

    2A: No.
    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.

    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.
    2A: I don't understand the solution here. Can you extrapolate?
    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
     
    NRC Help, Jul 31, 2006
    #9
  10. NRC Help

    NRC Help Guest

    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
    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)
     
    NRC Help, Jul 31, 2006
    #10
  11. 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.
    ======================================================



    --------------------
     
    Vincent Xu [MSFT], Aug 1, 2006
    #11
  12. NRC Help

    NRC Help Guest

    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.
     
    NRC Help, Aug 1, 2006
    #12
  13. Hi NRC,

    Honestly, I have interests to dig out the root cause but it appears to be
    related with Cisco device. I know that's inconvenience for you to build a
    windows vpn server but please understand, only in this case I have the
    ability to build a test enviroment for your issue. If you are using Cisco
    device, I'm unable to get the test enviroment. I agree with Jason that it
    could be a good idea to turn to Cisco for assistance. I'll appreciate if
    you can post back the results.

    Have a good day.


    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.
    ======================================================



    --------------------
     
    Vincent Xu [MSFT], Aug 2, 2006
    #13
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.