Windows Server 2008 R2 Unleashed (77 page)

as follows.

DNS entries in an Active Directory–integrated DNS zone are “secure,” which means that

only the client that originally created the record can subsequently update that same

record. This can cause problems if the DHCP server is automatically updating client

records, however, as the client no longer performs this function and cannot have security

applied to a record.

DHCP in Windows Server 2008 R2 overcomes this limitation by providing a special group

in Active Directory, called DNSUpdateProxy. Members of this group do not have any secu-

rity applied to objects that they create in the DNS database. The theory is that the first

client to “touch” the record will then take over security for that record.

The problem with this concept is that the records created by DHCP servers possess no

immediate security and are consequently subject to takeover by hostile clients. Because

domain controllers are responsible for publishing SRV DNS records, which indicate the

location of domain controllers, Kerberos servers, and the like, this leaves a gaping security

hole that users could exploit. Consequently, it is preferable to keep DHCP off domain

ptg

controllers. If this cannot be avoided, it is recommended to not place the DHCP server

into the DNSUpdateProxy group so as to avoid the security problems associated with it or

to ensure that each scope on the DHCP server is configured with a user account to use for

Dynamic DNS updates. To add a designated user account to perform Dynamic DNS regis-

tration for the DHCP server, open the DHCP server console, and on the desired DHCP

server, expand and right-click the IPv4 node, select the Advanced tab, and click the

Credentials button. Enter the name, domain, and password of the user account that will

update and own the Dynamic DNS entries related to DHCP leases. Ensure that this

account is just a standard user and not a domain administrator to ensure that it can only

manage records that it creates and will be denied the ability to update or replace any exist-

ing records created by Windows clients or DNS administrators.

Reviewing the Windows Internet Naming Service

(WINS)

The Windows Internet Naming Service (WINS) has a long history in Microsoft networks.

In the beginning, Microsoft networks were primarily broadcast-based, using protocols such

as NetBEUI to identify local computers. If a user on a Windows client wanted to find a

system by name, the Windows client would send out a broadcast message by name, and if

the system was on the same network, it would respond so the two systems could establish

a connection and begin communication. The problem with this type of name resolution

was that it did not scale beyond multiple subnets, and with today’s networks, broadcast

messages can be blocked by local server and workstation firewalls and anti-malware soft-

ware. With the adoption of TCP/IP as an easily routable protocol, the need to translate

362

CHAPTER 11

DHCP/WINS/Domain Controllers

NetBIOS or Windows computer names to IP addresses became a reality. This need gave rise

to the development of the Windows Internet Naming Service (WINS).

WINS provided a central database that can be referenced when a client system is looking

up another system by hostname, and that is the key difference between WINS and DNS,

hostname versus fully qualified name. As an example of this, a server named SERVER10 in

the companyabc.com domain would have a WINS record named “SERVER10” and a DNS

record in the companyabc.com DNS zone named “server10.companyabc.com.”

Understanding the Need for Legacy Microsoft NetBIOS Resolution

WINS is effectively a simple database of NetBIOS names and their corresponding IP

addresses. Some additional information, such as domain name, server type or service

type, and so on, can be determined as well, from the 16th byte in a NetBIOS name

stored in WINS.

WINS is considered legacy in the Microsoft world because NetBIOS resolution is being

phased out in favor of the domain name system (DNS) form of name resolution. However,

it is difficult to divorce WINS from modern networks because of the reliance on WINS by

down-level (pre-Windows 2000) clients, legacy applications, and even some Microsoft

services, such as the Distributed File System (DFS), that utilize NetBIOS resolution by

default. Also, many Independent Software Vendors, or ISVs, develop their software for

ptg

Microsoft networks, but their test networks sometimes only include a single network with

no firewalling between systems. When these software applications are deployed on enter-

prise networks, they can fall short in name resolution results, and deploying WINS might

be the only viable solution.

As mentioned previously, the new DNS GlobalNames feature is designed to remove the

need for WINS. See Chapter 10 for more information on DNS GlobalNames.

Exploring WINS and DNS Integration

DNS can use the WINS database to provide for quasi-DNS resolution of WINS clients. This

means that if a name resolution request is sent to a DNS server to resolve client1.compa-

nyabc.com, for example, the DNS server will first look in the companyabc.com zone. If no

record exists for client1.companyabc.com, the DNS server will perform a lookup on the

WINS database for CLIENT1; if a WINS record exists, the DNS server will take this IP

address and send it back to the DNS client as client1.companyabc.com, as illustrated in

Figure 11.16.

This functionality must be enabled on the DNS server because it is not configured by

default. This feature is configured on a zone-by-zone basis; however, if the forward lookup

zone is an Active Directory–integrated zone, each Windows Server 2008 R2 DNS server

hosting this zone will copy this WINS setting. To enable WINS resolution on a DNS server,

follow these steps:

1. On a server running DNS, open the DNS MMC snap-in (Start, Administrative

Tools, DNS).

2. Navigate to DNS\\Forward Lookup Zones.

