Windows Server 2008 R2 Unleashed (99 page)

478

CHAPTER 15

Security Policies, Network Policy Server, and Network Access

Protection

the Internet, or it might be a secured perimeter network such as a DMZ. Click Next

to continue.

FIGURE 15.15

Specifying the network card for VPN clients.

ptg

8. On the IP Address Assignment page, select how VPN clients will get their IP

addresses (typically Automatically). In addition, a manual range can be specified.

Click Next to continue.

9. On the Managing Multiple Remote Access Servers page, shown in Figure 15.16, select

whether to use RRAS to authenticate locally or to use a remote RADIUS server. Click

Next to continue.

FIGURE 15.16

Specifying RADIUS settings for the VPN server.

Deploying and Enforcing a Virtual Private Network (VPN) Using an RRAS Server

479

10. Review the wizard settings and click Finish when complete.

11. Click OK when prompted about the default connection request policy being created

and click OK again if prompted about the DHCP Relay Agent.

12. Click Finish when the wizard is complete.

The wizard will enable RRAS on the server and allow for administration of the VPN

settings and client from the Routing and Remote Access dialog box, shown in Figure

15.17. Review the settings within this tool to familiarize yourself with how the system is

configured.

15

ptg

FIGURE 15.17

Administering the server from the RRAS MMC tool.

Modifying the RRAS Network Policy

After installing and configuring RRAS, the NPS system will deny access by default to the

RRAS server for clients, unless the network policy generated is modified. The network

policy, which is labeled Connections to Microsoft Routing and Remote Access server, can

be found under the Network Policies node of the Network Policy Server.

The policy must be set to Grant Access in the Access Permission section of the dialog box,

as shown in Figure 15.18. This dialog box can be invoked by right-clicking the policy and

choosing Properties. After enabling, the NPS system will allow client connections.

NOTE

VPN clients can be controlled and monitored using the NPS role just like the IPSec,

802.1X, and DHCP clients can. Use the NPS Admin tool and the techniques described

earlier in this chapter to enable client health monitoring.

480

CHAPTER 15

Security Policies, Network Policy Server, and Network Access

Protection

ptg

FIGURE 15.18

Modifying the RRAS network policy on the NPS server.

Summary

Network Access Protection in Windows Server 2008 R2 provides for much-needed capabili-

ties to isolate and control clients that don’t conform to an organization’s policies. By

limiting the type of network access these clients can obtain, organizations can greatly

reduce their overall security risk. NAP support in Windows Server 2008 R2 is built in to

the operating system on both the server and the Windows 7, Windows Vista, and

Windows XP SP3 operating systems.

Windows Server 2008 R2’s NAP implementation provides for a robust set of tools in the

Network Policy Server role that can be used to restrict clients using NAP. The NPS role

contains built-in support for abilities to limit DHCP, IPSec, 802.1x, and VPN clients if they

do not pass system health checks. In addition, Windows Server 2008 R2 has improved

VPN capabilities, allowing administrators to control and encrypt the connections clients

make to the internal network. Using a combination of these technologies can greatly

improve the security in an environment.

Best Practices

481

Best Practices

The following are best practices from this chapter:

. Install the Network Policy Server role to restrict client access to networks and services.

. Use a dedicated Certificate Authority server for generation of health certificates for

IPSec.

. Ensure that the server certificate used for the Network Policy Server is issued from a

certificate authority that is trusted by the clients that will be connecting.

. Install at least two network cards in a server that will handle VPN client connections.

. Although Windows Server 2008 R2 VPN functionality is strong, consider the use of

an advanced firewall/VPN solution, such as the Forefront Edge line, consisting of

Forefront Threat Management Gateway and/or Forefront Unified Access Gateway to

further improve VPN security.

. Use L2TP over IPSec encryption for VPN connections when possible. Avoid using the

15

less-secure PPTP VPN connection type.

ptg

This page intentionally left blank

ptg

CHAPTER 16

IN THIS CHAPTER

Migrating from Windows
. Beginning the Migration Process

. Big Bang Migration

Server 2003/2008 to
. Phased Migration

Windows Server 2008 R2
. Multiple Domain Consolidation

Migration

In many ways, a migration from Windows Server

2003/2008 Active Directory to Windows Server 2008 R2

