We have a Windows XP Professional desktop at a remote site connected to our SBS 2003 domain controller at the main office via VPN (LogMeIn Hamachi).

The XP desktop was joined to the domain across the VPN connection without any problems.

The issue is that domain users at the remote site see the following message when they try to log on:

enter image description here

This does not happen when the PC is taken to the main office and connected to the LAN, and subsequent attempts to log on remotely succeed after this is done (but only due to cached credentials- the underlying problem remains and new users will still not be able to log on at the remote site).

The other symptom is that domain users do not show up properly on the Local Users and Groups MMC snap-in (it shows only their SIDs, without the corresponding domain user names).

I've tried removing the PC from the domain and re-joining in case it was simple broken trust relationship problem (and even tried a different PC) but the issue is always the same.

Here are the results of pinging various combinations of hostnames and IP addresses for the domain controller from the XP system:

ping server = SUCCESS

ping server.domain.local = FAIL (however pinging the server's FQDN is successful when done to PCs at the main office)

ping = FAIL (pinging DC by its private IP)

ping server's Hamachi VPN IP address = SUCCESS

There are no problems accessing shares on the server over the VPN link.

The (automatically-assigned) DNS for the XP system is the gateway router's IP:

Network shares on the server are working perfectly- it seems this issue only affects the ability to log on as domain users.

Any ideas what is going on and how I can fix this?


As you suspected, it's DNS at the remote site.

In order for a DNS server to be able to support Active Directory, the server is required to support the service (SRV) resource record type and the dynamic update protocol, as described in the RFC 2136. Active Directory uses DNS as the location mechanism for domain controllers, enabling computers on the network to obtain IP addresses of domain controllers. During the installation of Active Directory, the service (SRV) and address (A) resource records are dynamically registered in DNS. Both types of records are necessary for the functionality of the domain controller locator (Locator) mechanism.

To find domain controllers in a domain or forest, a client queries DNS for the SRV and A DNS resource records of the domain controller. The resource records provide the client with the names and IP addresses of the domain controllers. In this context, the SRV and A resource records are referred to as Locator DNS resource records.


Because the remote site can't contact the DC via its internal IP, remote users can't "find" that server to log on.

You probably don't want to add an entry for the second IP. Multihoming a domain controller can cause issues.


Instead, I think you want to disable DNS registration on the virtual Hamachi adapter. That's what I would try first, anyway.

http://support.microsoft.com/kb/272294 (that refers to 2000, but it should work for 2003, too)

Good luck!

[Edited to add...]

It sounds like you have the Hamachi interface on the DC itself. If so, I don't know if Hamachi supports referring to the DC via the non-Hamachi interface. You might have to use a different machine as a tunnel endpoint, if not.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.