Welcome to article number 14 in my 70-240 in 15 minutes a week series. This week's article covers part 2 of Active Directory and DNS, completing the topics begun last week. This article covers the implementation aspects of Active Directory and DNS.
by Dan DiNicolo
Welcome to article number 14 in my 70-240 in 15 minutes a week series. This week's article covers part 2 of Active Directory and DNS, completing the topics begun last week. This article covers the implementation aspects of Active Directory and DNS. This includes a look at the configuration of zones and zone properties in DNS, troubleshooting tools for DNS, as well as the installation of Active Directory domain controllers and related properties. Again, this topic ties into the Active Directory Implementation and Administration portion of the exam.
The material covered in this article includes:
- Service Records and locating domain controllers
- Configuring DNS zones properties
- DNS troubleshooting tools
- Installing Active Directory
- Troubleshooting the Active Directory Installation
Service Records and Locating Domain Controllers
Windows 2000 Active Directory requires DNS to function correctly. DNS support for SRV records is the only absolutely mandatory requirement for Active Directory to function. However, it is also recommended that your DNS server support dynamic updates, since domain controllers dynamically register a number of records in DNS. If your DNS servers do not support this, you would need to set up all required service records for all domain controllers manually, a potentially long and arduous process. Windows 2000 DNS supports both, as well as incremental zone updates
(IXFR). IXFR is useful in that it allows DNS servers to simply replicate zone changes instead of the entire zone file as in
AXFR-based implementations (NT 4 DNS, for example). It is also worth noting which versions of BIND (the popular Unix-based DNS server) support the above requirements:
BIND 4.9.7 - supports SRV records
BIND 8.2.1 - supports SRV records, Dynamic Update, IXFR
An understanding of the SRV records and related domains that you will find (or require) in a DNS implementation to support Active Directory is also important. Just to reiterate, Windows 2000 uses service records in DNS to locate domain controllers in specific domains, domain controllers in the same site, global catalog servers, key distribution centers, and more. A service record uses a standard record format, an example of which is shown below:
_service._protocol.name ttl class SRV priority weight port target
_Service represents the name of the service that a domain controller is running, such as ldap (for a domain controller), gc (for a global catalog server), kerberos for a key distribution center, and so forth.
_Protocol specifies the transport protocol used, such as TCP or
Name specifies the domain name relating to the record, for example win2000trainer.com
Ttl specifies the time to live value, in seconds
Class specifies the DNS record class value, almost always 'IN' for Internet.
Priority specifies the priority level of the server. Clients will attempt to contact the server with the lowest priority value.
Weight is a load-balancing feature. If multiple servers have the same priority, clients choose SRV records with higher weights.
Port specifies the port number that a particular service listens on.
Target specifies the FQDN of the host running the service
As such, a domain controller with FQDN dc1.win2000trainer.com acting as a global catalog server would have a service record (as well as many others) as shown below:
_gc._tcp.win2000trainer.com 600 IN SRV 0 100 3268 dc1.win2000trainer.com
Domain controllers register their service records when their Netlogon service starts. As such, stopping and starting the domain controller's Netlogon service can accomplish re-registration of all SRV records. You should also familiarize yourself with the different subdomains that are created beneath a domain in a Windows 2000 DNS implementation. The four main subdomains created are:
_msdcs - this subdomain is used to allow clients to find domain controllers providing specific services and running Windows 2000.
_sites - this subdomain is used to allow clients to find domain controllers providing specific services in a specific site.
_tcp - this subdomain lists services provided that use the TCP protocol to communicate.
_udp - this subdomain lists services provided that use the UDP protocol to communicate.
Service records and related entries can be verified by using both the DNS MMC snap-in, as well as by querying DNS using
nslookup.exe. The syntax to query a DNS server for a list of all service records for a given domain is shown below:
>ls -t SRV win2000trainer.com
Configuring the DNS Server for Active Directory Support
Aside from the details listed above, it is important to understand how to create an initial DNS zone to support Active Directory. This should be done in advanced of installing Active Directory, in order to ensure that things are configured as you wish them to be. If you do not configure the zone in advance, the installation wizard will automatically do it for you, and the installation may not meet your needs.
Configuring a zone first involves installing the DNS service via the Add/Remove Windows components wizard. After doing this, open the DNS tool and you should see a configuration as shown below:
By default the server will act as a caching-only server, simply
forwarding queries to root servers when an answer cannot be
found in cache. However, in order to support AD, a zone must be
created that will be authoritative for the Active Directory
domain that is to be installed. A wizard does exist to walk you
through the process (right click and choose Configure the
Server) if you choose that method. However, right-clicking the
forward lookup zone and choosing New Zone will open the New Zone
wizard, which I will cover here. By default, three options exist
for zone types to be created, as shown below:
the option for an Active Directory-integrated zone is
unavailable since Active Directory has not yet been set up.
Choosing a standard primary would be our only real option, since
a secondary requires a primary to exist. This primary zone can
later be changed to AD-integrated as we'll see in a bit. The
zone must be named, so I have chosen win2000trainer.com, which
will create a zone file called win2000trainer.com.dns. Notice
that the zone file exists under the Forward Lookup Zone area in
the screen below:
After creating a zone, ensure that the TCP/IP properties of the server
you wish to promote to a domain controller point to this newly
created DNS server (it may be the same system). Also note that
the properties on the zone can be accessed to change settings
such as the zone type (which can be changed once we install AD),
support for dynamic updates (disabled by default), SOA, Name
Server, WINS, and Zone Transfer information, as shown below:
Note that the properties configured for a zone are different than those configured for a DNS server, which may support many zones. Properties for a DNS server are shown below, allowing you to control elements including the configuration of interfaces, forwarders, advanced properties, root hints, logging, and monitoring.
Note that dynamic updates are not allowed by default. You'll need to change this in order for domain controllers to automatically register their service records.
Also remember that a zone can only be compromised of domains in a contiguous namespace. As such, if you wanted to support domains called test.com and win2000trainer.com from the same DNS server, you would be required to created separate zones. However, a single zone could handle the domains win2000trainer.com and research.win2000trainer.com without issue.
Although not required for Active Directory support, it is also good practice to create reverse lookup zones for all forward lookup zones created, since these provide IP address to hostname resolution services. A reverse zone name will be in a format that reverses the network portion of the IP address range in use, and appends the reverse-lookup domain name. For example, the domain name for a reverse zone that supports network 192.168.0.0 would be 168.192.in-addr.arpa. You should also enable dynamic updates for this zone in order for reverse records to be added automatically.
Troubleshooting DNS servers
Three main options exist for troubleshooting DNS servers that you should be aware of. The first is the monitoring tab on the properties of the DNS server, as shown below:
This tool allows you to pass queries to the DNS server to ensure it is functioning correctly. A simple query is passed only to this server for resolution, and will either pass or fail. A recursive query is one in which a DNS server will attempt to query other DNS servers to obtain an answer, which will again be presented as a pass or fail. This tool can also be used to test DNS on a regular basis, as specified by the test interval.
DNS logging can also be used for troubleshooting purposes, as it will log when certain DNS events occur. Found on the Logging tab of a DNS server's properties, all output is saved to a text file called
dns.log located in the %systemroot%\system32\dns folder on the server. Note that excessive logging may have a negative impact on server performance, and as such should only be used for troubleshooting purposes.
More commonly, Nslookup is the tool used to query a DNS server. This command line utility allows you to search for resource records relating to a domain. Use the /? option for a list of supported commands.
Installing Active Directory
One of the major improvements between Windows 2000 and Windows NT 4 is the fact that the decision on whether or not a server becomes a domain controller is made independent of the actual OS installation. As such, turning a member server into a domain controller (or vice-versa) is something that can be done without needing a complete reinstallation. The tool used to install (or uninstall) Active Directory on a server is the Active Directory Installation Wizard, dcpromo.exe. The section takes a look at the various decisions to be made throughout the wizard.
Before getting started, there are a few important requirements that you need to be aware of, as listed below:
- The system must be running Windows 2000 Server, Advanced Server, or Datacenter Server
- AD installation requires a minimum of 200 MB disk space for the AD database, and 50 MB for the transaction log files. These can be placed on FAT. FAT32, or NTFS partitions
- The server must have at least one NTFS partition, to house the SYSVOL folder.
- TCP/IP installed and configured to use DNS is required
- Appropriate administrative privileges are required.
The Active Directory installation wizard can be used for a few different purposes, and you should be aware of the reasons. These include creating a new forest (a new root domain), adding a domain controller to an existing domain, creating a new tree, and creating a new child domain. It is very important to pay attention during the wizard to ensure that you are making the correct choices, especially when creating the root domain of the forest, since this cannot be renamed for example. For the purpose of this article, I will cover the installation of a new root domain. You should familiarize yourself with the other options, however.
The wizard begins by asking if you are creating a new domain, or adding a domain controller to an existing domain. The second option is less involved, since the domain will already have been created.
choosing to create a new domain, we are presented with the
option of creating a new domain tree (as we are going to choose
since we are creating a new forest root), or creating a child
choosing to create a new tree, we must choose whether we wish to
create an entirely new forest, or add this tree to an existing
forest. Note that creating a new forest creates an entirely new
domain (in our case the root domain) must be named according to
DNS naming conventions. Since I have already created the
associated DNS zone, I will not be prompted with any errors, and
the wizard will not offer to create the zone for me. The second
screen after providing the domain name asks for the name is
Netbios format (provided by default and truncated to 15
characters if necessary) for older clients such as 95, 98 and
NT, who still rely on Netbios for things like logon.
decision is with respect to where the AD database and associated
log files should be placed. Make note of the fact that for best
performance, these should be placed on separate hard disks if
possible. By default they are both placed in the %systemroot%\NTDS
decision is to choose the location of the SYSVOL, the folder
that contains files relating to the domain such as group policy
objects, logon scripts, etc. This must be a NTFS partition, and
will be replicated by the file replication service (FRS)
next step is something that you must pay attention to,
especially if your environment still has NT 4 -based
application services in use (RAS for example). A remote access
server will need to check user properties in Active Directory,
and if the first option shown below is not chosen, the NT 4 RAS
server will not be able access the information, since RAS using
a null session to communicate with the domain controller. Note
that this 'loosening' of permissions could allow an
anonymous user to read some information in Active Directory.
will also need to choose a password to be used when this
server's administrator account for the purpose of accessing
directory services restore mode (from the advanced startup menu)
After all of the information has been entered, you are given an opportunity to review what has been selected, and upon confirming the domain is created. The domain controller installation process can also be automated with an unattended install. The syntax is
dcpromo.exe /answer:answerfilename. For a look at the syntax of the dcpromo answer file, check the file unattend.doc in the deploy.cab file found in the \support\tools directory of the Windows 2000 CD.
Note that the domain controller will register a variety of service records in DNS. These should be verified, either by viewing them with the DNS tool or by doing an Nslookup query for SRV records as described earlier. It is also worth checking for the existence of the appropriate files in the NTDS directory (as shown below), reviewing the log files in event viewer, and ensuring the existence of the SYSVOL directory.
Note that NTDS.dit is the actual AD database, while the
edb.* files are the transaction logs and checkpoint files. The
res*.log files are reserved log files, used for transaction logging should the server run out of disk space.
The installed domain controller will add a computer object to the domain controllers OU for the domain. It will also add a server object to the appropriate site (depending on what has been created) in Active Directory Sites and Services, based on its subnet address. By default the first domain controller in a new forest will be created in a site called Default-First-Site-Name (literally), and can be moved once you create other sites (discussed later in the series).
A new domain controller holds all three partitions of Active Directory - domain (domain object information), configuration (information about sites and services), and schema (definition of all object and attribute classes). If this is the first domain controller in a forest, it will also be a global catalog server, holding the global catalog partition (all objects in the forest and a subset of attributes) as well.
Note that the first domain controller in the root domain will house all operations master roles:
Domain Naming Master
By the same token, the first domain controller in each new domain will hold the following three roles:
Of course, these roles can be changes to other domain controllers, and often should based on resource usage. As a rule, you should ensure that the Infrastructure Master is not a global catalog server, since this will impact the validity of user-to-group references.
Something else that you should note is that after installing the first domain controller in a domain, the domain will still be in Mixed Mode. Mixed Mode exists for the purpose of backwards compatibility with NT 4 BDCs. However, even if you are installing a new domain from scratch, it will be installed in Mixed Mode. In order to realize many of the benefits of Active Directory, including the ability to
nest groups, use universal groups, and have the SID history attribute saved, you will need to be in Native Mode. This change is made on a domain-by-domain basis, not once for the whole forest as many people mistakenly think. To change a domain from Mixed Mode to Native Mode, use Active Directory Users and Computers (or Active Directory Domains and Trusts) by choosing the domain properties.
Note that the change from Mixed Mode to Native Mode is a one-way process and cannot be reversed.
Active Directory Troubleshooting
A few notes with respect to troubleshooting Active Directory installation problems:
1. There must be sufficient disk space to install Active Directory as outlined above. If you receive an error message stating there is not enough space, you will need to delete files to create space, or create an additional volume. Be sure that there is also an NTFS partition available, and use the convert.exe command on an existing FAT partition if necessary.
2. When creating a new domain, you will need to ensure that the DNS and Netbios names of the domain are unique. If they are not, the creation cannot proceed.
3. You must have the correct privileges to install a domain controller. To create a new forest, you will only need to be a local administrator. By default, to add a child domain to an existing forest (or any new domain), you must be a member of Enterprise Admins. To create a new domain controller in an existing domain, you must be a member of Domain Admins.
4. If you get a domain not found error when adding a domain controller to an existing domain, be sure that at least one domain controller is available and that it has properly registered its SRV records in DNS.
5. In order to remove the last domain controller in a domain, you must be a member of the Domain Admins group for that domain. The last domain controller in the root domain cannot be removed if child domains still exist.
That's it for another week. Next week we'll continue in the Active Directory portion of the series with a look at User and Group Administration. Thanks again to all who have contacted me with words of support for the series, I'm glad that you are finding it useful. As always, feel free to contact me with questions and comments, although please note that all technical questions must be posted to my
board, for the benefit of everyone. Until next week, best of luck with your studies.
This article was originally published on Tuesday May 15th 2001