Petitulo Del Traste

Mastering the Domain Name System

on Windows Server 2003

DNS

Cricket Liu, Matt Larson & Robbie Allen

Chapter 8 8 CHAPTER

Integrating with Active Directory

“The face is what one goes by, generally,” Alice remarked in a thoughtful tone.

With the release of Windows 2000, Microsoft replaced the Windows NT Security Account Manager (SAM) with Active Directory (AD), which serves asthe repository for information about users, groups, computers, and other network resources. In contrast to the SAM, Active Directory is built on several well-known standards including the Lightweight Directory Access Protocol (LDAP) for accessing and manipulating data, Kerberos for authentication, and—you guessed it—DNS for name resolution. In fact, using DNS for name resolution is one of themajor improvements of Active Directory over Windows NT, which relied on the Windows Internet Naming Service (WINS). Microsoft made the decision to develop WINS in the early days of Windows NT because, at the time, DNS did not support dynamic update capability, which Microsoft needed for its clients. As a result, many companies had to implement both services: DNS for standard Internet-based nameresolution and WINS for the Windows NT environment. This often pitted the NT administrators against the DNS administrators because of the need to maintain two separate namespaces. Over time, dynamic update support was added to DNS, and WINS failed to garner industry support—in no small part because it was a proprietary Microsoft offering. Even with the opportunity to get rid of WINS, migrating to ActiveDirectory hasn’t always resulted in a harmonious union between AD and DNS administrators. While Windows NT had virtually no DNS requirement, Active Directory is at the opposite extreme. It is completely dependent on DNS. If DNS becomes unavailable, clients may fail to authenticate or log in to Active Directory, and domain controllers will not be able to replicate changes throughout the forest.This highly visible dependency on DNS requires that the AD and DNS administrators work closely together (assuming they are in separate groups) and agree on implementation details, which can sometimes be a challenge. It is not uncommon for DNS administrators to be reluctant to delegate part of the namespace for Active Directory, and AD administrators are often

146 This is the Title of the Book,eMatter Edition Copyright © 2003 O’Reilly & Associates, Inc. All rights reserved.

hesitant to entrust a critical component to another group and forgo the advantages of AD-integrated DNS. This chapter explores many of the key DNS-related issues you need to be aware of when implementing and supporting Active Directory. We cover how Active Directory uses DNS for service advertisement and domaincontroller location; and, conversely, how Active Directory can be used to enhance DNS by providing robust replication and security for zone data. We do not—in fact, cannot in a single chapter—cover the numerous other Active Directory components. For more information on designing, implementing, and automating Active Directory, see Active Directory, Second Edition (O’Reilly) by our own Robbie Allen.For examples on how to perform common Active Directory administrative tasks, see Active Directory Cookbook (O’Reilly), also by Robbie.

Active Directory Domains
One of the first issues you have to consider when implementing an Active Directory infrastructure is how many domains you need and what to name them. Active Directory domain names are DNS domain names, but—and this is important—not everyDNS domain name is an Active Directory domain name.* So while an organization’s Active Directory namespace resembles its DNS namespace, the two don’t have to be identical. The number of domains you create in your forest is largely dependent on your administrative and replication requirements. A domain is mastered by one or more domain controllers, which are servers that have writeable copies of...