Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
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.
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
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
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