corkyduke
asked on
Mapping a drive to a share on a Windows 2003 Server over a VPN site to site connection
Scenario:
A Windows XP Pro PC in City1 (which is part of a NT 4 domain) is trying to map a network share across a VPN tunnel (dedicated site to site) to a Windows 2003 Server in City2 which is not part of a domain, is a standalone server, and there is a workgroup in operation there.
The City1 XP PC can successfully map shares through the VPN tunnel to an XP Pro PC in City2 that is on the same network as the 2003 Server.
The share and NTFS permissions on the 2003 Server shares have been double checked.
The 2003 Server (with IP 192.168.168.xx) successfully returns a ping from across the VPN tunnel from the XP Pro machine in City1.
Other PCs on the City1 network can map shares on the Ottawa 2003 Server just fine.
The command used to attempt to map the share on the 2003 Server is as follows:
Net use f: \\192.168.168.xx\shared
And the result is a System 53 error; network path does not exist.
When looking at the Network Neighborhood from an XP machine in City 1, City2's workgroup can be seen. If double clicked, it shows the PC's in the workgroup, and it is possible to look at the shares on CIty2 XP machines, but not the 2003 server. If you double click on the 2003 server, it gives an error indicating that permissions due not exist and to contact the administrator.
Employing -- Net use f: \\192.168.168.xx\shared /user:2003_Server_name_her
So the I guess the question is, what is different from a security standpoint for a 2003 Server vs an XP machine when serving up shares to a machine that is in a different domain. What needs to be done to allow the mapping of the drive?
A Windows XP Pro PC in City1 (which is part of a NT 4 domain) is trying to map a network share across a VPN tunnel (dedicated site to site) to a Windows 2003 Server in City2 which is not part of a domain, is a standalone server, and there is a workgroup in operation there.
The City1 XP PC can successfully map shares through the VPN tunnel to an XP Pro PC in City2 that is on the same network as the 2003 Server.
The share and NTFS permissions on the 2003 Server shares have been double checked.
The 2003 Server (with IP 192.168.168.xx) successfully returns a ping from across the VPN tunnel from the XP Pro machine in City1.
Other PCs on the City1 network can map shares on the Ottawa 2003 Server just fine.
The command used to attempt to map the share on the 2003 Server is as follows:
Net use f: \\192.168.168.xx\shared
And the result is a System 53 error; network path does not exist.
When looking at the Network Neighborhood from an XP machine in City 1, City2's workgroup can be seen. If double clicked, it shows the PC's in the workgroup, and it is possible to look at the shares on CIty2 XP machines, but not the 2003 server. If you double click on the 2003 server, it gives an error indicating that permissions due not exist and to contact the administrator.
Employing -- Net use f: \\192.168.168.xx\shared /user:2003_Server_name_her
So the I guess the question is, what is different from a security standpoint for a 2003 Server vs an XP machine when serving up shares to a machine that is in a different domain. What needs to be done to allow the mapping of the drive?
What are the permissions that "everyone has on the share and What are the NTFS permissions".Did you try giving anonymous user access on the shared folder
>>> net use f: \\192.168.168.xx\shared <<<
It seems that the administrative shares are not present on the windows 2003 server
To verify whether a computer is affected by this issue, follow these steps:
1. Examine the AutoShareServer and AutoShareWks registry values to make sure that they are not set to 0:
a. Click Start, click Run, type regedit, and then press ENTER.
b. Locate and then click the following registry sub-key: HKEY_LOCAL_MACHINE\System\
c. If the AutoShareServer and AutoShareWks DWORD values in the LanmanServer\Parameters sub-key are configured with a value data of 0, change that value to 1.
Note If these values do not exist, you do not have to create them because the default behavior is to automatically create the administrative shares.
d. Quit Registry Editor.
2. Restart the computer. Typically, computers that are running Windows Server 2003, Windows XP, Windows 2000, or Windows NT 4.0 automatically create the administrative shares during startup.
3. After the computer restarts, verify that the administrative shares are active. To examine the shares, use the net share command. To do this, follow these steps: a. Click Start, click Run, type cmd, and then press ENTER.
b. At the command prompt, type net share, and then press ENTER.
c. Look for the Admin$, C$, and IPC$ administrative shares in the list of shares.
It seems that the administrative shares are not present on the windows 2003 server
To verify whether a computer is affected by this issue, follow these steps:
1. Examine the AutoShareServer and AutoShareWks registry values to make sure that they are not set to 0:
a. Click Start, click Run, type regedit, and then press ENTER.
b. Locate and then click the following registry sub-key: HKEY_LOCAL_MACHINE\System\
c. If the AutoShareServer and AutoShareWks DWORD values in the LanmanServer\Parameters sub-key are configured with a value data of 0, change that value to 1.
Note If these values do not exist, you do not have to create them because the default behavior is to automatically create the administrative shares.
d. Quit Registry Editor.
2. Restart the computer. Typically, computers that are running Windows Server 2003, Windows XP, Windows 2000, or Windows NT 4.0 automatically create the administrative shares during startup.
3. After the computer restarts, verify that the administrative shares are active. To examine the shares, use the net share command. To do this, follow these steps: a. Click Start, click Run, type cmd, and then press ENTER.
b. At the command prompt, type net share, and then press ENTER.
c. Look for the Admin$, C$, and IPC$ administrative shares in the list of shares.
ASKER
The same results happen when trying to map to a share that has the Everyone group with full access. Admin shares have been verified as being present on the computer, although this should not be relevant. Again, users in workgroup in City2 can map a the share without problems.
ASKER
As an update, a Windows 98 machine in City 1 trying to map the share also gets the same results as the XP machine.
ASKER
Upon further testing, an XP laptop that is a member a totally separate and unrelated domain is attached to the city2 workgroup LAN and logged in with cached credentials, it too cannot access the share on the City 2 server. Even if you log on to the laptop locally and try to access the share you cannot and receive the same error of path not found. It would seem that the workgroup standalone sever won't accept a connection to a share from any PC that is a member of domain and won't even prompt for credentials. This is unexpected behaviour unless I'm missing something. Help?
ASKER
Well, after much grief and troubleshooting, it is now working. It turns out that Windows Firewall was running on the server that was preventing connections from the other side of the VPN tunnel. When shut off, share mapping then works.
Glad to see it work.
You can get your points back dunno how...
You can get your points back dunno how...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.