Inside Windows Server 1002003 [Electronic resources] نسخه متنی

DNS and Active Directory Namespaces

AsChapter 6, "Understanding Active Directory Services," an Active Directory domain must be rooted in a DNS domain name. Figure 8.1 shows a DNS domain namespace and a corresponding Active Directory tree.

There's no question that deploying and managing Active Directory is simpler if you use Windows Server 2003 name servers. However, if you have an existing third-party DNS platform, it's not likely that you can shift to Windows Server 2003 overnight. You may not even want to shift at all. Because DNS is such a critical element in Active Directory design and operation, you must decide how you will integrate Windows Server 2003 into your current DNS infrastructure. Here are three popular configurations:

• Forget about Windows DNS completely and use third-party name servers to host the zone for the Active Directory domain.




• Create a separate DNS domain for Active Directory, host the zone on Windows Server 2003 name servers, and forward queries for records in other zones to a third-party name server.




• Use your current public DNS domain to root the Active Directory domain and create a split public/private zone with the private zone hosted by Windows Server 2003 name servers.

The next few sections examine these options in detail.

Active Directory and Third-Party Name Servers

You do not need to run Windows Server 2003 DNS to support Active Directory, but your DNS servers must run a version of DNS that supports the Service Locator (SRV) resource record type as defined in RFC 2782, "A DNS RR for Specifying the Location of Services (DNS SRV)."

Active Directory domain controllers use SRV records to publish their Lightweight Directory Access Protocol (LDAP) and Kerberos services. The format for these records is specified in RFC 2052, "SRV Record Format and Use." Name servers running BIND 8.1.2 and later support SRV recordsso do servers running the most current version of Lucent QIP or NetWare 5.x DNS.

Because SRV records have a complex format, and Active Directory uses a lot of them, it is helpful to use a DNS platform that supports dynamic record registration as defined in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)."

If your DNS platform uses only static zones, or you don't want to enable dynamic updates, you must manually enter the SRV records in their proper format. The Domain Controller Promotion Wizard creates a file called Netlogon.dns in the C:\Windows\System32\Config folder. This file contains the SRV records that Netlogon attempted to register with DNS. You can import this file into a third-party name server, but your job doesn't stop there. You must remember to manually update the zone for any subsequent changes such as promoting or demoting domain controllers, creating new site objects, or changing a domain controller's site affiliation.

Separate Windows Domain and Windows-Based Zone

You may decide that your current DNS name is unsuitable for Active Directory. Or you may be unable to convince management to host Active Directory resource records on your current name servers. If so, you can create a separate DNS domain and root Active Directory in that namespace. Host the zone for the new domain on a Windows name server and use the existing name server as a forwarder. This configuration is shown in Figure 8.2.

In this configuration, your Windows clients point at the Windows name servers. When the clients request a record in an outside zone, the Windows name server forwards the request to the original name server. For Internet records, the Windows server can use root hints to sent iterative requests to the Verisign Top Level Domain (TLD) servers.

Public Domain with Split Public/Private Zone

This option is commonly used by organizations that want to retain their current, registered DNS domain name as their Active Directory domain name. For instance, the International Widget Company may prefer to use its registered Widget.com name rather than Widget.net or Widget.local or some other private namespace. Figure 8.3 shows this configuration.

This configuration uses separate zones for the public namespace and the private namespace. The private zone is hosted on a name server inside the firewall. The public zone is hosted on a name server in the DMZ or on an ISP's name server. In either case, clients point at the name server inside the firewall. This name server uses the outside name server as a forwarder or uses root hints to resolve addresses outside its zone of authority. You get the most flexibility for Active Directory by hosting the private zone on a Windows name server.

If you use this split configuration or one similar to it, keep in mind that Active Directory clients cannot access the private name server while they are outside the firewall. The client can only authenticate when connected through the firewall using a dial-up connection, a Virtual Private Network (VPN), or some other form of protected connection. Clients can use the Logon Using Dial-Up Connection option at the initial logon window to establish their credentials at logon. For Windows 2000/XP clients, this initiates a Kerberos-based logon that significantly speeds up subsequent access to member servers.

Root Domain Name

