70-240 in 15 minutes a week: Active Directory and DNS - Part 1
May 14, 2001
by Dan DiNicolo
Welcome to article number 13 in my 70-240 in 15 minutes a week series. This week's article is the first in the Active Directory portion of the series and covers a review of Active Directory concepts as well as an overview of DNS. This includes a look at the logical and physical structure of Active Directory, as well as a look at DNS terms, concepts, and new features. This article does reiterate some of the material covered in article number 8 in the series, which introduced Active Directory for the purpose of the Windows 2000 Server section of the 70-240 exam. Next week this topic will be continued, with a look at the actual implementation and administration of DNS, as well as Active Directory domain installation.
The material to be covered in this article includes:
- Review of basic Active Directory terms and concepts
- Logical Structure
- Physical Structure
- DNS Basics overview
- New Features of Windows 2000 DNS
Active Directory Review
As we covered in the Window 2000 Server portion of the series, Active Directory is the directory service of Windows 2000. A directory service is a store of information used for the purpose of both accessing information about objects (such as users, computers, domains, etc) as well as providing authentication and security services. Active Directory is very similar to other X.500-based directory services such as Novell's NDS and Sun's Directory Service, both in terms of basic structure and the services that it provides.
A wide range of objects can be created in Active Directory. An object represents a unique entity with the directory, and is usually made up of many attributes, which help to describe and identify it. For example, a user account is an example of an object. This type of object can have many attributes, including a first name, last name, password, phone number, address, and many others. In the same way, a shared printer can also be an object in Active Directory, and can have attributes such as a name, location, and more. The attributes of an object not only help to identify the object, but also allow us to search for it in the directory. For example, I could search Active Directory for a list of all users with first name Mark (perhaps to find his phone number), and would be returned with a list of all users whose first name attribute value is equal to Mark. Keep in mind that there are many different types of objects to be found in Active Directory - everything from domains, to users, to servers, to sites, to printers, and more. Objects are defined in something called the Schema - this is basically the 'blueprint' that defines the types of objects that can be created in Active Directory. However, you should be aware that it is also possible to define new types of objects and attributes by extending the Schema to meet the needs of your organization. This could include adding a babysitter's phone number attribute to user accounts, or creating a whole new object type called Company Vehicles, for example. Much more on extending the schema later in the series.
Active Directory functions mainly through the use of a protocol referred to as LDAP, the Lightweight Directory Access Protocol. An open and defined standard for accessing directories, LDAP provides the mechanism for updating information, querying, and defining objects in the directory. For example, every object in Active Directory is represented by what is called an LDAP distinguished name. This name uniquely identifies the object within the entire directory. For example, the distinguished name for a user account object named Dan DiNicolo that exists in the Information Technology organizational unit in the win2000trainer.com domain would be:
CN=Dan DiNicolo, OU=Information Technology, DC=win2000trainer, DC=com
An LDAP distinguished name is made up of three main elements
CN - Common Name, the name of the object within Active Directory.
OU - Organizational Unit, the name of the Organizational Unit within Active Directory. Note that built-in containers, such as Users, would use CN= instead of OU= in an LDAP distinguished name.
DC - Domain Component, the DNS domain name in which the object exists, represented one domain level at a time, starting with lower-level domains and ending with top-level domains.
Another two quick examples:
CN=John Doe, CN=Users, DC=domain, DC=com would represent a user object named John Doe whose account exists in the Users built-in container in a domain named domain.com
CN=Jane Doe, OU=Sales, OU=Toronto, DC=canada, DC=company, DC=net would represent a user object name Jane Doe, whose account exists in an OU called Sales, which is a sub-OU of an OU named Toronto, which is in a domain named canada.company.net
Another way of defining objects within Active Directory is via the object's relative distinguished name. Quite simply, a relative distinguished name is just a shorter way of describing an object based on where we are focused. For example, if I were looking in the OU called Sales, which is a sub OU of the OU Toronto, in the canada.company.net domain, I could say that the relative distinguished name of the object I previously described is CN=Jane Doe.
Logical Structure of Active Directory
Active Directory can be considered to have both a logical and physical structure, and there is no correlation between the two. The logical parts of Active Directory include forests, trees, domains, OUs and global catalogs. Each element of the logical structure of Active Directory is defined below:
Domain - a domain in Windows 2000 is very similar to a domain is Windows NT. It is still a logical group of users and computers that share the characteristics of centralized security and administration. A domain is still a boundary for security - this means that an administrator of a domain is an administrator for only that domain, and no others, by default. A domain is also a boundary for replication - all domain controllers that are part of the same domain must replicate with one another. Much like NT 4, trust relationships can exist that allow users from one domain to access resources in another. Domains in the same forest automatically have trust relationships configured, but you should also note that you could create trust relationships to external domains (including NT 4-based domains) if necessary. In Active Directory, domain naming follows DNS naming conventions - domain.com as an example.
Tree - a tree is a collection of Active Directory domains that share a contiguous namespace. In this configuration, domains fall into a parent-child relationship, which the child domain taking on the name of the parent. For example, I could create a child domain named Canada under company.com - making the full name of the domain Canada.company.com. Child domains automatically have a transitive two-way trust relationship configured with their parent. This means that the trust relationship can be used by all other domains in the forest as a means to access the domain. Note that Canada.company.com is still a separate domain in this example, which means that it is still a security and replication boundary. As such, an administrator from company.com cannot administer the Canada.company.com domain unless explicitly granted the ability to do so.
Forest - a forest is the largest unit in Active Directory and is a collection of trees that share a common Schema, the definition of objects that can be created. In a forest all trees are connected by transitive two-way trust relationships, thus allowing users in any tree access to resources in another for which they have been given appropriate permissions and rights. By default the first domain created in a forest is referred to as the root domain. Amongst other things, this is where the Schema is stored by default. You cannot rename or remove the root domain - this will force the removal of your entire Active Directory forest.
Organizational Unit - An organizational unit (OU) is a container object that helps to organize objects for the purpose of administration or group policy application. An OU exists within a domain and can only contain objects from that domain. OU can be nested, which allows for more flexibility in terms of administration. Different methods for designing OU structures exist including according to administration (most common), geography, or organizational structure. One popular use of OUs is to delegate administrative authority - this allows you to give a user a degree of administrative control over just the OU, and not the entire domain, for example.
Global Catalogs - Global Catalogs are listings of every object that exists within an Active Directory forest. By default, a domain controller only contains information about objects in that domain. A Global Catalog server is a domain controller that contains information about every object (though not every attribute for each) stored in the entire forest. This facilitates and speeds up the search for information in Active Directory. By default only the first domain controller created in a forest has a copy of the global catalog - others much be designated manually.
Physical Structure of Active Directory
The physical structure of Active Directory helps to manage the communication between servers with respect to the directory. The two physical elements of Active Directory are domain controllers and sites. Each is described below.
Domain Controllers - domain controllers are Windows 2000 Server-based systems that store the Active Directory database. Every Windows 2000 domain controller has a writable copy of the directory. This is different that in NT 4, where only the PDC had this capability. Domain controllers in the same domain contain replicas of the directory that must be synchronized periodically.
Site - a site is a concept that did not exist in an NT directory service structure. In Active Directory, sites are groups of IP subnets that are connected at high speed. Although the definition of 'high speed' is open, it is generally considered to be subnets that are connected at LAN speeds (say 10 Mb) or higher. The purpose of defining sites in Active Directory is to control network traffic relating to directory synchronization, as well as to help ensure that users connect to local resources. For example, domain controllers located in the same site replicate with one another on a 5-minute change notification interval similar to in NT 4. However, replication between domain controllers in different sites can be scheduled according to your needs. This allows a much greater degree of flexibility that in NT 4. For example, you could set things up such that replication between sites could only happen between midnight and 6am - thus ensuring that replication traffic would not interfere with normal data transfer during business hours. Sites also help ensure that users avoid accessing resources over the WAN by having client systems access servers (such as domain controllers) that are in the same physical site first.
Planning a DNS Implementation for Active Directory
Prior to installing Active Directory in a Windows 2000 environment, it is important to first design a DNS implementation that will meet both your name resolution and Active Directory requirements. Active Directory requires DNS in order to provide both name resolution as well as namespace definition, since domain names in Windows 2000 are based on the DNS naming conventions. As such, any servers on which you are installing Active Directory should have their TCP/IP properties configured to be pointing at a DNS server that you have already configured. If you choose not to do this, the installation of Active Directory will automatically create a DNS structure for you, which may not meet your needs.
Since a basic introduction to how DNS queries work was already covered earlier in the series, I am not going to repeat it here. Instead I am going to cover the main areas of DNS that you'll need to understand in order to successfully implement the service for the purpose of supporting both name resolution and especially Active Directory.
The first concept that you'll need to be familiar with is the use of DNS to resolve hostnames or fully qualified domain names to IP addresses. As a quick reminder, a fully qualified domain name (FQDN) provides the hostname as well as the domain name of a system. For example:
In this example, the hostname is the leftmost portion, or www. Hostnames can also be resolved using a HOSTS file, which is a static text file that exists in the %systemroot%\system32\drivers\etc directory on the local machine. DNS should not be confused with WINS, which maps Netbios names to IP addresses (as does the text equivalent, LMHOSTS).
DNS stores a number of different types of resource records beyond simple host or 'A' records. The most popular resource records that you'll find in a zone file are outlined below:
SOA - represents the Start of Authority for a zone, and provides information about the zone including which server is the primary, who the administrative contact is, how often zone database files are checked for changes, database serial numbers, time to live values, and more.
A - represents a unique host address on the network, mapping its hostname to an IP address.
NS - outlines a domain name and the corresponding FQDN of name servers that are authoritative for that domain.
MX - designates that a given host is a mail exchanger (mail server or forwarder) for the domain specified.
PTR - provides reverse lookup capabilities by mapping the reversed IP address of a host to an FQDN. This allows the hostname associated with an IP address to be found. PTR records are found in reverse lookup zone files.
SRV - maps a particular service to one or more hosts. For example, records can indicate a server as a Global Catalog server, domain controller, and so forth.
The second main concept you'll need to be familiar with is that of a zone. A zone is basically an area of the DNS namespace that functions as an administrative unit. That is, a group of name servers are responsible (have authority) for the records relating to a certain domain and/or subdomains. I like to refer to zones as areas of responsibility. For example, I could create a zone for the domain win2000trainer.com, and create 2 servers that would be responsible (authoritative) for holding records for the defined zone. I could then create a different zone, to be managed by someone else, for the domain asia.win2000trainer.com, and have 2 other servers (maybe in Asia) that are responsible (authoritative) for the records in that zone. However, a zone can also encompass a number of domains, as long as they fall within a contiguous namespace. For example, win2000trainer.com and asia.win2000trainer.com could be part of the same zone, and have a number of servers responsible for holding records relating to the two domains. If a query was sent to these DNS servers looking for a record ending in win2000trainer.com or asia.win2000trainer.com, these name servers could answer the query, since they are authoritative for the zone, which includes the two domains. The main reason for having multiple zones usually relates to administrative authority, as well as zone transfer traffic. For example, perhaps I have one DNS administrator in Canada and one in Asia. Then, two zones may be warranted. By the same token, if I had only one zone, then all DNS servers (perhaps two in Canada and two in Asia) would all need to participate in zone transfers in order to receive updates. This may cause an unacceptable level of WAN traffic.
As a general rule, 5 main types of DNS servers exist which you should be familiar with. These are primary, secondary, active-directory integrated, forwarding, and caching-only. Each is described below:
Primary DNS Server - a primary DNS server is the name server that is authoritative for a zone. Essentially what this means is that this is the only server on which updates to the zone database can be made.
Secondary DNS Server - a secondary DNS server contains a read-only copy of the information stored on the primary name server, and obtains updates via zone transfers. A single secondary is the minimum suggested requirement, but many more can be created for the purposes of load-balancing and fault-tolerance.
Active Directory Integrated - limited to Windows 2000-based DNS servers, this implementation of DNS stores the zone file as an object within Active Directory instead of a series of files on the hard drive. In this scenario, every domain controller running DNS essentially acts as a primary DNS server, allowing updates to the zone file, and handling zone file synchronization via directory replication. As such, if any DNS server should fail, any other AD-integrated server can continue to make updates.
Caching-Only - a caching only DNS server is not authoritative for any zone. As such, it simply takes client queries, performs queries on other DNS servers, caches the results, and passes the answers to clients. By default, a caching-only DNS server will forward all queries for information not found in cache to DNS root servers.
Forwarder - DNS servers can be configured to sent queries that they cannot resolve to other specific DNS servers, referred to as forwarders. The forwarders will then work to resolve the query, instead of the individual DNS servers. This allows the number of requests sent to find hosts (on the Internet for example) to be reduced over time, as the forwarder handles these requests and caches the results, which are subsequently returned to the DNS servers making the request. The can improve both speed and efficiency.
New Features of Windows 2000 DNS
In the Windows 2000 DNS implementation, a number of changes have been made. The most important include support for service records, dynamic DNS, secure dynamic updates, incremental zone transfer, and Active Directory integration. Each of these is described below:
Service Records - Windows 2000 DNS implementation provides support for an important type of resource record, service records (often referred to a SRV records). Service records allow a client to query DNS looking for a system running a particular service, such as a global catalog (which is designated by a GC record).
Dynamic DNS - In a traditional DNS implementation, all records needed to be created and updated manually on the DNS server, which could be extremely time consuming. The Windows 2000 implementation supports RFC 2136, usually referred to as Dynamic DNS or DDNS. In this implementation, clients are capable of automatically updating their records, which is especially useful in environments where clients use DHCP for IP address allocation. Windows 2000 is the only current Microsoft client OS that supports dynamic updates. However, it is also possible to configure a Windows 2000 DHCP server such that it updates DNS on behalf of clients, thus allowing non-Windows 2000 client information to be updated in DNS. Dynamic DNS is also especially useful for domain controllers, who can automatically register their service records - otherwise, all of these would need to be created manually.
Secure Dynamic Updates - if a DNS zone is Active Directory integrated, Windows 2000 allows you to use something called secure dynamic updates. Note that dynamic updates can potentially be dangerous because any client could potentially be registered in DNS, since dynamic DNS is only looking for a request, and is not authenticating the request. If secure dynamic updates are enabled, only a user or system that has the appropriate permissions on the associated access control list (ACL) for the zone can add a system to DNS. By default, the Authenticated Users group has these permissions. Client systems will attempt to use an unsecured request first by default, and a secure update if refused.
Incremental Zone Transfer - NT 4 DNS implementations only supported AXFR, or full zone transfers. Under this configuration, every time a primary name server did a zone transfers with a secondary, the entire zone database file was transferred, even if there were only a single change. Windows 2000 DNS supports IXFR, or incremental zone transfers. In this implementation, only the changes are passed during the zone transfer, as opposed to the entire zone database file.
Active Directory Integration - Windows 2000 still supports the traditional primary / secondary implementation of DNS. In that scenario, changes to the zone file could only be made on the primary, which had the only writable copy. Windows 2000 introduces a new concept here - Active Directory Integrated DNS. In this implementation, the DNS zone file and associated information is stored as objects in Active Directory instead of as files in the DNS directory on the hard disk. This integration basically allows any domain controller running DNS to accept changes to the DNS database, with changes to the zone file replicated as part of Active Directory replication. This also helps make DNS more fault-tolerant. In a traditional DNS environment, if the primary name server were to fail, all dynamic updates to DNS would be denied, since the writable copy would not be available. In AD-integrated DNS, all DNS servers are capable of handling an update. Note that legacy DNS servers can continue to exist - they can be secondaries, using the AD-integrated DNS server as a primary.
That ends part one of the first article in the Active Directory portion of the series. I apologize for splitting this topic in half, but the alternative was one very long article. Next week I'll continue with a focus on the implementation-related aspects of DNS and Active Directory. This will include a look at the actual installation and configuration of DNS, as well as the installation of Active Directory. I hope you are enjoying the series so far and finding it useful. As always, I look forward to your comments and feedback -
I can be contacted here. I also hope that you'll make use of
board, where I (and others!) take the time to answer your questions as you study. Best of luck with your studies this week.