Solved

Weird connectivity issue connecting from remote Win7 via VPN to Win2008R2 shares

Posted on 2015-01-21
29
232 Views
Last Modified: 2015-03-02
Problem: A remote workstation connects to the main site via VPN, but an Explorer window to \\server2 cannot be launched. However, an Explorer window to \\server1 is launched OK.

The environment and further details are as follows.

Workstation:
Win 7 Pro, member of the Windows domain, but physically remote to the main office LAN; connected by VPN

Domain:
\\server1 o/s - Windows 2003; domain controller; DNS server; firewall off
\\server2 o/s - Windows 2008R2; domain controller; DNS server; firewall off
functional level - Windows 2003
single AD forest, single AD domain

VPN:
LAN side - Cisco Meraki, not integrated into AD
client side - Win 7 built-in VPN, i.e. not a Cisco VPN client app
DHCP IP settings - DNS is set to server2
VPN connection settings - "DNS suffix for this connection" is set to internal.clientdomain.com
VPN username/passowrd is saved and the connection is available for all users

Troubleshooting steps so far:
- log into workstation with user1
- connect to site via VPN
- ping server1 - resolves correctly to server's IP address, responds with server's correct FQDN, ping works OK
- ping server2 - resolves correctly to server's IP address, responds with server's correct FQDN, ping works OK
- run \\server1 - launches Explorer window with list of available shares
- run \\server1\netlogon - launches Explorer window showing contents of the share
- run \\server2 - error: "Windows cannot access \\server2 - you do not have permission to access \\server2"
- run \\server2\netlogon - error: "An extended error has occurred"
- run \\server2.internal.clientdomain.com - launches Explorer window with list of available shares (therefore, the permissions appear to be OK)
- run \\server2.internal.clientdomain.com\netlogon - launches Explorer window showing contents of the share
- Explorer windows are launched OK to other Win2003 member servers plus workstations

- with the VPN connection running, switch user and log in with user2
- run \\server2 - launches Explorer window with list of available shares !!! (i.e. without having to append the DNS suffix to the name)

For a remote workstation not joined to the Windows domain:
- connect to site via VPN
- run \\server2 - user is prompted for credentials, once these are entered, Explorer window appears as expected

Any help with troubleshooting this further would be greatly appreciated!!
0
Comment
Question by:askrabbit
  • 12
  • 11
  • +3
29 Comments
 
LVL 35

Expert Comment

by:Kimputer
ID: 40562032
For user1, are there any saved credentials on server2 (go to control panel, users, user1, then check for the item Manage your credentials, click Windows credentials, see if anything is related to server2 (and delete these entries).
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40562067
On the workstation, logged in as user1, there are no stored credentials.
0
 
LVL 90

Accepted Solution

by:
John Hurst earned 500 total points
ID: 40575057
Can you map the Server2 share as follows ?

NET USE X: \\Servername\folder /user:DOMAIN\username

OR

NET USE X: \\IP_Address_of_Server\folder /user:DOMAIN\username
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40575099
I have performed the following tests:

net use x: \\server2\share
- System error 2221 has occurred. The user name could not be found.

net use x: \\server2.internal.clientdomain.com\share
- connects immediately

net use x: \\server2\share /user:domain\username password
- connects immediately

net use x: \\ipaddress\share
- prompts for user/pwd then connects OK
0
 
LVL 90

Expert Comment

by:John Hurst
ID: 40575105
So does the use of DOMAIN qualifier answer your question?  It looks like it does.  I use that form myself as well.
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40575153
Not entirely...

If the VPN is set up "for all users" by user1, then user2 logs into the remote workstation (using the Windows Switch User facility) - using net use x: \\server2\share connects immediately within user2's session.

Because the error for the first test above indicated a problem with a user name, perhaps it is worth mentioning that the VPN uses a completely different set of credentials to either user1 or user2. At face value, it seems that the correct set of credentials is being passed to \\server2.internal.clientdomain.com\share, but not to \\server2\share.

The other thing to mention is that connecting via VPN and mapping drive letters using the simple netbios servername, rather than the FQDN, used to work fine prior to an infrastructure change. The old Cisco 2851 was replaced with a Meraki MX80.

In addition to the above, the other very strange thing is that the net use mapping works fine to Windows 2003 Servers, whether domain controllers or not, and the mapping doesn't work to the Windows 2008R2 Server (a dc).
0
 
LVL 90

Expert Comment

by:John Hurst
ID: 40575175
With respect to the second question, I have clients with Server 2003 and Servers 2008, 2012. Server 2003 is going out of commission. But login is different for Server 2003 than the other two and I use DOMAIN because it works and, in fact, will work anywhere.

I am not familiar with your VPN setup. I use simple IPsec with a Juniper firewall. The VPN set up like this has zero bearing on drive mapping. If your VPN gets in the way, you would have to take that into account when mapping.
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40575326
I take your points about 2003 going end-of-life and the difference between 2003 and 2008/2012. However, I do not understand why:
a) it worked before the infrastructure change - this may have had an effect, as some traffic that was allowed before may now no longer be allowed;
b) it works now for user2 (when the VPN has already been established under a different user's session);
c) it works without passing explicit user credentials when using the FQDN in the share name.