"What's in a name?" asked Juliet as she gazed at the heavens and dreamt of her Romeo. Names turn out to be critically important, in computing and love. Don't pay the price that Romeo and Juliet paid by ignoring names as you design your domains.

Windows clients live in two worlds: a hierarchical world where the only name that really matters is the fully qualified DNS domain name and a flat world where the NetBIOS name has ultimate significance. Your domain design must support both these naming structures.

When you promote the first domain controller in an Active Directory domain, the Domain Controller Promotion Wizard (Dcpromo) generates a flat NetBIOS name from the left-most element of the fully qualified DNS name. For example, the Company.com DNS name yields the flat name COMPANY. It's theoretically possible to designate a flat name during the domain controller promotion that does not match the leftmost element in the DNS name. This can cause confusion among users, who may wonder what name to use in any given circumstance.

If you want to retain your current NT domain name as your Active Directory domain name, you must select a DNS domain name that uses the flat name as the lowest domain constituent. For example, the NT domain called COMPANY could have a DNS name of Company.com, Company.net, Company.local, or Company.Enterprise.ParentDomain.com.

Domain Name Restrictions Caused by Flat Names

To retain your current NT domain name as the flat name for your Active Directory domain, you must upgrade the existing PDC. You cannot create a parallel Active Directory domain with the same flat name because this causes a NetBIOS name conflict.

For example, let's say you have an existing NT domain named COMPANY. If you try to promote a new Windows Server 2003 domain controller and root Active Directory in a DNS domain called Company.com, the Domain Controller Promotion Wizard attempts to register the flat name COMPANY it derived from Company.com. When it does this registration, it gets a notification from the PDC of COMPANY (or from WINS) declaring that the COMPANY domain name already exists. The promotion wizard will suggest COMPANY0. You should not accept this or any other alternative that results in a flat name that does not match the lowest DNS domain.

If you don't like your current NT domain name and you want your Active Directory domain to have a different flat name, you must set up a new Active Directory domain and migrate objects into the that domain from the existing NT domain. The next chapter contains details on object migration.

Suggestions for Resolving Name Disputes

The pairing of Active Directory and DNS in many organizations is as star-crossed as Romeo and Juliet's relationship. Large organizations often have a multitude of highly competitive IT groups who may have fractured the DNS namespace into many zones that forward and delegate in ways that would give a chess champion a headache.

The DNS namespace for a university, for example, might have separate domains for Academic Services, Administration, Alumni, Biology, Chemistry, Physics, Fine Arts, Physical Education, Facilities, Math-Physics, Humanities, Bookstore, Student Union, and Library with subdomains under each for Undergrads, Grads, Law, Medical, and Hospital, not to mention more branches for outlying campuses and extended campuses and minicampuses and walk-in learning centers and on and on and on.

If you are an administrator in a department or office that exists in a DNS subdomain, you may be wondering how to handle your Active Directory design. To avoid the inevitable bureaucratic decision process, you may be tempted to root your Active Directory forest in your current DNS subdomain and proceed with your deployment. Here is why that would be a mistake.

Let's say your DNS subdomain is Humanities.EastCampus.BigUniversity.edu. Your current NT domain name is PLATO. When you migrate to Active Directory, you want to change the domain's flat name because Plato has been exposed as an intellectual despot who wreaked carnage on centuries of western thought. You decide to create a Windows Server 2003 domain rooted in your DNS subdomain with the flat name HUMANITIES. This has two unfortunate consequences:

• The domain's flat name must be unique in a forest to preserve backward compatibility. There are other Humanities departments at other campuses and they would not like you preempting the name.




• By rooting your Active Directory domain at Humanities.EastCampus.BigUniversity.edu, you form a new forest. When the rest of the university eventually migrates to Active Directory, you'll be forced to migrate objects from your forest to their forest or to form a transitive Forest Trust. The second option limits your ability to share resources and makes comprehensive domain management much more difficult.

Your best option is to meet with IT staff from the various campuses and decide how to move forward together with a DNS namespace that supports a unified Active Directory design and deployment. If you are absolutely stymied by bureaucracy and inertia, you can proceed with your own forest but be prepared to do lots of work in the future to heal the breach.