Reviewing the Windows Internet Naming Service (WINS)

363

1

11

Client

1: Client sends a query to the DNS server

4

for client1.companyabc.com.

2: The DNS server is unable to resolve

2

using DNS and forwards the request to the

DNS

WINS server.

Server

3

3: An entry for CLIENT1 in the WINS

database is found and forwarded back to the

DNS server.

client1.companyabc.com =

10.1.2.165

WINS

4: The DNS server returns the IP address to

Server

the client and attaches the suffix

companyabc.com.

FIGURE 11.16

WINS integration with DNS.

3. Right-click the zone in question and click Properties.

4. Choose the WINS tab.

ptg

5. Select the Use WINS Forward Lookup check box.

6. Enter the IP address of the WINS server(s) to be used for resolution of names not

found in DNS, and click Add to save the changes, as illustrated in Figure 11.17.

FIGURE 11.17

Configuring WINS resolution in DNS.

364

CHAPTER 11

DHCP/WINS/Domain Controllers

7. If you are replicating this zone between DNS servers that are not running Windows

Server 2008 R2 DNS services, make sure to check the box labeled Do Not Replicate

This Record. This prevents the records from being replicated to other servers during

zone transfers.

8. Click OK to finish and return to the DNS Manager page.

For more information on DNS configuration, refer to Chapter 10.

Reviewing Changes in Windows Server 2008 R2 WINS

Although the overall function of WINS has not changed significantly in Windows Server

2008 R2, some additions to the management tools allow for increased functionality and

capabilities:

.
Advanced search capabilities for WINS databases—
Previous implementations of

WINS had simplistic search capabilities that were limited to simple keyword searches

of NetBIOS records in the database. The search engine for WINS has been updated in

Windows Server 2008 R2 to support more advanced search parameters, thus giving

administrators more flexibility in searching for specific records.

.
WINS pull record filtering and replication partner acceptance—
Instead of

entire transfers of all records on other servers, replication can be limited to only

ptg

those records owned by a specific server, thus excluding extraneous records from lit-

tering a WINS database.

In addition to these advances in Windows Server 2008 R2, Windows 2000 introduced

enhancements to WINS, such as an updated database engine, persistent connections,

manual tombstoning, and other improvements.

Installing and Configuring WINS

As with many services in Windows Server 2008 R2, the installation and configuration

process of a WINS server is streamlined through the Add Features Wizard. This wizard

automatically installs all necessary services and databases and configures other settings

pertinent to a particular service. Although other methods of installation still exist, this

method is the preferred approach in Windows Server 2008 R2.

Installing WINS

To install WINS on a server using the Server Manager Add Features Wizard, follow these

steps:

1. Choose Start, All Programs, Administrative Tools, Server Manager. In the console tree,

right-click on Features, and then click Add Features to start the Add Features Wizard.

2. On the Select Features page, scroll down the list of features and select the check box

next to WINS Server. Then click Next to continue.

3. Verify that WINS Server is displayed in the selections window.

4. Click Install on the Confirm Installation Selections page to begin installing the

WINS server.

Installing and Configuring WINS

365

5. It will take a few minutes for the installation to begin and the basic configuration of

the WINS server to complete.

11

6. If desired, click the Print, E-mail, or Save the Installation Report link to archive the

installation results.

7. Click Close on the Installation Results page to finish setup.

Configuring Push/Pull Partners

If a WINS server in an environment is the sole WINS server for that network, no addi-

tional configuration is required other than ensuring that clients will be pointing to the

WINS server in their IP configuration. However, if it has been decided that WINS is

required, it is a best-practice recommendation to deploy a secondary WINS server to

provide redundancy. Unlike DHCP, however, WINS replication partners will replicate their

registered entries between each other. WINS replication is established through the designa-

tion of WINS push/pull partners.

A push partner for a particular WINS server is the server that pushes WINS database infor-

mation to a receiving or pull partner. A pull partner is a WINS server from which changes

are “pulled.” In a nutshell, if Server1 has Server2 configured as a push partner, Server2

must have Server1 configured as a pull partner, and vice versa.

ptg

A WINS push/pull topology should roughly map to an organization’s network topology. For

example, if an organization is composed of two main offices that serve as network hubs,

and several branch offices, each with its own WINS servers, the WINS push/pull topology

could look something like Figure 11.18. In many organizations, however, if network

connectivity is reliable between locations, it is a best practice to deploy only two WINS

servers for the entire organization. This reduces WINS database replication and administra-

tion. Remote or branch office WINS servers should only be deployed on networks where

network and/or firewall administrators block WINS traffic from remote networks.

Examining WINS Replication

WINS replicates database changes on a set schedule, which can be modified on a per-

connection basis. Just as with any network communications, the replication schedule

should be modified to fit the particular needs of an organization. If a wide area network

(WAN) link is saturated with traffic, it might be wise to throttle back the WINS replication

schedule. However, if a link between push/pull partners is robust, a shorter schedule can