Crossing Domain Boundaries: Name Resolution


You may be in a situation where you have to access network resources from another Active Directory domain. Perhaps you do business with another company and have to access files or applications from their network. This situation is very common when you are a consultant installing, configuring or building custom information systems for different clients. There are several challenges you have to solve or work around to access network resources across domain boundaries.

Assuming that you already connected to the client’s network with the help of DHCP, your first challenge is to get name resolution working. Name resolution is a process that converts human readable host names into numeric addresses used by TCP/IP. Whenever computer program uses a network address, such as a web URL http://target, the host name has to be converted or resolved to an IP address before the target host can be accessed over the network from your computer. When both your computer and the target host are on the same domain, this process works seamlessly. However, when computer and the target host are on different domains, you may need to make additional configuration changes.

There are two name resolution mechanisms in active use today: NetBIOS and DNS. Although both of these these protocols were developed in the early 1980s, NetBIOS was implemented on the Windows platform first and then has fallen out of favor with release of Windows 2000 and Active Directory, which provided support for DNS.

C:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : CATTAMLAPTOP
   Primary Dns Suffix  . . . . . . . : catapultsystems.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : catapultsystems.com
                                       dmz.catapultsystems.com

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : client.lan
   Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Controller
   Physical Address. . . . . . . . . : 00-11-22-33-44-55
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::3424:f17e:93ec:8912%11(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.16.242.13(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Lease Obtained. . . . . . . . . . : Thursday, April 23, 2009 4:12:45 PM
   Lease Expires . . . . . . . . . . : Thursday, April 30, 2009 4:12:45 PM
   Default Gateway . . . . . . . . . : 172.16.1.2
   DHCP Server . . . . . . . . . . . : 10.10.4.22
   DNS Servers . . . . . . . . . . . : 10.10.4.6
                                       10.10.4.8
   NetBIOS over Tcpip. . . . . . . . : Enabled

You can tell which mechanism is available by looking at the output produced by ipconfig command. In particular, the DNS Servers setting will tell you if a DNS server is available for name resolution and NetBIOS over Tcpip setting will tell you if NetBIOS is enabled.

Name resolution through DNS

DNS works in client-server mode, where your computer sends a name resolution request to a DNS server and the server sends back the IP address registered for the specified host name. To use DNS for name resolution, first you need to use the ipconfig command (shown above) to verify that a DNS server is available. Typically, this will be configured automatically, by DHCP, when your computer connects to the network.

Because the Domain Name System is hierarchical, DNS server cannot uniquely resolve a local name such as target. Before sending a host name to the server, DNS client will try to guess its fully-qualified domain name (FQDN), such as target.client.lan, based on the list of known DNS suffixes it has access to through various configuration settings. It will keep asking the configured DNS servers to resolve the potential names until it finds a match. The order of DNS servers and domain suffixes is important because the DNS client will use the first one it can resolve. If it happens to be a wrong guess, you will not be able to connect to the desired target host.

Primary DNS suffix

The primary DNS suffix a suffix of the fully-qualified domain name of your computer. As you can see in the Windows IP Configuration section of the ipconfig output below, the primary DNS suffix on my laptop is catapultsystems.com.

C:\>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : CATTAMLAPTOP
   Primary Dns Suffix  . . . . . . . : catapultsystems.com
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : catapultsystems.com
                                       dmz.catapultsystems.com
DNS client configuration

The Windows IP Configuration section of the output of ipconfig command also shows you the search list of suffixes specified in the DNS client configuration. By default, the DNS Suffix Search List will include only domain suffixes for your own domain. You can change this list using Registry Editor as shown below.

image

Also keep in mind that your domain administrator may be controlling this and other DNS client settings using Active Directory group policy.

image

Network adapter configuration

TCP/IP settings of your network adapter configuration can also provide DNS suffixes for name resolution. As you can see on the screenshot below, you can either specify a connection-specific suffix or an entire list of different DNS suffixes and their order.

image

Configuring and verifying DNS name resolution

As we discussed, DNS client will try to resolve a local host name such as target, by appending the list of domain suffixes it knows about and sending them to the DNS server until it finds a fully-qualified domain name the server can resolve. Unfortunately, this process is complicated by having two different sources of this information on your computer (DNS client configuration and network adapter configuration), different implementations of DNS servers and network administrators controlling these settings through group policy. I had better luck with DNS client configuration and prefer to use it exclusively. However, I can imagine a different combination of these conditions where network adapter configuration may work better.

In our example, where we need to access a host called target located on the Active Directory domain client.lan, use the Registry Editor to add client.lan to beginning of the comma-delimited search list of DNS suffixes. You could also use a registry import file similar to one show below, just make sure you replace the Catapult domain suffixes with your own.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient]
"SearchList"="client.lan,catapultsystems.com,dmz.catapultsystems.com"

Once you have configured the list of domain suffixes, verify that your DNS client can resolve target host name using ping and nslookup commands as shown below.

C:\>ping target

Pinging target.client.lan [10.10.4.74] with 32 bytes of data:
Reply from 10.10.4.74: bytes=32 time=2ms TTL=127
Reply from 10.10.4.74: bytes=32 time=1ms TTL=127
Reply from 10.10.4.74: bytes=32 time=1ms TTL=127
Reply from 10.10.4.74: bytes=32 time=1ms TTL=127

Ping statistics for 10.10.4.74:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 2ms, Average = 1ms

C:\>nslookup target
Server:  dns.client.lan
Address:  10.10.4.6

Name:    target.client.lan
Address:  10.10.4.74

The nslookup command will tell you if the DNS server is available, if it can resolve the host name and what the local host name was actually resolved to. This step is important to verify that your DNS client guessed the fully-qualified domain name of the target host correctly. Depending on configuration, the DNS client may try using the primary DNS suffix first and ask the server to resolve target.catapultsystems.com before it asks about target.client.lan. Some DNS servers I had to connect to in the past would happily accept these names from other domains and return incorrect IP addresses.

The ping command will tell you if the actual target host is available. Typically computers will respond to ping requests within a local network, but keep in mind that some network administrators may turn this service off to improve security and reduce network traffic.

On rare occasions, the DNS client may not be able to resolve the target host name immediately after you change the configuration. In  this case, you can can give it a nudge by flushing DNS cache and pinging the target host again.

C:\>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Name resolution through NetBIOS

With Windows 2000, DNS replaced WINS as a recommended name resolution mechanism. NetBIOS can work in two modes - peer-to-peer, when name resolution requests are broadcast across the local network, and client-server, when name resolution requests are sent to a NetBIOS Name Service, also known as WINS. Although many company no longer have WINS servers on their network, you may still be able to use it in peer-to-peer mode. Whether it works will depend on the target host being within the reach for name resolution broadcasts from your computer and having the NetBIOS setting enabled. NetBIOS also works great for name resolution in small home network and virtual networks between several VMs on a single physical host.

In order to use NetBIOS successfully, check the adapter configuration section of the ipconfig output to see whether NetBIOS over Tcpip is Enabled on both your computer and the target host.

C:\>ipconfig /all

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : client.lan
   Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Controller
   Physical Address. . . . . . . . . : 00-11-22-33-44-55
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::3424:f17e:93ec:8912%11(Preferred)
   IPv4 Address. . . . . . . . . . . : 172.16.242.13(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Lease Obtained. . . . . . . . . . : Thursday, April 23, 2009 4:12:45 PM
   Lease Expires . . . . . . . . . . : Thursday, April 30, 2009 4:12:45 PM
   Default Gateway . . . . . . . . . : 172.16.1.2
   DHCP Server . . . . . . . . . . . : 10.10.4.22
   DNS Servers . . . . . . . . . . . : 10.10.4.6
                                       10.10.4.8
   NetBIOS over Tcpip. . . . . . . . : Enabled

You can change this setting in network adapter configuration as shown below. Note that Default setting for NetBIOS may mean both enabled or disabled. You may want to set it explicitly if you need to use NetBIOS.

image

Having verified that NetBIOS over TCP/IP is enabled, you can use ping and nbtstat commands to verify if you can resolve name of the target host through NetBIOS.

C:\>ping target

Pinging target [172.16.1.195] with 32 bytes of data:
Reply from 172.16.1.195: bytes=32 time=1ms TTL=128
Reply from 172.16.1.195: bytes=32 time=2ms TTL=128
Reply from 172.16.1.195: bytes=32 time=7ms TTL=128
Reply from 172.16.1.195: bytes=32 time=2ms TTL=128

Ping statistics for 172.16.1.195:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 7ms, Average = 3ms

C:\>nbtstat -r

    NetBIOS Names Resolution and Registration Statistics
    ----------------------------------------------------

    Resolved By Broadcast     = 1
    Resolved By Name Server   = 0

    Registered By Broadcast   = 3
    Registered By Name Server = 0

    NetBIOS Names Resolved By Broadcast
---------------------------------------------
           TARGET       <00>

nbtstat will confirm if target host name was resolved through NetBIOS broadcast and ping will confirm if the target host can be reached via TCP/IP. Notice that even though the target host is a member of an Active Directory domain, both ping and nbtstat commands report only its local name. This may be important if the application you are trying to reach on the target host was configured to use fully-qualified domain names.

Conclusion

In order to access network resources on a different Active Directory domain, you often need to make additional configuration changes to allow name resolution process to work correctly. Although it is possible to use fully-qualified domain names, such as target.client.lan, or even raw IP addresses, such as 172.16.1.195, many applications are configured to use local host names and will not work correctly. In particular, an application, such as Windows SharePoint Services, may have the local host name embedded in its configuration and will encounter errors after initial successful connection.

In my experience, using DNS-based name resolution and adding the target DNS suffix (client.lan) to the DNS client search list in registry works best. I found DNS client configuration to be more reliable than changing TCP/IP settings of the network adapter. I’ve had situations where DNS suffixes configured through TCP/IP settings would not work no matter what I tried. However, you may have to use network adapter TCP/IP settings if the DNS client configuration is controlled by the Active Directory group policy in your organization.

Although outmoded by DNS in Active Directory networks, NetBIOS-based name resolution is still useful when working on small networks that don’t have Active Directory, such as a home networks or a virtual networks built using Virtual PC and Loopback Adapter. Make sure that NetBIOS over TCP/IP is enabled to take advantage of this name resolution mechanism.

What’s next

Once you have name resolution working correctly, your next challenge when accessing network resources is authentication. Majority of applications on the Microsoft platform rely on integrated Windows authentication to allow administrators to manage security in company’s Active Directory. Integrated Windows authentication is a great improvement compared to custom authentication and authorization mechanisms that were prevalent in applications before. Unfortunately, it also creates additional difficulties when you try to access network resources and applications across domain boundaries. In some cases, these difficulties are seemingly insurmountable and lack of knowledge forces us to fall back on older, custom authentication mechanisms, such as SQL Server authentication. However, solutions exist for most of these problems, which is the topic of the next article (coming soon).


Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Be the first to leave a comment!