Configuring DNS to Support Active Directory

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 the default configuration.

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.

Note that 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 2000trainers.com, which will create a zone file called 2000trainers.com.dns.

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.

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 2000trainers.com from the same DNS server, you would be required to created separate zones. However, a single zone could handle the domains 2000trainers.com and research.2000trainers.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.

DNS 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 UDP.

Name specifies the domain name relating to the record, for example 2000trainers.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.2000trainers.com acting as a global catalog server would have a service record (as well as many others) as shown below:

_gc._tcp.2000trainers.com 600 IN SRV 0 100 3268 dc1.2000trainers.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:

C:\Nslookup
>ls –t SRV 2000trainers.com

Changes to DNS in Windows 2000

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.

Planning DNS 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:

www.2000trainers.com

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 –represent 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 2000trainers.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.2000trainers.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, 2000trainers.com and asia.2000trainers.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 2000trainers.com or asia.2000trainers.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.

Active Directory Logical and Physical Components

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.

Active Directory Distinguished Names

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.

Using IPSec to Secure TCP/IP Traffic

Windows 2000 supports IPSec, which can provide for secure network communication between clients by encrypting IP-based data and using Kerberos for authentication. The beauty of IPSec is that is not application-based encryption (which would require that an application on both the sending and receiving computer supported encryption) but rather network-stack based. As such, any TCP/IP-based application is capable of utilizing IPSec, because encryption (and decryption) actually happens in the protocol stack. As such, the encryption is completely application-independent and totally transparent to the user.

Windows 2000 supports IPSec in two modes – transport mode and tunnel mode. In tunnel mode, two endpoints (IP addresses) must be defined, and IPSec will encrypt data (it can also be used for authentication of systems only) that travels through the tunnel. This setup is commonly used in connecting remote offices via VPNs over the Internet. Note that the systems communicating need not necessarily be Windows 2000-based, since IPSec is an open standard. In transport mode, policies can defined which designate when and how IPSec encryption should be used on the network. For example, you could specify that only traffic moving from a client to TCP ports 80 or 23 on a server must be encrypted, and that all other traffic need not be. Similarly, you could specify that a client must initiate encrypted communication with a server or the server will not respond. The level and degree of IPSec use on your network is only dictated by your own needs (don’t forget that any encryption will create CPU overhead).

Security Templates

Another MMC snap-in, Security Templates, allows you to view and configure template settings, as well create new templates. Templates files are in an .inf format, readable in any text editor. A small example of the password policy settings of a template file are shown below:
[System Access]
;----------------------------------------------------------------
;Account Policies - Password Policy
;----------------------------------------------------------------
MinimumPasswordAge = 0
MaximumPasswordAge = 42
MinimumPasswordLength = 0
PasswordComplexity = 0
PasswordHistorySize = 0
RequireLogonToChangePassword = 0
ClearTextPassword = 0

Windows 2000 provides a number of templates by default. You should have an understanding on the provided template files and why you would use them. The names of templates provide an idea of when/how they are to be used. The last two letters in the template file name (before the .inf extension) usually tell you which type of system a template is meant for – WS for a workstation, DC for a domain controller, SV for a server. For example, the hisecws.inf identifies the template as applying highly secure settings to a workstation. Beyond this, there are five main security levels outlined in the default templates, with each outlined below:

Basic*.inf – Basic. These templates apply the default security configuration to a system. These would be useful if you set too high a level of security on a system and wanted to return settings back to the default.

Compat*.inf – Compatible. Windows 2000 gives members of the Users group more strict security settings than in NT 4.0. As such, some applications (such as those certified for NT 4 but not Windows 2000) may not function correctly (or potentially at all) on Windows 2000. When this template is applied, applications run under the Power Users level of privilege, even though the user may not have that level of access.

Secure*.inf – Secure. Contains settings recommended for securing a system except for those relating to files, folders, and registry keys, which are configured securely by default.

Hisec*.inf – Highly Secure. Provides settings to provide a much higher level of protection, including network security. In this configuration, a system can only communicate with other Windows 2000-based systems, for example.

Dedica*.inf – Dedicated Domain Controller. Contains recommended security settings for a domain controller that is not also acting as an application server.

Template files are stored in %systemroot%\security\templates by default.

Security Configuration and Analysis

Windows 2000 provides an MMC snap-in tool for analyzing the security configuration of a system. The Security Configuration and Analysis snap-in allows you to compare the current configuration of a system with settings found in security template files, pointing out inconsistencies between the two settings. Although a system can be configured using this tool, it is usually better to export settings to a template file, which can then be deployed to multiple systems using Group Policy in an Active Directory environment. However, settings can be configured on a system-by-system basis if required.

The Security Configuration and Analysis tool requires a working database in which to store system configuration information for the purpose of the comparison. This file has an .sdb extension, and must be opened (or created if starting from scratch) prior to importing a security template for the purpose of comparison. After the .sdb file has been created, one of the pre-defined security templates provided with Windows 2000 can be imported, as can any templates that you have created. Imagine that you wanted to check and see whether a certain system on your network met the requirements of your pre-defined enterprise-wide security settings that you have stored in a template. You could simply open a new .sdb file, and then import the template and compare the security settings to those on the system. The analysis will literally show which settings meet, do not meet, or are not defined in the template you imported. As shown below, the password policy on my system does not meet many of the requirements mapped out in a provided template called securews.inf (more on templates coming up).

RAID and Fault Tolerance

Windows 2000, like Windows NT 4.0, still supports what is commonly referred to as software RAID, or Redundant Array of Independent Disks. In software RAID, the OS handles all RAID functions, and the system does not require a separate RAID controller card. Although the software method is less expensive, it is certainly slower and less reliable than traditional hardware RAID. Windows 2000 supports three types of RAID as described below. Note that all RAID configuration is handled via the Disk Management MMC tool.

RAID 0

Now referred to as a ‘striped volume’, this is usually used to speed up access to data. In this configuration, which supports between 2 and 32 physical disks, data is striped evenly across the disks, which act as a single logical volume. Although the name suggests redundancy, there is in fact no redundancy in a RAID 0 configuration. Should a single volume in the striped volume fail, access to data on that volume will be lost. In Windows 2000, new striped volumes can only be created on dynamic disks, although existing stripe sets from NT 4.0 can continue to exist on basic disks in the case of an upgrade. Essentially that means you can have stripe sets if you upgraded, but cannot create new RAID 0 until you upgrade all hard disks that you wish to be part of the new configuration to dynamic disks. Note that neither the system nor boot partitions can reside on RAID 0 volumes.

RAID 1