I would prefer if I could get to the bottom of what is going on, rather than face the prospect of changing all login and other scripts as well as amending server/share paths in linked Office documents, AutoCAD files, etc, etc...
0
 
LVL 90

Expert Comment

by:John Hurst
ID: 40575365
I am not sure what next. Systems change and newer systems work differently from older systems. So I think you do need to change logins - that is what I do.
0
 
LVL 38

Expert Comment

by:Hypercat (Deb)
ID: 40575600
It's certainly odd, but seems to have something to do with the way Win2003 resolves names and credentials vs. Win2008.  Do you have WINS running on your Win2003 DC? Conversely, do you have NetBIOS over TCP/IP enabled on your Win2008 DC?
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40586678
Apologies for my absence - unfortunately I was rather unwell over the last several days. Anyway, back in the saddle now...

I also thought that it must be something to do with the different between Win2k3 and Win2k8. However, I don't think that WINS is significant, as WINS would only figure if the Win2k8 server could not be resolved. If "net use" is specified passing user credentials by way of a "/user" argument, the Win2k8 share connects immediately with no error.

Further to my comments above, we have now performed a Wireshark packet capture and found the following:

- net use x: \\server2k3\share
There is a packet exchange via SMB; the share is connected straightaway.

- net use x: \\server2k8\share
There is an initial exchange via SMB2; then eventually there is then a response from the server via WebDAV; then an error.
Upon close inspection, after the initial SMB2 exchange, there is also an exchange via Kerberos indicating that the user context being passed is that of the VPN connection, not the domain Windows user! It is little wonder that the share does not get mapped, as the VPN user is not a domain account - just an account to authenticate against the VPN endpoint.

- net use x: \\server2k8\share /user:windowsuser password
There is a packet exchange via SMB2; the share is connected straightaway.

So, is this a bug of some sort?? It seems that host name resolution, etc is working fine. It is the user context from client to server2k8 which is seemingly not being passed correctly.

I would welcome your further thoughts.
0
 
LVL 90

Expert Comment

