4. Using Windows Server 2003 AD Application Partitions for DNS Zone Information
AD application partitions are a new feature of
Windows Server 2003. Data added to the AD is replicated by default to
all domain controllers in the domain. However, this is not always a good
idea and can create a performance issue because of excessive
replication. If application data is not required on all domain
controllers, consider the use of application partitions.
4.1. Using application partitions
DNS data is one type of data that may be constrained to application partitions
. When DNS is integrated with AD, all zone information is stored in the
AD and replicated by default to all DCs. Each DC does not, however,
automatically become a DNS server, nor is this required. Therefore, it
may not be necessary to replicate DNS data to every DC.
Two application partitions for DNS data (a
domain-wide DNS application partition, and a forest-wide DNS application
directory partition) are automatically created when the DNS server
service is created during the dcpromo process on the first Windows
Server 2003 DC in the forest. For all other domains, the domain-wide
application partition is created when the DNS service is installed on
the first Windows Server 2003 DC in the domain. The domain-wide
application partition is unique for each domain and is replicated to all
DCs in that domain that are running the DNS service.
The forest-wide application partition is
replicated to all DCs in all domains that are running the DNS service.
It is also possible to create a custom DNS application directory
partition. A custom application directory partition for DNS will
replicate its data to those DCs that enlist in the partition. These
various partitions, along with the domain partitions, are referred to as
DNS replication scopes
.
By default, the Locator DNS resource records for the domain are stored in _msdcs.DnsDomainName
subdomain for the domain. This subdomain is automatically created when
the DNS root domain of a new AD forest is created on a Windows Server
2003 DC and is stored in the forest-wide DNS application directory
partition.
The
domain partition is the only DNS replication scope available to Windows
2000 DCs. Windows 2000 DCs cannot access data in Windows Server 2003
application directory partitions. If Windows 2000 AD-integrated DNS
servers must coexist with Windows Server 2003 AD-integrated DNS servers,
you must change the DNS replication scope of the Windows Server 2003
DNS server to "To all domain controllers in the AD domain domain_name." |
|
4.2. Migrating from Windows 2000 to Windows Server 2003
When migrating from Windows 2000 AD to Windows
Server 2003 AD, you can reduce replication traffic and reduce the amount
of material stored in the global catalog by changing the replication
scope of the DNS zone information to the DNS application directory
partitions.
To change DNS replication scope, first upgrade
all Windows 2000 DCs to Windows Server 2003. Ensure that the domain
naming master is hosted on a Windows Server 2003 DC. If there is an
existing _msdcs.forestroot_domain zone
on DNS, move it to the forest-wide DNS application directory partition.
Open the DNS console on a DC that hosts a DNS server in a domain.
Right-click on the DNS zone that uses the FQDN of the AD domain and
select Properties. Click the Change button for "Replication: All domain
controllers in the AD domain." Click "To all DNS servers in the AD
domain domain_name." Click OK. Repeat the DNS console steps for each
domain.
DNS isn't the only network service that can
impact the operation of AD. Much of AD's operation assumes synchronized
time between member computers. The windows time service
can ensure that time is synchronized.
5. Configuring the Windows Time Service
Many operations in an AD environment depend on
synchronized time. For example, Kerberos requires that time be
synchronized between server and client. (By default, if the time on the
client is off by more than five minutes from that of the server,
Kerberos logon will fail.) Other computer-to-computer operations will
not succeed if the time on both ends of the connection is not close.
Additionally, the date stamp on log files should be accurate to assist
in troubleshooting and for incident investigation.
Windows Server 2003 includes the W32Time services, which is an implementation of the Network Time Protocol (NTP)
. A standalone server can be directed to synchronize with an
Internet-available timeserver, or with a local hardware clock. In an AD
domain, synchronization follows a hierarchical structure that
incorporates the following:
Windows client computers and member servers typically use their authenticating domain controller as their inbound time partner
(the computer with which they synchronize their time).
DCs in a domain typically use the PDC emulator for the domain as their inbound time partner.
PDC emulators select their inbound time partner as the PDC emulator in their parent domain.
The
PDC emulator for the forest root-domain is the authoritative timeserver
for the forest and should be configured to synchronize time with an
Internet-available timeserver, or with a local hardware clock.
The
maximum positive and negative time changes that will be made during
synchronization can be configured in the registry. This capability is
meant to allow for reasonable automatic changes caused by imperfect
clocks and time latency across networks. Keeping these values small will
prevent the introduction of large time changes that could seriously
impact operations and produce time gaps (as well as wildly divergent
time stamped log data).
If a time change is necessary, the event is logged.
Time
services available on the Internet are not authenticated. It is
possible to spoof such services and, therefore, provide misinformation.
In a Windows forest, this means all computers would eventually adopt an
incorrect time. To secure time operations, use a hardware clock such as a
GPS receiver with time outputs. |
|
5.1. Synchronizing with an external time source
To synchronize the PDC emulator of the domain
with an Internet-based time source (or some other network-locatable time
source), you should complete the following registry entries:
Change the server type to NTP by changing the Type value to NTP at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\Par-ameters\.
Set the AnnounceFlags value to 5. This value is located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\.
Enable the NTPServer by changing the Enabled value to 1 at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\Ntp-Server.
Specify a time source by modifying the NtpServer value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters. Change the value from time.windows.com,0x1 to a list of URLs that indicate the external timeservers. Append 0x1 to each DNS name.
Select a poll interval by editing the SpecialPollInterval value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient\. Change the value to a number that represent the time in seconds.
Configure time correction by changing the value MaxPosPhaseCorrection at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\. Change the value to the time in seconds. The MaxPosPhaseCorrection is the largest possible positive time correction in seconds that the service makes. A reasonable value might be 3600 (1 hour) or less, depending on the poll interval, network conditions, and external time source.
Complete the configuration of time correction by changing the value MaxNegPhaseCorrection at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\. Change the value to the time in seconds. The MaxNegPhaseCorrection is the largest possible positive time correction in seconds that the service makes. A reasonable value might be 3600 (1 hour) or less, depending on the poll interval, network conditions, and external time source.
At the command prompt, stop and start the Windows Time service by using the command net stop w32time && net start w32time.
Many
of the entries mentioned here can be set using Group Policy. However,
the PDC emulator for the domain is a single computer, and Group Policy
is usually used to establish settings for multiple computers. |
|
5.2. Synchronize with a hardware clock
To use the internal hardware clock of the server, you should use the following:
Change the value of AnnounceFlags to A at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\.
At the command prompt, stop and start the Windows Time service by using the command net stop w32time && net start w32time.
To synchronize with a separate hardware clock follow the instructions provided with the hardware.
As we've seen, time synchronization is automated
by default within the AD forest. Automated time synchronization cannot
occur, however, if member computers cannot connect to their domain, and
that will not be possible if IP addressing is incorrect. DHCP is used in
many networks to automate IP addressing. DHCP can also be integrated
with AD.
6. Integrating DHCP with AD
If you will be using Windows 2000 or Windows
Server 2003 DHCP servers in your AD environment, you should be aware
that these Windows DHCP servers must be authorized in AD or they will
not be able to start. This requirement can help prevent rogue Windows
DHCP servers on the network. A rogue DHCP server can cause problems by
issuing invalid IP addresses to clients, thus creating a denial of
service. DHCP servers must either be DCs or member servers to be
authorized. DHCP services on standalone Windows servers cannot be
authorized in the domain. However, if they are on a subnet that does not
have an authorized DHCP server, they will function. However, this
configuration is not recommended. If the standalone DHCP server detects
another DHCP server, it will stop leasing IP addresses to DHCP clients.
Non-Windows
DHCP servers and Windows NT 4.0 DHCP servers will not be hampered and
can initialize and service clients even if they are not authorized
Windows DHCP servers on the network. |
|
Detection of an unauthorized DHCP server is
accomplished via the use of the DHCP information message (DHCPINFORM)
and Microsoft-specific options types that are used to communicate
information about the forest root domain. When DHCP member servers
start, they query AD for the list of authorized DHCP server IP
addresses. If the name is on the list, then the DHCP server starts
servicing clients. If the name is not on the list, it does not provide
service to DHCP clients.
In a multiple forest environment, member servers
seek authorization information from their own forest only. This means
that clients may obtain an IP address via a DHCP server in another
forest, even though no DHCP server is available from their own forest.
Member DHCP servers repeat the detection process every 60 minutes.
When a standalone DHCP server starts, it sends a
DHCPINFORM message seeking other DHCP servers on the network and
querying for other DHCP servers on the network. If there are DHCP member
servers on the network, they reply with DHCP acknowledgment messages
(DHCPACK) that include information about the forest root domain. If
there are no member server DHCP servers on the network (the standalone
DHCP server receives no reply), the standalone DHCP server begins
servicing DHCP clients. If the standalone server receives a reply from
an authorized DHCP server, the standalone server does not provide DHCP
services to clients. The standalone DHCP server repeats its query every
10 minutes.
To authorize DHCP servers and benefit from this approach:
The first DHCP server must be a member server in an AD domain.
To
authorize the DHCP server using its FQDN, the FQDN of the DHCP server
cannot exceed 64 characters. (The IP address of the DHCP server can be
used to authorize the server.)
To
authorize a Windows 2000 DHCP server in a Windows Server 2003 forest,
the Windows 2000 DHCP server must be at service pack 2 or above.
You
must be a member of the Enterprise Admins group (or have been delegated
the right to authorize DHCP) to authorize a DHCP server.
You can authorize DHCP servers in one of two
ways. To authorize DHCP Servers using the DHCP Management Console, open
the console and right-click DHCP. Select Authorize.
You could also authorize DHCP server using the netsh command. To use this method, enter the following at the command line:
netsh dhcp add server
servername serverIP
For example, you could use the following command:
netsh dhcp add grnvalley.nomoore.local 192.168.5.40
To delete an authorized server using the netsh command, enter the following from the command line:
netsh dhcp delete server
servername serverIP
To list the authorized servers in AD using the netsh command, enter the following from the command line:
netsh dhcp show server
7. NetBIOS and WINS in an AD Domain
As you can tell, AD serves as the backbone for
many network services and is intimately related to others. These other
services (such as DNS, DHCP and Windows time service) play crucial roles
in an AD network. DNS is critical for AD's existence. Administration of
an AD network is much easier because of its support of and use of DHCP
and the Windows time service. Windows Internet Name Service (or WINS, a
legacy Windows network service) can also play a role in the AD network.
All AD domains have both DNS names and NetBIOS
names. DNS services are required for the operation of AD. All Windows XP
Professional, Windows 2000, and Windows Server 2003 computers can use
DNS to locate computers on the network. Some applications (and legacy
Windows clients such as Windows 98) rely on the ability to locate
computers on the network using NetBIOS. To assist these computers, the
Windows Internet Name Service (WINS) can be implemented in an AD
environment.
7.1. Integrating WINS in a DNS environment
WINS integration
in a Windows DNS environment is configured to allow lookup of DNS names
that cannot be resolved by querying the DNS namespace. Two DNS resource
record types are used:
WINS resource record
This integrates WINS lookup in forward
lookup zones. When a WINS resource record is present in DNS, the WINS
database can be used for forward queries for hostnames or names that are
not found in the zone database. This service can even assist computers
that are not WINS-aware (such as Unix).
WINS-R resource record
This integrates a node adapter status request for reverse lookup zones.
A WINS lookup via a DNS query follows these steps, as shown in Figure 9:
The client queries its preferred DNS server for a client in a DNS zone that is integrated with WINS.
The normal DNS recursion process proceeds and locates the DNS server authoritative for the desired DNS zone.
The DNS server looks for a matching host (A) record matching the requested computer and doesn't find one.
Since
the DNS server is enabled to do WINS lookup, the server separates the
host part of the computer name from the FQDN in the DNS query.
The DNS server sends a NetBIOS name request for the host to the WINS server.
If
the WINS server can resolve the name it returns the IP address to the
DNS server. The DNS server creates a host (A) resource record using the
resolved IP address from the WINS server. This address is returned to
the original, preferred DNS server.
The preferred DNS server passes the address to the requesting client.
A WINS reverse lookup via a DNS query follows these steps:
The
WINS database is not indexed by an IP address and, therefore, the DNS
service cannot simply send a reverse name lookup to WINS to get the name
of the computer if the IP address is known. However, the DNS service
can send a node adapter status request to the IP address in the DNS
reverse query.
The computer responds to the node adapter status request with the computer name.
The DNS services appends the computer name to the DNS domain name and forwards the result to the requesting client.
WINS
and WINS-R resource records are only available in and used by Windows
DNS servers. If zone transfers are approved between Windows DNS servers
and other DNS servers, prevent these records from being included in zone
transfers. |
|
To enable WINS lookup in DNS, begin by opening
the DNS console. Right-click the forward lookup zone for which you wish
to enable WINS. Select the WINS tab and select the "Use WINS forward
lookup" checkbox, as shown in Figure 10.
Enter the IP address of the WINS server to be used for WINS lookup and then click Add. Click OK.
To enable a reverse lookup, begin by opening the
DNS console. Right-click the reverse lookup zone for which you wish to
enable WINS. Select the WINS-R tab and select the Use WINS-R lookup
checkbox. Enter the domain name to use in the "Domain to append to
returned name" box, as shown in Figure 11.
In some networks, you may wish to restrict
direct access to WINS records. You might do this to obscure the address
of internal hosts while listing public addresses such as web servers.
While the address can be found for a specific computer by doing a WINS
lookup, if the addresses are accessible to a zone transfer, no previous
knowledge of a computer NetBIOS name is necessary. While zone transfers
should only be allowed to trusted DNS servers, the extra step of
preventing the exposure of WINS records may be judged by your
organization as an added security step.
To prevent WINS records from being included in
zone transfers, begin by opening the DNS console. Right-click the zone
to be configured not to include WINS resource records in a zone
transfer. Select the "Do not replicate this record" checkbox.
In addition to using
TCP/IP effectively with AD, you should also be aware of the benefits of
using Group Policy. Group Policy can be used to provide security
settings and other management options for computers joined in a Windows
2000 or Windows Server 2003 domain.
