Topic: Cannot map drives or connect to Ibay

[alext]

Hi Stefano,

Re. your suggestions;

I guessed that the SME domain may take some time to be "discovered" by Windows but having left the VPN connection up for some considerable time it never showed up.
I assume that by suggesting that I define the SME server as DNS for the VPN connection you meant that I should modify the DNS address in the TCP/IP item in the Networking tab of the VPN profile. This I have done,  (set to the internal IP address of the SME server - 192.168.100.1), but it makes no difference - still no domain discovered.

I put a pause at the end of the SME login script then, after establishing the VPN tunnel, I attempted to get a directory listing of the netlogon share of the SME server by using the DOS command;

   dir \\192.168.100.1\netlogon

The result was:

   Access is denied.

As an integrity test of the command I also tried;

   dir \\192.168.100.1\NETLOGON

The result was:

   The network path was not found.

Which seems to suggest that netlogon is a share but NETLOGON is not and that somehow my VPN connection is not getting the correct access rights, (if any...). In fact I am wondering if the domain login is happening at all: I am being authenticated so that part of the VPN connection is working but it seems that the server is ignoring my domain login request.
 
In all cases (VPN connection and drive mapping), I am using IP addresses.

Cheers,
Alex

[janet]

alext

Have you actually joined the computer to the domain before you try to do a domain login via VPN ?

A domain is a trusted network of computers, and at some point in time you have to setup that trust ie join the domain. Only then are you allowed to login to a domain.

Typically a notebook would have joined the domain when connected to the local network (LAN) where the SME Domain controller is. Then that notebook goes off site to a remote location. The user logins in to the notebook workstation using the normal domain login screen, but as there is no domain controller (DC) available to authenticate against, Windows uses the cached memory. Then when you establish the VPN Domain login connection, the correct trusted credentials are presented to the "now remote" Domain Controller, and you are then granted appropriate access rights to the domain.

If you are using a standalone PC that has not yet joined the domain, then you need to initially connect using a normal "non domain" VPN login screen, and then go through the process of joining that PC  to the domain (using the admin user and password etc etc).
Then you disconnect the VPN connection and login again using the VPN Domain login option. the domain should then be found and connected to, as your PC is now a trusted member of the domain.
It will still take many minutes to discover the domain depending on Internet connection speed, but remember VPN is very slow anyway, compared to the actual Internet connection speed.

Do a google search on VPN Domain login issues, there are many results.

[axessit]

Am asumming here that the remote PC's workgroup is the same as the SME's workgroup? The workstation will only initially browse it's own workgroup and not see the SME if it's workgroup (domain) is different.

[alext]

Mary,

Sorry for the delay in replying - had some other problems.

My office, (remote) workstation can connect to the SME server via VPN but not to the domain.
(My office workstation is XP3 Prof SP3)

I followed your suggestion in paragraph 4, (standalone PC), by connecting, as usual to the SME sever via VPN using the "non-domain" VPN login screen, (no domain name is requested). This was successful.

Then, with the VPN tunnel still established, I attempted to join the domain via the Control Panel > System > Computer Name > Change dialogue.
Initially I was a member of a local workgroup, (comprising 1 PC). I requested membership to my remote SME served domain by entering the domain name in the "Domain" box, (switching on the radio button first, of course), then clicking "OK".

This resulted in an error stating that a domain controller for my remote domain could not me found.
As the remote domain is private and NOT registered with a DNS server I added the domain name and remote server local IP address to me HOSTS file. I tested connectivity by successfuly pinging the remote domain name.

I then tried several combinations in the "Domain" box, (e.g. server local ip address, server local IP name, server external IP address). None of which worked which was as I expected.

I then created an entry in my LMHOSTS file defining the SME domain name pointing to the SME server at its local IP address. This also failed.
I modified my NETWORK > WINS parameters on my VPN connection to first enable NETBIOS over TCP/IP then to disable it: neither worked.