Active Directory Domain Services is more of a service pack

upgrade than a major migration. The architectures are

fundamentally the same and require mainly upgrades to the

schema and domains. The differences between the operat-

ing systems are more evolutionary than revolutionary, and,

subsequently, there are fewer design considerations than in

upgrades from the NT 4.0 operating system.

ptg

That said, several immediate improvements to the operating

system can be realized through migration to Windows

Server 2008 R2, whether by migrating all servers immedi-

ately or by using a slow, phased approach. Improvements to

Active Directory Domain Services (AD DS), such as the

ability to use Read-Only Domain Controllers as global

catalog servers, the Recycle Bin for AD, and greater scalabil-

ity, provide incentive for Windows Server 2003/2008 Active

Directory environments to begin migration. Standalone

server improvements such as Hyper-V, Remote Desktop

Services, File and Print Server improvements, Automated

Server Recovery, and many more also serve to encourage

migrations.

This chapter focuses on the planning, strategy, and logistics

of migration from Windows Server 2003/2008 Active

Directory to Windows Server 2008 R2 Active Directory

Domain Services. Several scenarios for migration are consid-

ered, including a Big Bang upgrade, a phased upgrade, and a

consolidation migration.

484

CHAPTER 16

Migrating from Windows Server 2003/2008 to Windows Server

2008 R2

Beginning the Migration Process

Any migration procedure should define the reasons for migration, steps involved, fallback

precautions, and other important factors that can influence the migration process. After

finalizing these items, the migration can begin.

Identifying Migration Objectives

Two underlying philosophies influence technology upgrades, each philosophy working

against the other. The first is the expression “If it ain’t broke, don’t fix it.” Obviously, if an

organization has a functional, easy-to-use, and well-designed Windows Server 2003/2008

infrastructure, popping in that Windows Server 2008 R2 DVD and upgrading might not be

so appealing. The second philosophy is something along the lines of “Those who fail to

upgrade their technologies perish.” Eventually, all technologies become outdated and

unsupported.

Choosing a pragmatic middle ground between these two philosophies effectively depends

on the factors that drive an organization to upgrade. If the organization has critical busi-

ness needs that can be satisfied by an upgrade, such an upgrade might be a good idea. If,

however, no critical need exists, it might be wise to wait until the next iteration of

Windows or a future service pack for Windows Server 2008 R2.

ptg

Establishing Migration Project Phases

After the decision is made to upgrade, a detailed plan of the resources, timeline, scope,

and objectives of the project should be outlined. Part of any migration plan requires estab-

lishing either an ad-hoc project plan or a professionally drawn-up project plan. The migra-

tion plan assists the project managers of the migration project to accomplish the planned

objectives in a timely manner with the correct application of resources.

The following is a condensed description of the standard phases for a migration project:

.
Discovery—
The first portion of a design project should be a discovery, or fact-

finding, portion. This section focuses on the analysis of the current environment

and documentation of the analysis results. Current network diagrams, server loca-

tions, wide area network (WAN) throughputs, server application dependencies, and

all other networking components should be detailed as part of the Discovery phase.

.
Design—
The Design portion of a project is straightforward. All key components of

the actual migration plan should be documented, and key data from the Discovery

phase should be used to draw up design and migration documents. The project plan

itself would normally be drafted during this phase. Because Windows Server 2008 R2

Active Directory is not dramatically different from Windows Server 2003 or 2008,

significant reengineering of an existing Active Directory environment is not neces-

sary. However, other issues such as server placement, new feature utilization, and

changes in AD DS replication models should be outlined.

.
Prototype—
The Prototype phase of a project involves the essential lab work to test

the design assumptions made during the Design phase. The ideal prototype would

Beginning the Migration Process

485

involve a mock production environment that is migrated from Windows Server

2003/2008 to Windows Server 2008 R2. For Active Directory, this means creating a

production domain controller (DC) and then isolating it in the lab and seizing the

Flexible Single Master Operations (FSMO) roles with a server in the lab. The Active

Directory migration can then be performed without affecting the production envi-

ronment. Step-by-step procedures for the migration can also be outlined and

produced as deliverables for this phase.

.
Pilot—
The Pilot phase, or Proof-of-Concept phase, involves a production “test” of

the migration steps, on a limited scale. For example, a noncritical server could be