Network Services
| < Day Day Up > |
| 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. DHCP ServicesWindows 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 databaseWindows 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:
DHCP AuthorizationWindows 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. note The NETSH.exe command now supports deleting leases and can activate and deactivate DHCP scopes. For an excellent description of using the NETSH command for managing DHCP, refer to the online help in Windows Server 2003. Search for Netsh.exe and look in the "Command Line Reference A-Z." For an excellent multimedia presentation on migrating Windows NT 4 to Windows Server 2003 scopes as well as other DHCP reference material, go to http://www.microsoft.com/technet/treeview/default.asp?url=/technet/tcevents/itevents/windows2003srv/TNT1-92.asp . 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
Conditional ForwardingConditional 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 6.4 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. Figure 6.4. Conditional forwarding is implemented on the Forwarders tab in the DNS server properties dialog box. 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 DelegationOften, 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 6.5. 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. Figure 6.5. Compaq's delegation of the _msdcs, _sites, _tcp, and _udp zones allows the use of a single namespace in the company. This is currently HP's namespace configuration. 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 6.6. 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. Figure 6.6. Compaq could have used this method of delegation, adding a new sub-domain to the root namespace. This is a far more common solution. After the merger with HP, this infrastructure remained intact and services the entire HP Windows 2003 environment today. Delegation of the _msdcs ZoneDelegating 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 6.7 shows the zone information for HP's test environment, Qtest.cpqcorp.net, and Figure 6.8 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. Figure 6.7. CName (Alias) records,Domain records, and GC records are only stored in the _msdcs zone in the forest root domain. Figure 6.8. The _msdcs zone in child domains does not contain CName or GC records. 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 6.9, 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. Figure 6.9. DNS referrals are used for DCs in the child domain to find the CName records in the root domain in order to effect AD replication. 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.10. This puts the name resolution information on a DNS server close to the client. Figure 6.10. Delegation of the root _msdcs zone improves performance of DNS name resolution for other domains in the forest for GC and CName records. 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 PartitionsApplication partitions, described in Chapter 1, 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 6.11. Note that the _msdcs zone from the root zone (_msdcs.company.com) is shown as a child of the ForestDnsZones container. Figure 6.11. The _msdcs zone information is included in the ForestDnsZones application partition, as seen here using the LDP tool. Group Policy SettingsA number of Group Policy settings are related to DNS, including the DC Locator, DNS client, and Net Logon parameters. (These are detailed in Chapter 1, and should be reviewed when designing the DNS infrastructure.) 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 ConfigurationIn 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. As described previously in this chapter, 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 6.12). 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. Figure 6.12. ADI zones can utilize standard secondary zones on member servers to improve name resolution performance in remote sites. 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 ConfigurationConfiguration 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:
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 ConfigurationThe 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, new to Windows 2003, is available on the General tab of the Zone properties dialog box. This feature, illustrated in Figure 6.13, allows you to decide who the DNS data should be replicated to. The options include
Figure 6.13. Replication scope options for ADI DNS zones allows the Administrator to select the scope of replication for the zone information. Configuring Clients for Single-Label DNS DomainsA 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
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. Remote AccessThe 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. Chapter 14, "Remote Access Service," gives an in-depth look at the use of VPNs and HP/Compaq's implementation. Chapter 14 was authored by Thaddeus Fortenberry, HP's Program Manager for VPN. |
| < Day Day Up > |
EAN: N/A
Pages: 214