Introduction
Within an Active Directory network there are many moving components that need to be understood to help track down issues that might be occurring for domain controllers, servers, and desktops. From the desktop troubleshooting side, many issues can be tracked back to the DNS IP address that is configured for the IP properties. If the DNS IP address is incorrect, many errors will occur, which are mostly behind the scenes and nothing will indicate what the true problem is. In order to see what can go wrong, as well as understand what is happening behind the scenes, this article will describe all of those moving parts to flush out the common issues. When you are done reading, you will have a much better understanding of how your desktops (and even servers) obtain all of the information they need to authenticate and access network resources.
The Desktop First Step
During boot, the operating system will do what it needs to get the core Windows files and parameters in place. This is done by the boot.ini, ntoskrnl, and other files. All these files are doing is making sure that the last booted operating system and configurations are put in place. This will include the Registry, configuration files, and even down to making sure the correct operating system is selected, if there are a few loaded on the computer.
After the operating system is prepared, then the computer needs to configure the network. For most corporations the network is configured using DHCP, which stands for Dynamic Host Configuration Protocol. DHCP is very well known and most of you reading already knew that acronym. In order for your desktop to contact DHCP it performs a network broadcast to contact a DHCP server. The DHCP server(s) are already listening for these requests and will capture the broadcast request and respond when one of them hears the request.
Note:
Starting back in Windows 2000 if there no DHCP server responds (meaning there is one on the network which did not respond or there is not one at all for the network), the desktop will automatically configure a IP address to itself. This is the APIPA address, which stands for Automatic Private IP Address. The APIPA range of IP addresses is 169.254.0.1 to 169.254.255.254.
When the desktop communicates with the DHCP server, it will receive IP related configurations. The IP configurations that most DHCP servers deliver to the client include:
IP address
Subnet mask
Default Gateway
DNS IP address
WINS IP address
DNS domain name
If the desktop does not receive the correct IP settings, such as IP address or subnet mask, then the desktop might not even communicate with other computers on the network. If the wrong default gateway is provided, then the desktop will not be able to communicate outside of its subnet, which might not include the DNS server.
If the desktop is configured to have the user be a local administrator, the user can also modify the IP address settings manually. This will override any settings received by the DHCP server and in some cases can eliminate all communications with the DHCP server. In the end, the desktop can be restricted from communicating with all other computers on the network. It can also fail to communicate with the correct DNS server, if the DNS server entry is incorrect for the network and Active Directory domain where the desktop resides.
The Desktop Second Step
Now that the desktop has all of the essential IP configuration information, it now needs to find and communicate with a domain controller for the Active Directory domain. Instead of this initial communication being a broadcast, like it was to communicate with the DHCP server, the desktop directly communicates with the DNS server it has configured to find the domain controllers.
The desktop makes direct contact with the DNS server and waits to hear back from the DNS server with information about the domain controllers. When the DNS server receives the request from the desktop, it must analyze the information that it receives.
- The DNS server will evaluate which subnet the desktop is on, based on the IP address and subnet mask configured on the desktop
- The DNS server must evaluate which Active Directory site the desktop is located in, if there are any sites configured in DNS
- The DNS server must evaluate the order of the domain controllers that it responds with, based on domain controller priority, sites, and domain controllers configured to be used for other sites
The result that the DNS server gives to the desktop is called the DCLIST, and is a hierarchical list of domain controllers based on the criteria the DNS made during analysis. The top of the DCLIST should be domain controllers in the desktops site, then the other domain controllers not in the site.
The DNS server also provides the other SRV (service resource records) to the desktop, which it needs. This would include the KDC (Key distribution center for Kerberos) and DFS servers (if configured within DNS).
If the desktop fails to obtain the SRV records it will fail to use anything related to Active Directory, due to the fact that the only way the client can use Active Directory is to obtain the TCP, LDAP, DC, and KDC SRV records it obtains from DNS. This will make Kerberos fail, Group Policy fail, and all other communications to the domain controllers via Kerberos and LDAP fail.
The Desktop Third Step
Now that the desktop has the IP address of the domain controllers, it can make a direct connection to the first domain controller on the list. This should be a quick connection, as the domain controller should be in the desktops’ site.
If the domain controller is available, it will respond and the desktop and domain controller communicate. The desktop provides information to the domain controller such that the desktop can be authenticated as a member of the domain.
After the desktop is authenticated, the desktop will receive the essential information that it is designed to receive, such as startup scripts, Group Policy settings, etc. This is communicated from the domain controller through a secure connection, which is shared out from the domain controller via the NETLOGON share.
There is a good chance the desktop will finally authenticate, but it will be using NTLMv2 or NTLM. Kerberos is only used when the desktop can obtain the KDC and other SRV records from DNS. Again, if there is no Kerberos communication with the domain controller, all Active Directory functions fail for the desktop.
Summary
As you can see DNS configurations for the desktop are essential. If there are any incorrect settings on the desktop, either manually or from the DHCP server, the desktop will not correctly communicate with the DNS server or the Active Directory domain controller. With so much riding on the correct DNS configuration, it is essential that DNS be configured correctly for all Windows computers that are joined to the Active Directory domain. Without the correct configuration, the desktop will not use Kerberos, will not receive Group Policy, and will not be able to use Active Directory correctly, due to the fact that no communication was made with the DNS server to receive the SRV records that Active Directory placed there for finding AD resources.
