11.1 Active Directory


DNS on Windows 2000, 2nd Edition
By Matt Larson, Cricket Liu
Table of Contents
Chapter 11.  New DNS Features in Windows 2000

11.1 Active Directory

Active Directory is the major new feature of Windows 2000. It's a hierarchical database of information about all objects in the network: computers, printers, users, and so on. Both users and computers access the information in Active Directory. The Active Directory database is partitioned into domains for administrative purposes, and one or more domain controllers store information about particular domains. (Compare this to DNS's namespace, which is partitioned into zones, with one or more name servers authoritative for each zone.) The most important fact about Active Directory for our purposes is that it is integrated tightly with DNS. For moremuch moreinformation about Active Directory, see Windows 2000 Active Directory by Alistair G. Lowe-Norris (O'Reilly).

11.1.1 Active Directory Domain Names

The most obvious connection between Active Directory and DNS is the naming of domainsActive Directory domains, that is. In the past, under Windows NT, domain names followed the NetBIOS host-naming rules: names consisted of a single label (i.e., no dots) and could contain letters , digits, and limited punctuation. Most Windows dialog boxes forced domain-name input to uppercase, so while they were case-insensitive, you usually saw domain names written in all uppercase. For example, Movie University's Windows NT domain name was MOVIEU .

With Windows 2000, all Active Directory domain names are DNS domain names, butand this is importantnot every DNS domain name is an Active Directory domain name. [1] So while an organization's Active Directory namespace resembles its DNS namespace, the two don't have to be and probably won't be identical. While it's beyond the scope of this book to give an exhaustive explanation of Active Directory namespace design, we can give you some examples to clarify the connection between the naming of Active Directory domains and DNS domains.

[1] And every square is a rectangle, but not all rectangles are squares. All registered mail is certified, but not all certified mail is registered. You get the idea.

Consider Movie University. After reading this far, you're familiar with Movie U.'s DNS namespace: the apex (or top) of the namespace is movie.edu , and there are subdomains named fx.movie.edu , classics.movie.edu , and comedies.movie.edu . This namespace is represented in Figure 11-1.

Now let's talk about Movie U.'s Active Directory namespace. An organization's Active Directory domain names correspond to some of its DNS domain names, and the Active Directory domain at the top of an organization's domain tree usually corresponds to a subdomain of the apex of its DNS namespace. In Movie U.'s case, however, the root of the Active Directory domain tree is the same as the apex of the DNS namespace, movie.edu . Figure 11-1 shows Movie U.'s Active Directory domain tree beside its DNS namespace. Note how the two diverge, though. For various administrative reasons, the folks over in fx.movie.edu need to run their own Active Directory domain. But everyone else at Movie U. is a part of the movie.edu Active Directory domain, even though individual hosts fall into different DNS domains.

Figure 11-1. Movie University's namespace

11.1.2 DNS as Location Broker

You may be wondering why Active Directory domain names are DNS domain names. The answer is that Windows 2000 systems (running in native mode) use DNS as a location broker ; that is, to find services. Previous versions of Windows used NetBIOS to find domain controllers, but Windows 2000 hosts use DNS. Take the case of a Windows 2000 Professional host at Movie U. that's been joined to the movie.edu Active Directory domain. When this system boots up, it sends a series of DNS queries to its configured name server to find a domain controller for the movie.edu domain. The SRV resource record

The particular query sent by the Windows 2000 client is for a resource record type you may not have heard of: the SRV (service location) record. The SRV record, introduced in RFC 2782, is a general mechanism for locating services. Before we can talk in detail about exactly how a Windows 2000 client finds its domain controller using SRV records, we need to describe the SRV record itself.

Locating a service or a particular type of server within a zone is a difficult problem if you don't know which host it runs on. Some zone administrators have attempted to solve this problem by using service-specific aliases in their zones. For example, at Movie U. we created the alias ftp.movie.edu and pointed it to the domain name of the host that runs our FTP archive:

 ftp.movie.edu.    IN    CNAME    plan9.fx.movie.edu. 

This makes it easy for people to guess a domain name that will get them to our FTP archive and separates the domain name people use to access the archive from the domain name of the host on which it runs. If we were to move the archive to a different host, we could simply change the CNAME record.

Another option, for clients that understand it, is the SRV record. In addition to simply allowing a client to locate the host on which a particular service runs, SRV provides powerful features that allow zone administrators to distribute load and provide backup services, similar to what the MX record provides.

A unique aspect of the SRV record is the format of the domain name to which it's attached. Like the service-specific aliases described earlier, the domain name an SRV record is attached to gives the name of the service sought, but it also includes the protocol it runs over, concatenated with a domain name. The labels representing the service name and the protocol begin with an underscore to distinguish them from labels in the domain name of a host. So, for example:


represents the SRV records someone ftp ing to movie.edu should retrieve in order to find the movie.edu FTP servers, while:


represents the SRV records someone accessing the URL http://www.movie.edu should look up in order to find the www.movie.edu web servers.

The names of the service and protocol must come from the latest Assigned Numbers RFC (the most recent as of this writing is RFC 1700) or be unique names used only locally. Don't use the port or protocol numbers , just the names. When entering SRV records with the DNS console, the service name is limited to eight common services.

The SRV record has four resource record-specific fields: priority , weight , port , and target . Priority, weight, and port are unsigned 16-bit numbers (between 0 and 65535). Target is a domain name.

Priority works similarly to the preference in an MX record: the lower the number in the priority field, the more desirable the associated target. When searching for the hosts offering a given service, clients should try targets with the same priority value before trying those with a higher value in the priority field (lower priority values indicate higher priorityconfusing, eh?).

Weight allows zone administrators to distribute load to multiple targets. Clients should query targets at the same priority in proportion to their weight. For example, if one target has a priority of zero and a weight of one and another target has a priority of zero but a weight of two, the second target should receive twice as much load (in queries, connections, etc.) as the first. It's up to the service's clients to direct that load: they typically use a system call to choose a random number. If the number is, say, in the top one-third of the range, they try the first target, and if the number is in the bottom two- thirds of the range, they try the second target.

Port specifies the port on which the service being sought is running. This allows zone administrators to run servers on nonstandard ports. For example, an administrator can use SRV records to point web browsers at a web server running on port 8000 instead of the standard HTTP port (80).

Finally, target specifies the domain name of a host on which the service is running (on the port specified in the port field). Target must be the canonical name of the host (not an alias), with address records attached to it.

So, for the movie.edu FTP server, we might add two SRV records to the movie.edu zone. Adding the first with the DNS console is shown in Figure 11-2.

Figure 11-2. Adding an SRV record with the DNS console

After adding the second record, the movie.edu zone data file ( movie.edu.dns ) contains these records:

 _ftp._tcp.movie.edu.  IN  SRV  1  0  21  plan9.fx.movie.edu.                       IN  SRV  2  0  21  thing.fx.movie.edu. 

This instructs SRV-capable FTP clients to try the FTP server on plan9.fx.movie.edu 's port 21 first when accessing movie.edu 's FTP service and then to try the FTP server on thing.fx.movie.edu 's port 21 if plan9.fx.movie.edu 's FTP server isn't available.

The records:

 _http._tcp.www.movie.edu.  IN  SRV  0  2  80   www.movie.edu.                            IN  SRV  0  1  80   www2.movie.edu.                            IN  SRV  1  1  8000 postmanrings2x.movie.edu. 

direct web queries for www.movie.edu (the web site) to port 80 on www.movie.edu (the host) and www2.movie.edu , with www.movie.edu getting twice the queries www2.movie.edu does. If neither is available, queries go to postmanrings2x.movie.edu on port 8000.

But don't get excited and add SRV records for your FTP and web servers: few clients actually use SRV records to locate their servers. In fact, we're not aware of any FTP clients or web browsers that look up SRV records. On the other hand, when Microsoft was looking for a way to have Windows 2000 clients find their domain controllers, SRV records fit the bill perfectly . DNS resource records needed by a domain controller

A Windows 2000 client needs to reach several services on its domain controller. Clients communicate with Active Directory itself using the Lightweight Directory Access Protocol (LDAP). [2] Authentication and authorization are handled by Kerberos. [3] A domain controller needs DNS to "advertise" the availability of these services. The resource records needed by the movie.edu Active Directory domain look like this:

[2] LDAP is an Internet standard defined in RFC 2251.

[3] Kerberos is also an Internet standardsee RFC 1510.

 movie.edu. 600 IN A _ldap._tcp.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu. _ldap._tcp.pdc._msdcs.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu. _ldap._tcp.6e10690c-40a2-4383-98a7-c716ef9266d1.domains._msdcs.movie.edu.      600 IN SRV 0 100 389 terminator.movie.edu. 260aad2b-3ce7-41c2-923e-8e7bec165788._msdcs.movie.edu. 600 IN CNAME      terminator.movie.edu. _kerberos._tcp.dc._msdcs.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu. _ldap._tcp.dc._msdcs.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu. _kerberos._tcp.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu. _kerberos._udp.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu. _kpasswd._tcp.movie.edu. 600 IN SRV 0 100 464 terminator.movie.edu. _kpasswd._udp.movie.edu. 600 IN SRV 0 100 464 terminator.movie.edu. _ldap._tcp.Default-First-Site-Name._sites.movie.edu. 600 IN SRV 0 100 389      terminator.movie.edu. _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.movie.edu.      600 IN SRV 0 100 88 terminator.movie.edu. _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.movie.edu.      600 IN SRV 0 100 389 terminator.movie.edu. _kerberos._tcp.Default-First-Site-Name._sites.movie.edu.      600 IN SRV 0 100 88 terminator.movie.edu. _ldap._tcp.gc._msdcs.movie.edu. 600 IN SRV 0 100 3268 terminator.movie.edu. gc._msdcs.movie.edu. 600 IN A _gc._tcp.movie.edu. 600 IN SRV 0 100 3268 terminator.movie.edu. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.movie.edu.      600 IN SRV 0 100 3268 terminator.movie.edu. _gc._tcp.Default-First-Site-Name._sites.movie.edu. 600 IN SRV 0 100 3268      terminator.movie.edu. 

The movie.edu domain has one domain controller, terminator.movie.edu . You can see that the target of every SRV record (that is, the host providing the service) is terminator . Notice the various services provided by terminator : LDAP over TCP, Kerberos over TCP and UDP, etc. For an explanation of the function of each of the records needed by a domain controller, see Microsoft Knowledge Base article Q178169.

Also notice two A records hiding among all those SRV records:

 movie.edu. 600 IN A gc._msdcs.movie.edu. 600 IN A 

The first A record is for LDAP clients that don't understand SRV records. Since Windows 2000 clients do use SRV records to locate the LDAP service on the domain controller, you don't need that domain A record (the one for movie.edu ) unless you're using other LDAP clients. (And even then, you can just point those clients at the domain controller using its fully qualified name: terminator.movie.edu , in this case.) It's good that the A record isn't required, because a lot of folks already have an A record at the apex of their DNS namespace. This record usually points to a web server, not to an Active Directory server. For example, Movie U.'s main web server is accessible via both www.movie.edu and movie.edu . However, note that the second A record, which points to the Global Catalog service on the domain controller, is required.

This discussion begs the question: how do those SRV records get there? Are you dreading that you'll have to type them in yourself? Never fearthe domain controller adds these records to DNS itself, using a recent DNS protocol enhancement called dynamic update. We'll discuss dynamic update soon, along with more details about how domain controllers update DNS with the records they require.

One final note: if we had multiple domain controllers for movie.edu , there would be an additional set of records for each one.

11.1.3 Storing Zones in Active Directory

Zone storage is another Active Directory-DNS integration point. With the previous version of the Microsoft DNS Server in NT Server 4.0 (or a standard BIND name server, for that matter), a name server loads zones from two places. If the name server is a primary master for a zone, it loads that zone from a file on disk. If the name server is a secondary master (or a slave, to use the newer term used by recent DNS- related RFCs), it loads the zone from another authoritative server (usually the primary master) over the network, using a zone transfer. The purpose of this traditional primary/secondary relationship is to facilitate replication. A zone needs multiple authoritative servers for redundancy and to spread the query load. The zone transfer is DNS's built-in replication mechanism: as you know, just change the zone on the primary, and the change eventually percolates to the secondaries.

The Microsoft DNS Server gives you a third option, called Active Directory integration . Rather than being stored in a file on the primary master's disk, the zone data is stored in the Active Directory database. This option is available only when the DNS server is running on a domain controller. The reasoning is that since Active Directory already has its own replication topologya " multimaster " scheme in which each domain controller can accept changes and propagate them to the other domain controllerswhy not just take advantage of Active Directory's replication for DNS zones, rather than designing a separate primary/secondary topology?

There are at least a couple of reasons why you'd want to opt for Active Directory integration for your zones. While it does save you from designing and implementing primary/secondary relationships for all your name servers and zones, the main reason is secure dynamic update. Microsoft has extended the standard DNS dynamic update protocol, allowing it to work with the Active Directory security model, but this feature is available only with Active Directory-integrated zones. Secure dynamic update alone is enough reason to store zone information in Active Directory.

One other note about Active Directory-integrated zones: strictly speaking, you don't have to make every name server for a zone Active Directory integrated. Since all authoritative servers allow zone transfers, a server that loads a zone from Active Directory will happily respond to zone transfers. So you can conceivably make only a zone's primary master name server Active Directory integrated and have the secondaries continue to load from the primary. However, it defeats one of the purposes of Active Directory integrationletting Active Directory handle zone replicationto use traditional zone transfers. The other huge advantage of Active Directory integration is secure dynamic update, which isn't possible if only the primary master is Active Directory integrated. So to take full advantage of Active Directory integration, all name servers for a zone should store the zone in Active Directory.


DNS on Windows 2000
DNS on Windows 2000
ISBN: 0596002300
EAN: 2147483647
Year: 2001
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net