Network services described in this section
include DHCP, DNS, and Remote Access. There have been significant
improvements in all three areas that will affect the physical design of
the Windows 2003 infrastructure. Even if you currently have a Windows
2000 environment, there are features you will want to take advantage of.
1. DHCP Services
Windows Server 2003 made some significant changes to
DHCP. The most significant change is in the way DHCP configuration
information is stored. Windows 2000 DHCP stored its configuration
information in the Registry, where Windows 2003 DHCP utilizes the AD.
This is important in a couple of ways:
In addition, the Jet database utilized in Windows
2003 is ESE98 (only), which is also 64-bit compatible, whereas Windows
2000 utilized JET500, JET200, and ESENT databases.
Backup and Restore of the DHCP database
Windows Server 2003 allows backup and restore of the
DHCP database. This permits the entire database to be moved to a new
server. In addition, individual scopes can be moved to another server
with the dhcpexim.exe tool from the Resource Kit. Following are
important points to note concerning the backup/restore process:
The backup/restore option is in the DHCP Administrator snap-in. Right-click on the server and go to backup or restore.
The default directory to save the backup is %systemroot%\system32\dhcp\backup.
Backup is done while the server is running.
Restore requires a restart of the DHCP service.
DHCP
configuration data elements, such as audit log settings, database
locations, and so on, are not defined in the database and thus are not
restored.
There is an interruption of service during the restore of the DHCP database, but not during the backup.
Windows NT and Windows 2000 DHCP databases can be restored to a Windows 2003 DHCP server.
DHCP Authorization
Windows 2000 stored DHCP authorized servers in a
single multivalued object. This limited the number of DHCP servers to
854 authorized servers per domain along with other limits. Windows
Server 2003 stores authorized DHCP servers as separate objects in the
AD. Besides increasing the number of DHCP servers, it corrects the
problem in Windows 2000 where changes made at the same time are
overwritten, and DCs don't search outside of their domain for authorized
DHCP servers. These features are available in Windows 2000 SP2 and
later also.
2. Domain Name Service (DNS)
Windows 2003 made several significant changes that
affect the DNS structure. This section details these new features as
well as some important design considerations. Although there are new
features in Windows Server 2003, the basic functionality and most design
rules from Windows 2000 still apply. Microsoft has created an excellent
Web site called DNS Center for Windows 2000 (located at http://www.microsoft.com/windows2000/technologies/communications/dns/default.asp)
that contains whitepapers, best practices, Web casts, articles, and so
on. It's well worth the effort to review the site for basic information
that still applies. Microsoft has not updated their DNS whitepaper for
Windows Server 2003.
Significant new features for Windows 2003 DNS include
Stub zones
Conditional forwarding
Delegation of _msdcs zone
Application partitions—DomainDnsZones and ForestDnsZones
New Group Policy settings
Conditional Forwarding
Conditional forwarding is more of a description of a
feature than any name you'll find in the snap-in. It is a shortcut
across the DNS tree to send referrals for a particular domain directly
to the Start of Authority (SOA) for that domain without going through
the DNS hierarchy to resolve it. Consider an example where a client in
the NA.corp.net domain wants to resolve a name in the EU.corp.net
domain. The request would go from the NA DNS server to the Corp.net DNS
server. The Corp.net DNS knows about the EU domain, and sends the
request to the SOA for the EU.Corp.net domain, which returns the
information to the client. In conditional forwarding, you can map a
domain to the IP address of one or more SOAs for that domain. So in this
example, on the DNS server for the NA.corp.net domain, you can map the
EU.corp.net domain directly to the SOA for the EU.corp.net domain. The
client would query for the EU resource record, but instead of going to
the parent domain and back, the request goes directly to the SOA for the
EU.corp.net domain.
Consider an example of two forests, Company.com and
NewCompany.com, which are implemented as a multiforest configuration for
a company. To build a cross-forest (Kerberos) trust between the two
forests, we must first get name resolution between them. We can
accomplish that with conditional forwarding.
Figure 1
shows the Forwarders tab used to configure name resolution with
conditional forwarding. This example is defined on a Name Server (NS) in
the Company.com domain. Note that the domain NewCompany.com is defined
with NSs 10.0.7.253 and 10.0.7.254. Thus, any requests for resources in
NewCompany.com are referred to these two Name Servers rather than using
normal iterative processes to resolve the name. It's basically a
shortcut that provides better performance. Similarly, the NSs for
Company.com would be defined on the NSs in NewCompany.com.
DNS conditional forwarding would be useful in an
environment that has multiple domain trees, rather than a single root,
or one that uses nonregistered DNS domain names.
Zone Delegation
Often, initial internal configuration of the Windows
2000 or 2003 DNS structure involves an existing UNIX or Linux BIND DNS
that is hosting the internal and external namespace. All AD requires is a
DNS zone that is a unique namespace or it can be a zone that is
delegated from the existing BIND server. This can be as simple as
creating a new child zone.
An interesting delegation example is that of HP's
internal DNS structure. Before the HP-Compaq merger, Compaq used a BIND
server to service the UNIX and VMS communities as well as the Windows NT
community for the internal namespace, CPQCORP.NET. Compaq decided to
use Cpqcorp.net as the Windows 2000 namespace rather than delegating a
new zone such as W2K.cpqcorp.net. The BIND server, because it supports
dynamic updates and SRV records, could have been made authoritative for
the Windows 2000 domain, but Compaq didn't want to enable dynamic
updates on the root DNS. The resulting configuration is shown in Figure 2.
The four domains, _msdcs, _sites, _tcp, and _udp, are delegated from
the BIND server, which hosts CPQCORP.NET to a Windows 2000 DNS. There is
also a delegation from the BIND server for the three child zones,
Americas.cpqcorp.net, EMEA.cpqcorp.net, and AsiaPac.cpqcorp.net.
Compaq could have use a far more common delegation
scheme by adding a new zone such as W2K and delegating the whole
namespace from the BIND server to the Windows DNS, as shown in Figure 3.
After the delegation is made from the BIND server, the Windows
environment is self-contained and won't affect the other parts of the
namespace. Windows Admins can administer their own DNS without bothering
the UNIX Admins, and can delegate other zones from there.
After the merger with HP, this infrastructure remained intact and services the entire HP Windows 2003 environment today.
Delegation of the _msdcs Zone
Delegating the _msdcs zone is a feature of Windows
2000 and 2003 DNS that is still largely misunderstood—or not understood
at all by Administrators. Features in Windows 2003 drastically change
the way this fairly complicated issue is dealt with. Let's first
describe the problem and how it was solved in Windows 2000, and then
we'll describe how Windows 2003 solves the issue with Application
Partitions called ForestDnsZones and DomainDnsZones.
Four subzones are created by Windows 2000 and 2003 to hold the SRV records:
In a single-domain environment, there is no further
issue. However, there is a problem in multidomain environments. The
_msdcs zone in the root zone of the forest (the domain that was created
first in the forest) holds two record types that no other DNS in the
forest holds: GC records and CName or Alias records. The GC records are
required to locate GCs for client requests for such things as
authentication and AD lookups. The CName records map the server GUID
number to the fully qualified domain name (FQDN) of the server and are
used in AD replication. Every time a DC replicates with another DC, a
DNS query is made to locate the DC using the CName record.
In a multidomain environment, each domain has a
forward lookup zone registered that contains the four subzones: _msdcs,
_sites, _tcp, and _udp. However, only the _msdcs zone in the root zone
contains the GC and the CName records. Figure 3 shows the zone information for HP's test environment, Qtest.cpqcorp.net, and Figure 5
shows the zone information for a child domain, EMEA.cpqcorp.net. Note
that the _msdcs zone in EMEA does not contain the CName records or the
GC records that the Qtest domain has.
The problem comes when network performance or
connectivity prevents name resolution from finding the root zone,
preventing clients from finding GC records (affecting authentication and
exchange) and preventing DCs from finding CName records (affecting AD
replication). In Figure 5,
the domain Corp.com is the forest root and W2K.net is a separate domain
tree and the top-level domain for the Windows 2000 structure, with
NA.W2K.net and EU.W2K.net as child domains. If DC2.EU.W2K.net attempts
to replicate to DC3.EU.W2K.net, it must resolve the name for the
replication partner in the _msdcs zone in the Corp.com domain. If
network problems prevent this from happening, replication fails.
The solution in Windows 2000 was to either configure secondary zones of Corp.com
on DNS servers in the W2K, EU, and NA domains, or to delegate the
_msdcs zone from the forest root to the other DNS servers, as
illustrated in Figure 6. This puts the name resolution information on a DNS server close to the client.
Windows 2003 delegates the root _msdcs zone
automatically when DCPromo creates the first DC in the forest, if DNS is
not configured before DCPromo runs and if DCPromo is allowed to
automatically configure DNS.
note
In Windows 2000, allowing DCPromo to automatically
configure DNS was not recommended because it put a “.” Zone at the root
of the DNS namespace, preventing name resolution outside of the domain.
This has been corrected in Windows 2003 and, in fact, DCPromo does an
excellent job of configuring DNS, including automatic delegation of the
root _msdcs zone. Note also that although that zone is delegated, the
Administrator must add appropriate DNS servers to the delegation for
other zones in the forest that need to participate in the delegation.
Another way to solve the _msdcs problem is by using
the ForestDnsZones and DomainDnsZones application partitions,
automatically configured when a Windows 2003 forest is created
(described in the following section).
ForestDnsZones and DomainDnsZones Application Partitions
Application partitions, can replicate data to a user-defined set of DCs across domain
boundaries. Two such partitions are created by default when the forest
is created: ForestDnsZones and DomainDnsZones. These partitions contain
ADI DNS zone data—DNS forward lookup zones called ForestDnsZones and
DomainDnsZones—and can be viewed in the DNS Management snap-in. The
purpose of these partitions is to contain DNS records and replicate them
only to DNS server. Windows 2000 behavior was to replicate ADI DNS
records to all DCs as part of the domain partition in AD. This was
unnecessary and generated unnecessary traffic via dynamic registrations.
ForestDnsZones is a forest-wide partition, of which
every DNS server in the forest is a replica. Information in this zone is
replicated to every DNS in the forest. DomainDnsZones is a domain-wide
partition that contains DNS server that are members of the domain that
the DNS hosting it is a member of. When a child domain is created, the
DNS is added to the ForestDnsZones partition, a new DomainDnsZones
partition is created, and this first DNS is added. As additional DNS
server are joined to the domain, they are added as replicas.
note
If ForestDnsZones or DomainDnsZones forward lookup
zones are accidentally deleted, they can be re-created via dynamic
registration by restarting the Net Logon service. The DCs will be
re-added as replicas. If the application partition, created in NTDSUtil,
is deleted, it will have to be re-created via NTDSUtil.
By default, the _msdcs zone of the forest root is
created in the ForestDnsZones partition. Thus, by default, the issue of
making the CName and GC SRV records more readily available to child
domains is solved. The contents of the ForestDnsZones and
DomainDnsZones, like any other application partition, can be viewed
using the LDP utility, as shown in Figure 7. Note that the _msdcs zone from the root zone (_msdcs.company.com) is shown as a child of the ForestDnsZones container.
Group Policy Settings
A number of Group Policy settings are related to DNS,
including the DC Locator, DNS client, and Net Logon parameters. Microsoft continues to use Group Policy to make it easy to define
parameters that once were buried in the Registry. The downside of that
is the parameters are easy to find, so make sure you trust the
Administrators who have privileges to modify Group Policy.
ADI Zone Configuration
In the early days of Windows 2000, Microsoft
recommended that DNS server hosting ADI zones should point to themselves
as the Preferred DNS in the TCP/IP properties of the computer, and to
any other close DNS for the Additional DNS Servers. This was found to
cause replication failures where multiple DCs were authoritative DNS
servers for the forest root zone. Each DC registers a CName (Alias) record that maps the server
GUID to the FQDN of the server for replication purposes. When a DNS in
the forest root (authoritative for the root _msdcs zone) is configured
in its TCP/IP properties to point to itself as the Preferred DNS, it
registers its CName record on its copy of the _msdcs domain, but it
doesn't replicate to the other DNS server in the domain. This results in
“islands” of name resolution for the CName records and consequently
causes replication failures because CName records are missing for some
of the DCs. Microsoft KB article 275278, “DNS Server Becomes an Island
When a Domain Controller Points to Itself for the
Msdcs.forestDNnsNameDomain,” suggests remedies for the problem,
including selecting a single DNS to be authoritative for the forest root
zone, and having all the other ADI Primary DNS NSs point to that one
server as the preferred DNS and to another DNS (other than themselves)
as the Additional DNS Servers.
Windows Server 2003 has implemented functionality
that addresses the island server problem. When a DC attempts to register
its records, it will do so on all NSs that are authoritative for the
forest root zone. According to Microsoft, this functionality in Windows
Server 2003 is still supported, but another supported configuration is
to have each DC/DNS point to itself for the Preferred DNS (in the TCP/IP
properties), and point to another DNS for the Additional DNS Servers.
Both configurations are supported.
ADI zones can only be hosted by DCs. However, an ADI
zone can be hosted as a standard secondary zone on member servers. For
example, the company.com ADI zone is hosted on several DCs, but there
are remote sites where you want to place DNS server to give the users
better performance, and you don't want to place DCs at those sites. To
solve this, you can install DNS on a member server and create a
secondary zone, sourcing from the single ADI Primary that the other ADI
DNS server point to for DNS (illustrated in Figure 8).
Thus, all DNS server are registering from the single source DNS, and
you have a mix of ADI and secondary zones to support the domain clients.
Hosting standard secondary zones on domain
controllers is not recommended. The behavior is that if a standard
secondary zone is created on a DC, when the DC is rebooted, the zone
will be converted to an ADI primary zone. If you want a secondary zone,
put it on a member server.
Client Configuration
Configuration of the DNS in the TCP/IP properties of
each client need never point to a DNS outside the Windows 2000 or 2003
domain. These properties are viewed by right-clicking My Network Places,
choosing Properties, right-clicking <LAN Connection>, selecting
Properties, selecting TCP/IP from the list, and selecting the Properties
button. Note that in this context, “client” refers to any
computer—workstation, server, or DC—that is not a DNS.
Best practices for DNS configuration of clients include the following:
Preferred DNS should point to closest DNS in the network to the client, preferably one that is in the same site.
Additional DNS Servers can be one or more DNS server that are next closest to the client in the network.
Clients
should never point to a DNS outside of their domain, whether it be a
UNIX BIND server hosting other internal zones or an Internet Service
Provider's (ISP) DNS.
Administrators often use the Additional DNS Servers
property to try to build in redundancy by adding other DNS server.
Pointing to other internal DNS server is fruitless because even if they
did register the DNS record, the Windows domain would not use it.
Pointing to an ISP's DNS is equally useless because the ISP certainly
won't allow random clients to register DNS records and, again, even if
they did, the Windows domain couldn't use it. In both cases, this
nondomain DNS is not authoritative for the client's domain. The rule is
simply to point clients to their local DNS and use DNS forwarding to
forward requests to other domains and the Internet.
DNS Configuration
The DNS and zone properties configuration is very
similar to that recommended for Windows 2000. The server properties are
displayed by right-clicking the DNS Server icon in the DNS snap-in and
selecting Properties, whereas the zone properties are displayed by
right-clicking the Zone icon in the snap-in and selecting Properties.
The DNS properties of significance are on the
Forwarders tab. Windows 2003 adds conditional forwarding to the normal
forwarder list, as shown earlier in Figure 6.4.
In the Selected Domain's Forwarder IP Address List, add DNS server to
which client requests for name resolution outside the domain are sent.
This is where the internal DNS server that host other domains as well as
the ISP's DNS can be listed.
The zone properties of note include
Replication scope
Dynamic updates
Name servers
Zone transfers
Replication scope, new to Windows 2003, is available
on the General tab of the Zone properties dialog box. This feature,
illustrated in Figure 9, allows you to decide who the DNS data should be replicated to. The options include
All DNS server in the forest:
Replicates zone information to all DNS server in the forest.
All DNS server in the domain:
This is the default for an ADI zone.
All DCs in the domain:
This option would be used if there are Windows 2000 DCs that are also DNS server in the domain.
All DCs specified in the replication scope of an application directory partition:
This would be used for user-defined application partitions.
Configuring Clients for Single-Label DNS Domains
A single-label DNS name consists of a FQDN that has
only a single label without a dot (.). For instance, rather than
Company.com, the DNS name would be Company—just like a NetBIOS name
would appear. A single label AD domain in Windows 2000 presents problems
because Windows 2000 SP4 and Windows XP clients, by default
Do not register themselves in a single-label domain
Do not use DNS to locate DCs in single-label domains
Do not use DNS to locate DCs in single-label domains in other forests unless a single-label domain is in the local forest
Windows 2003 and XP have added Registry keys that
change the behavior of these three situations. Microsoft KB article
826743, “Clients cannot dynamically register DNS records in a
single-label forward lookup zone,” describes the first two issues in
this list and KB article 300684, “Information about configuring Windows
for domains with single label DNS names,” describes the third item.
note
Microsoft changed the default behavior of clients to not
support single-label domains because Microsoft does not recommend this
configuration. The single-label domain was typically a product of
upgrading Windows NT domains and not of changing the name from the
Windows NT “NetBIOS” name to the Windows 2000/Windows Server 2003 DNS
name.
3. Remote Access
The improvements in remote access using Virtual
Private Networking (VPN) technology have completely changed the face of
remote access infrastructures for companies since Windows NT introduced
Remote Access Service (RAS). Windows 2000 introduced more secure
end-to-end connections using IPSec and Level 2 Tunneling Protocol (L2TP)
protocols, and permitted network-to-network VPN connections to connect
remote subnets. However, there were some limitations, including the
inability to use IPSec to a network serviced by a Network Address
Translator (NAT) service. Windows 2003 improved performance, removed
some of the restrictions such as allowing IPSec to run on NAT clients,
and added a built-in NAT firewall in the Routing and Remote Access
Service (RRAS) utility. These improvements have allowed companies to
begin phasing out the old RAS dial-up servers and associated 800 number
access lines.
Compaq, prior to the HP merger, began implementing
Windows 2003 VPN solutions for the production remote access
infrastructure during the beta versions, about a year before the RTM
build. This was done to take advantage of performance and IPSec
features, among other reasons. As the VPN infrastructure grew, the
toll-free access numbers were gradually eliminated. Currently, most toll
free dial-up access in HP has been eliminated.
SmartCards have also added a high level of
security to remote users. While I was working on the Microsoft Beta
Technical Support team in 2002, Microsoft implemented a new remote
access policy. Microsoft provided SmartCards and configured accounts to
require SmartCard authentication for remote access.
