Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 301
  • Last Modified:

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

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
askrabbit
Asked:
askrabbit
  • 12
  • 11
  • +3
1 Solution
 
KimputerCommented:
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
 
askrabbitAuthor Commented:
On the workstation, logged in as user1, there are no stored credentials.
0
 
JohnBusiness Consultant (Owner)Commented:
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
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

 
askrabbitAuthor Commented:
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
 
JohnBusiness Consultant (Owner)Commented:
So does the use of DOMAIN qualifier answer your question?  It looks like it does.  I use that form myself as well.
0
 
askrabbitAuthor Commented:
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
 
JohnBusiness Consultant (Owner)Commented:
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
 
askrabbitAuthor Commented:
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
 
JohnBusiness Consultant (Owner)Commented:
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
 
Hypercat (Deb)Commented:
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
 
askrabbitAuthor Commented:
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
 
JohnBusiness Consultant (Owner)Commented:
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
 
askrabbitAuthor Commented:
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
 
JohnBusiness Consultant (Owner)Commented:
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
 
askrabbitAuthor Commented:
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
 
JohnBusiness Consultant (Owner)Commented:
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
 
askrabbitAuthor Commented:
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
 
JohnBusiness Consultant (Owner)Commented:
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
 
askrabbitAuthor Commented:
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
 
JohnBusiness Consultant (Owner)Commented:
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
 
askrabbitAuthor Commented:
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
 
Feroz AhmedSenior Network EngineerCommented:
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
 
askrabbitAuthor Commented:
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
 
LeeTutorretiredCommented:
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
 
JohnBusiness Consultant (Owner)Commented:
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
 
JohnBusiness Consultant (Owner)Commented:
Thank you for following up.
0
 
askrabbitAuthor Commented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 12
  • 11
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now