by:John Hurst
ID: 40586698
So, is this a bug of some sort?? <--- No, I do not think so (unless your systems are different than mine in a way I don't know). I think it is just modernization in systems. I see the same behaviour (need for DOMAIN\username) in our newer systems, but not old ones.
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40586724
What I should have added is this: in addition to the behaviour for which we ran the packet capture, please note that if the VPN is established within a second, parallel user session on the remote workstation, the user can then connect to the win2k8 share without having to explicitly state "/user etc etc".

So, not specifying the user works fine:
- inside the network
- in a remote network which is connected via site-to-site vpn
- in a remote workstation where the vpn is established in a separate user session
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 90

Expert Comment

by:John Hurst
ID: 40586759
So then the first VPN setup was different somehow.

My IPsec VPN is transparent to logging on to a server, so I do not see VPN issues.

I have also drifted to always explicitly naming the DOMAIN because the result is that it works everywhere with no issues.
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40586818
The VPN setup is identical for user1 and user2. When the vpn connection was created, it was made available to everyone: "allow other people to use this connection".

I feel that there is a problem in the way that the client sends the user context to the 2k8 server. However, if this isn't fixable, then I am certainly in the market for a workaround...

John - when you say you "explicitly name the domain", what do you mean? You surely don't pass user passwords as part of 'net use' commands in scripts, do you?
0
 
LVL 90

Expert Comment

by:John Hurst
ID: 40586970
First, my machine is NOT domain-connected. I am a consultant. For users on-domain, we use scripts and the scripts ensure the proper mapping of files. User are attached to a domain, so no issue.

For me, I use the form:

NET USE Z: \\serveraddress\foldershare user:DOMAIN\username  [password]

On my machine (secured), I use passwords.
On client machines, there is no need. They have access because of their membership in AD and the scripts map folders they have access to.
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40587094
OK, now I understand your setup.

For us, the following is true:
- For a machine which is a standalone member of a workgroup - no issue. After the VPN is established, a username/password is needed to establish any connection to a share on any domain server. This all works as expected.

- For a machine which has been joined to the domain, but is now remote to the domain (a laptop, say) - this is where we have the issue. The machine has a computer account in AD; the user has a user account in AD and logs in using cached credentials. If the machine is physically on the main office LAN - no problems, everything works OK. If the machine is remote and connected via vpn, there is an issue solely with connecting to a win2k8 share.

Apologies if I did not make it clear enough that we do not have a problem with machines which are not domain members. The problem only exists for a remote domain member computer.

Any further thoughts?
0
 
LVL 90

Expert Comment

by:John Hurst
ID: 40587124
To your last post domain qualifier will solve your issue and it works. And it always works everywhere which is why I use it.
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40588357
I've now performed a further test:
- log in as domain user onto remote machine using cached credentials
- connect vpn to main site (using completely different credetials)
- net use \\server2k8\share - gives error "unknown user"
- net use \\server2k8\share /user:domainuser - this connects OK!!

Interestingly, I typed the last "net use", with the user flag WITHOUT a trailing asterisk or password. No password was prompted for - the session picked up the cached credentials of the logged in user!

I may be able to work with this. However, it still leaves with me a the problem that no login scripts, etc will run automatically, as there is no access to the win2k8 server until the first connection is established. A bit of chicken and egg!

So, the question boils down to this:
In the context of a remote domain-connected workstation, how can I tell Windows 7 to automatically use the cached credentials of the logged in user when it attempts to connect to a Win2008 share using SMB2, rather than the credentials of the VPN connection?
0
 
LVL 90

Expert Comment

by:John Hurst
ID: 40588388
I cannot help further.  I moved on and use new concepts (DOMAIN\user) and they work everywhere. I do not use old concepts.

Your question was that you could not connect from remote VPN and I provided a working solution for that.
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40588444
John - thank you for your help. Using "net use" exposed the underlying nature of the problem, as a much more specific error message was given. From this, I then gained more insight through a packet trace. However, using the "/user" flag is only a partial solution for me. I can't help thinking that there is either a bug in the client o/s or a way of telling the client o/s to use the already cached domain user's credentials.

I asked for "help with troubleshooting this further" and so I am happy to award points. Also, I would be happy to pose another Experts Exchange question with my more specific info...

...unless anyone has any further thoughts?
0
 
LVL 5

Expert Comment

by:Feroz Ahmed
ID: 40594268
Hi,

As you are able to ping to Server2 from your end and able to view shares but not able to access shares such as Netlogon.Login to server2 and goto shares and right click on particular share Netlogon and goto properties goto Effective permissions and give full permissions and then try from workstation through run command \\server\netlogon you can access the share without any difficulty.Follow the same scenario for all shares goto Security settings and provide effective permissions and take full access.
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40594313
Hi sm feroz

Thank you for your post, but I think you may be missing the point here. I do not think that it is a question of wrong or inadequate permissions on the share. What is happening is that the wrong credentials are being passed to the w2k8 server by the remote workstation. If I specify the fqdn name in a "net use" command, or if I use the "/user" flag, the share is connected OK, with the appropriate level of access. The issue is that the credentials associated with the VPN are being passed to the w2k8 server, rather than the credentials of the underlying logged in Windows domain user. It seems that using the fqdn or explicitly specifying the user makes the connection work.
0
 
LVL 59

Expert Comment

by:LeeTutor
ID: 40638357
I've requested that this question be deleted for the following reason:

The question has either no comments or not enough useful information to be called an "answer".
0
 
LVL 90

Expert Comment

by:John Hurst
ID: 40638358
I asked if you used a proper connectivity method (NET USE) and you said "net use x: \\server2\share /user:domain\username password  - connects immediately"

So I have answered this question correctly. The older connection methodology you are trying to use in new systems does not apply well. My method works on all servers and standard VPN connections forward from Server 2003 to Server 2012 (I have done this).

My answer http:#a40575057 is the solution here.
0
 
LVL 90

Expert Comment

by:John Hurst
ID: 40638738
Thank you for following up.
0
 
LVL 2

Author Comment

by:askrabbit
ID: 40639255
To LeeTutor: I do not understand why this question would be deleted or deemed 'abandoned'. John gave me good help and his suggestion of the /user:DOMAIN qualifier set me on the right track for further troubleshooting. The points are assigned to John and quite rightly so.
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

Suggested Solutions

Join Greg Farro and Ethan Banks from Packet Pushers (http://packetpushers.net/podcast/podcasts/pq-show-93-smart-network-monitoring-paessler-sponsored/) and Greg Ross from Paessler (https://www.paessler.com/prtg) for a discussion about smart network …
OfficeMate Freezes on login or does not load after login credentials are input.
This Micro Tutorial will teach you how to the overview of Microsoft Security Essentials. This is a free anti-virus software that guards your PC against viruses, spyware, worms, and other malicious software. This will be demonstrated using Windows…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now