Looking into this a bit deeper it seems to me, (and I accept that I may be very wrong), that the SME server is not accepting and/or processing the datagram generated by the Netlogon process of me client when delivered via VPN.

I do have a valid user account on the SME server, (the one that I am using to attempt to join the domain), and VPN access for the user account on the server is enabled.

Stranger and stranger...

Cheers,
Alex

PS. - reply tp axesslt:

We really are talking DOMAINS not WORKGROUPS. My remote client the is not initially connected to any domain and is thus in its own workgroup whose name is different to the domain to which I am trying to connect.
My remote client is on a LAN which also has a locally connected SME server that is also a domain controller. The remote unattached client can see the local SME server with Windows browser.
 

[janet]

alext

Are you trying all this with the personal or any firewall disabled for the VPN connection, and with the remote SME server configured as the WINS/DNS server for your VPN connection (ie in your VPN setup) ?
Is the SME server you are remotely connecting to, actually the Domain Controller for that network ?

This resulted in an error stating that a domain controller for my remote domain could not be found.
As the remote domain is private and NOT registered with a DNS server....

Don't blame SME server, that error is reasonably explicit. Your system cannot find the domain controller. You need to troubleshoot and understand why that is so, but you seem to be trying random fixes and then saying it's very strange when it doesn't work. Do your research and find out why. Investigate domain login via VPN much more than you have done so far.

I don't understand the relevance or meaning of your comment re the remote domain is private and not registered with a DNS server. Does it have some meaning to you that may impact upon the issues you are experiencing ? As I asked earlier, is the server you are connecting to an SME server and is it the Domain Controller for that network ?

[Stefano]

This resulted in an error stating that a domain controller for my remote domain could not me found.
As the remote domain is private and NOT registered with a DNS server I added the domain name and remote server local IP address to me HOSTS file. I tested connectivity by successfuly pinging the remote domain name.

I haven't had any problem to authenticate a domain client via vpn..

I mean: pc client joined to a remote SME server.. at windows startup, che flag "Use remote connection" (or similar, my O.S. is in italian) was set... no problem at all..

it's a network problem.. investigate on it

[axessit]

PS. - reply tp axesslt:

We really are talking DOMAINS not WORKGROUPS. My remote client the is not initially connected to any domain and is thus in its own workgroup whose name is different to the domain to which I am trying to connect.
My remote client is on a LAN which also has a locally connected SME server that is also a domain controller. The remote unattached client can see the local SME server with Windows browser.

I realise we are  talking about domains, but the "workgroup" box in the configuration has a windows workgroup name, that is the name of the domain you try and join. I have often found you have to change the windows workgroup name to match the domain (and you leave out the ".co.xx") on the workstation, reboot, then try and join it to the domain.

For instance, I have a SME server with the domain axessit.test, and the workgroup is set for testing, so the domain I put into the windows Domain box to join is testing, not axessit.test.

I do have a valid user account on the SME server, (the one that I am using to attempt to join the domain),

If you are getting asked for a username and password, then the workstation has found the domain controller. You must use a domain admin account, such as admin/passwd, not just any user account name.

Maybe you should tell us the SME workgroup setting, the and the Windows domain you are trying to join.

[janet]

alext

Ah yes, axessit has identified your confusion between a Domain (trusted group of computers) and a domain name (URL for Internet access). They are totally different things.

The Domain name for purposes of logging in to a trusted DOMAIN (ie login to a SME Domain Controller server or DC) is the same as the workgroup name you configured in server manager, but only in the case where the server is also configured to be the only DC on your network eg WRKGROUP or OFFICE1

The Internet URL type domain name is the main domain name given to your server when you first ran the Configure this server screens eg mymaindomain.com.au

Also as axessit identified & I said earlier, only the admin username and password combination or a user who has admin privileges, can authorize a workstation to join a domain.

Try again with the correct DOMAIN name and admin user details.