The list has dwindled a little because support for Shiva Password Authentication Protocol
(SPAP) and the Extensible Authentication Protocol-Message Digest have been removed from
Windows Server 2008 and Windows Vista VPNs as client choices. It was thought that these
two types of authentication provided little value in securing authentication.
NOTE MS-CHAP and SPAP support in Windows Server 2008
At the time of writing this book for the release to manufacturing of Windows Server 2008,
MS-CHAP (also known as MS-CHAP v1) and SPAP were still included in the NPS and Routing and
Remote Access Microsoft Management Consoles (MMCs) although EAP-MD5 is not available.
Documentation at http://technet.microsoft.com/en-us/library/bb726965.aspx#ECAA states that support
was removed for all three. Please note the last section stating the removal of certain technologies.
From a VPN client perspective for Windows Vista and Windows Server 2008, EAP-MD5,
MS-CHAP, and SPAP are no longer available as choices.
From a security perspective, do not choose Password Authentication Protocol (PAP) and
MS-CHAP unless necessary to support an incompatible client. MS-CHAP v2 should be used
only when strong passwords are enforced.
Among the supported EAP types, EAP-TLS and PEAP-TLS use certificate-based authentication.
PEAP supports two EAP types, PEAP-TLS and PEAP-MSCHAP v2. When PEAP is used with
the EAP-MSCHAP v2 type, passwords are used to authenticate the user for the connection.
Lesson 1: Perimeter Networks and Remote Access Strategies 243
Once again, strong passwords should be enforced to ensure a higher level of security for the
To provide support for certificates when employing certificate-based authentication with
either EAP-TLS or PEAP-TLS, users require a user certificate on either a smart card or on their
computer. Issuing a certificate through a smart card is not too difficult. Issuing certificates to
users who are mostly remote to store on their computers will require one of three solutions:
■ Have each user manually request a certificate through either the certificate authority
Web enrollment service or the Certificates MMC snap-in.
■ Have an administrator request a certificate on the user’s behalf and manually install the
certificate in the personal store on the user’s computer.
■ Use Group Policy to distribute a certificate to users.
Having each user perform the request individually solves the dilemma of distributing certificates
in most cases. The issue becomes a support problem if too many users need assistance
or other technical difficulties arise. The final answer, to use Group Policy, is probably the most
efficient but can also have problems. Some users using laptops might not be connected to the
network, or the computer itself might not be part of the corporate domain for one reason or
another. In most cases, Group Policy works for the majority of users. Traveling users using laptops
that are part of the domain need to connect and log on to the domain as part of the process
of acquiring a certificate through Group Policy.
Another concern when setting up the environment for remote access connectivity is whether
NAP will be instituted in the near future. For VPN connections, NAP includes a VPN enforcement
point, which requires a connecting client to use one of the PEAP types for authentication.
In choosing which PEAP type to use, PEAP-MSCHAP v2 or PEAP-TLS, PEAP-TLS holds the
advantage as a superior authentication protocol for two reasons:
■ It does not use a password for authentication but uses a certificate as previously noted.
■ PEAP-TLS is superior to EAP-TLS because the exchange of certificates for authentication
takes place after the client and the server have created an encrypted tunnel.
The disadvantage in using PEAP-TLS over PEAP-MSCHAP v2 is that all users now require a certificate
whereas PEAP-MSCHAP v2 requires only a server certificate. An issue in using PEAPMSCHAP
v2 concerns the certificate issued to the VPN server performing the authentication.
If the certificate issued to it is from one of the established trusted public root certification
authorities, no other work is required other than purchasing the certificate itself. If the certificate
is issued from a standalone root CA by the internal enterprise PKI, then a copy of its certificate
needs to be installed on all computers connecting to the VPN using PEAP-MSCHAP v2
for authentication. If the certificate is issued from an enterprise CA, the certificate for the root
CA must be distributed through the Web enrollment, the Certificates console, or another manual
244 Chapter 5 Designing a Network Access Strategy
Designing Secure VPN Server Deployment
When considering the placement of VPN servers, it has become customary for the VPN servers
to be deployed in the perimeter network. Although there are established guidelines for deploying
the VPN server outside of the perimeter firewall, it is considered a best practice to deploy
the VPN server inside the perimeter zone, behind the perimeter firewall. The previous IP filter
tables, Table 5-1 and 5-2, outline the best practices for opening up access to the VPN servers
deployed inside the perimeter network.
If the branch offices need VPN connectivity, two choices are available:
■ Direct VPN connectivity to VPN servers located at the branch offices
■ Centralized management of VPN access to one main office and ensured VPN client
access to resources located in their respective branch offices
VPN Server Deployment at Branch Offices If VPN servers are to be deployed at the branch
offices, you must give the same consideration when setting up access through the firewall
there. The VPN server should be deployed in a perimeter network, often termed a screened
subnet, as Figure 5-4 displays. Availability of affordable firewalls such as ISA Server can provide
a perimeter network and secure access to resources such as a VPN server, making securing
a colocated VPN server an easier chore. Companies can standardize how branch office
access is achieved to relieve the complications involved in planning each deployment.
Figure 5-4 VPN server deployed in the screened subnet
Lesson 1: Perimeter Networks and Remote Access Strategies 245
MORE INFO IP filters
To protect the VPN server further, IP filters can be established with the Windows Server 2008
Firewall feature. Although there is a default program setting for NPS, you can obtain more granular
control by running the Security Configuration Wizard. Microsoft refers to this technique for securing
ports and services as role-based security policies. You can find more information about using this
wizard to configure role-based security settings for an NPS server at http://technet2.microsoft.com
MORE INFO Manually configuring Windows Firewall
To learn more about manually configuring Windows Firewall with Advanced Security, use the
following link to download an entire document devoted to this topic: http://www.microsoft.com
Centralized Management of VPN Access Clients accessing resources through VPN servers
that are centrally located can still access resources anywhere within the enterprise. Because
a VPN connection to a VPN client essentially is offering a local area network (LAN) connection
remotely, a VPN client will also have access anywhere on that LAN that a normal wired LAN
client has access. This is both an advantage and a plausible security issue.
The obvious advantage is the ease in offering resources to the remote client. The VPN client
can be anywhere Internet access is available to gain access to data and application servers on
your enterprise network in a secure manner. To mediate any possible security issues, the VPN
server can enforce strict network routing rules to allow the client access to specific segments
of the network. In addition, filter rules can be applied to the VPN connection to disallow a curious
VPN client from wandering into areas of the network deemed out of bounds. Because a
user with sufficient rights locally can administer his or her own routing tables, the VPN administrator
needs to be aware that such users can circumvent simple security applied through
routing rules. Inbound IP filters and policies applied to the VPN connection can disable a
user’s ability to browse networks that are not authorized by the connection.
Designing a RADIUS Solution for Remote Access
In designing a VPN solution, authentication of VPN clients becomes a paramount concern. In
deciding which protocols to use for the tunnel and which authentication protocols are configured
for access, the next step is how to manage the authentication of those users.
Managing authentication services for multiple services and for multiple points of access for
each of these services rapidly becomes a drain on an administrator’s time. As the enterprise
administrator, you can see the wisdom in centrally managing authentication and authorization
of access to resources.
246 Chapter 5 Designing a Network Access Strategy
Microsoft has had an evolving RADIUS strategy ever since the introduction of Routing and
Remote Access in Windows 2000 Server. Internet Authentication Service (IAS) was the next
iteration and brought along huge improvements. One of the advances was support for a
RADIUS proxy. With Windows Server 2008, the VPN and RADIUS solutions are now part of
its newly renamed NPS.
NPS encompasses many facets of remote access services. It provides the following services:
■ RADIUS client
■ RADIUS proxy
■ RADIUS server
■ RADIUS accounting
■ VPN administration for access and polices
■ Primary console for administering NAP services
Therefore, when designing your RADIUS solution for VPNs and remote access policies, think
about eventually using NAP because NPS plays a central role in this feature.
Designing a RADIUS Solution for the Main Office
In designing a RADIUS solution, consider all the components of a RADIUS infrastructure that
provide authentication, authorization, and accounting. Starting with the access clients and all
the way through the RADIUS infrastructure to the back-end user database, an enterprise
administrator must carefully plot the location of each of these services. Figure 5-5 displays a
real RADIUS design from a high-level overview.
From this overall design, you can see that RADIUS can support authentication for a variety of
services and a variety of access client and access servers. Users of Web-based applications from
either extranets with partners or publicly accessible application servers can be authenticated
using the RADIUS client support built into ISA Server. VPN and dial-up clients can be authenticated
through an NPS server configured as a RADIUS client. Finally, wireless clients, either
guests or WLAN for the corporate environment, can also use the built-in RADIUS client support
in wireless access points to relay RADIUS requests.
Lesson 1: Perimeter Networks and Remote Access Strategies 247
Figure 5-5 RADIUS infrastructure, support elements, and example application support
248 Chapter 5 Designing a Network Access Strategy
Deployment Location for RADIUS Services Securing your RADIUS solution involves
deploying only the essential services in the perimeter network and placing the rest of the services
in the secured, internal network. Using Figure 5-5 as a basis for this discussion, you
would want to place only the following services in the perimeter network while deploying the
rest of the services behind the internal firewall:
■ ISA Server
■ Application servers (probably in a screened subnet connected to ISA Server, leaving any
SQL servers containing the data inside the trusted environment)
■ VPN server
■ Wireless access point
■ RADIUS proxies
Planning RADIUS Communication ISA Server has built-in capabilities to forward authentication
requests to a RADIUS server to centralize authentication for users of published Web
servers, Web application servers, and Windows SharePoint Services Web sites. The application
servers can exist in a screened subnet or in the perimeter network but have access only
through an authenticated request from ISA Server. The data that the application servers draw
upon can be secured in SQL servers behind the internal firewall.
VPN servers with the NPS role installed can be set up as RADIUS clients and forward all
requests to back-end RADIUS proxies. The VPN servers can use a RADIUS server group configuration
to ensure high availability and load balancing of requests.
The wireless access points using 802.1x, WPA Enterprise, or WPA2 Enterprise authentication
services act as RADIUS clients to forward all RADIUS requests through the RADIUS proxies.
The RADIUS proxies then forward those requests to an internal RADIUS server.
Load Balancing and High Availability of a RADIUS Infrastructure Using RADIUS proxies
in your RADIUS design is a strong asset in a RADIUS solution for several reasons. There is
a fine line between a RADIUS client and a RADIUS proxy. To the RADIUS client, the RADIUS
proxy appears to be the RADIUS server where authentication would normally occur. Thus, the
communication between the RADIUS clients and the RADIUS proxies is through the RADIUS
Typically, RADIUS clients do not have a reliable mechanism built into their client architecture
for load balancing their requests across multiple RADIUS servers. Load balancing the RADIUS
client requests is achieved by configuring some of the RADIUS clients to use specific RADIUS
proxy servers as their primary RADIUS servers and configuring other RADIUS clients to use
the remaining RADIUS proxy servers as their primary servers. Each of these two RADIUS client
groups can then use the other’s primary RADIUS server as its secondary RADIUS server.
Lesson 1: Perimeter Networks and Remote Access Strategies 249
This type of load balancing is sufficient for the front end of your RADIUS infrastructure. To
load balance the back end, the RADIUS proxy servers load balance their requests by round
robin with servers of a RADIUS server group.
NPS role service also provides the VPN server role. You can load balance the VPN service, if
necessary, by creating an NLB cluster and ensuring that you set the port rule to single or network
affinity. The port range for the port rule should encompass the proper TCP port (1723)
for PPTP, the UDP ports (500/4500) for L2TP, and TCP port (443) for SSTP.
MORE INFO IP address and subject name configuration for SSTP NLB cluster
To ensure proper setup for NLB when using SSTP, the certificate must be the same computer
certificate on all VPN servers in the NLB cluster. You can find additional information regarding IP
address and subject name configuration for the SSTP NLB cluster at http://support.microsoft.com
Designing a RADIUS Solution for Branch Office Remote Access
If your deployment design calls for distributed VPN remote access, the VPN servers can route
their RADIUS requests to the central office’s RADIUS server. You can use RADIUS proxies if
necessary. To secure the RADIUS communication from the VPN servers through a public network
such as the Internet, you can use VPNs linking the branch offices to the main office to
carry the RADIUS communication. Because the RADIUS protocol encrypts only select portions
of the RADIUS protocol communication, be sure to encrypt the entire RADIUS communication
pathway whenever you need RADIUS communication over great distances. This is
another advantage that ISA Server delivers when you use it to secure access to the branch
offices. ISA Server can also establish the secure VPN that can carry the RADIUS communication
between the branch office VPN servers and the main office RADIUS servers.
Scaling RADIUS Authentication for Multiple Domains and Forests
If your enterprise requires you to authenticate VPN clients from different forests, you have
another issue. RADIUS by default provides authentication for users from the same realm of
which the RADIUS server is a member. To provide RADIUS authentication for multiple realms,
trust relationships must be constructed, or a RADIUS proxy can enable authentication.
For multiple domains of the same forest, no extra trusts are required. For multiple domains
with no trusts or one-way trusts, either create the needed trusts or employ a RADIUS proxy.
A RADIUS proxy can resolve the issue if trust relationships are not possible. A RADIUS server
in a domain foreign to that of the user receives a RADIUS request for authentication. The
RADIUS server without trusts in place with the foreign domain cannot forward the request to
an appropriate realm to authenticate the user. By implementing a RADIUS proxy in the communication
pathway, the RADIUS requests from the RADIUS clients in specific realms can be
250 Chapter 5 Designing a Network Access Strategy
proxied to the correct RADIUS servers to provide a successful authentication for the user. Figure
5-6 displays the design details.
Figure 5-6 RADIUS proxies implemented to provide a successful multi-forest solution
PRACTICE Designing a RADIUS Solution for a Mid-Size Enterprise
You are the enterprise administrator at Contoso, Ltd. Contoso is a mid-size corporation with
offices located in the southeastern United States and the Caribbean. As an enterprise administrator,
you are charged with the task of constructing a VPN solution for all branch offices and
the main office in Ft. Lauderdale, Florida, for Contoso.
With branch offices in Atlanta, Georgia; New Orleans, Louisiana; Orlando, Florida; St. Thomas
in the Virgin Islands; and Grand Cayman in the Cayman Islands, Contoso employs over 2,000
Forest A Forest B
Lesson 1: Perimeter Networks and Remote Access Strategies 251
employees. Offices in the United States are connected by the corporate wide area network
(WAN). Offices in the Caribbean are connected by a site-to-site VPN connection to the Ft.
A single Active Directory Domain Services (AD DS) forest with two domains currently exists
for Contoso. The two domains are contoso.com and caribbean.contoso.com. The Grand Cayman
branch office is a recent acquisition from a competing firm, Fabrikam, Inc. Fabrikam has one
Active Directory forest with one domain, fabrikam.com. You have already moved all Fabrikam
domain controllers to the Ft. Lauderdale office in anticipation of centralized management. The
branch office at Grand Cayman is being sent a read-only domain controller (RODC) for secure
An overall goal is to provide a secure and efficient remote access solution for users in all offices.
Certificate authentication of both users and computers is required for the remote access solution
instead of the current user password–only authentication provided by MS-CHAP. No dialup
services are offered because all users should connect to their offices through the Internet.
Remote access is administered by each office. Administration of remote access policies must
be simplified and duplicated on every VPN server. The remote access setup must allow users
to authenticate to VPN servers at any of the branch offices or the main office.
Contoso wishes to enforce a level of health for all computers connecting through the VPN. Initially,
only a monitored solution is needed to determine the extent of the security problems
with VPN clients.
All domains are run internally by a mixture of Windows Server 2003 and Windows Server
2008 domain controllers. All VPN servers are running on Windows Server 2003.
Exercise 1 Design the VPN Solution
In this exercise, you will review the current enterprise and, based upon the requirements for
the new remote access solution, you will plan a new solution.
1. What are important factors to consider in the current environment when forming a
remote access solution?
❑ Multiple forests with no established trusts between them
❑ Management’s desire to simplify the distributed management of the current
authentication scheme used for remote access
❑ Use of the Internet for all remote access connections
❑ Employment of the highest security by all connections, implying a VPN connection
❑ Security requirements to use a certificate-based authentication service
2. Which authentication protocols can you choose? Why?
❑ EAP-TLS and PEAP-TLS are the only authentication protocols that provide certificatebased
252 Chapter 5 Designing a Network Access Strategy
3. Which VPN protocol should you use?
❑ L2TP because it will provide the security required for both the computer and the
user. SSTP provides a secure and encrypted tunnel using only a server certificate.
Exercise 2 Design the RADIUS Solution
1. What are the primary considerations in moving the VPN connection toward a RADIUS
solution in line with Contoso’s overall goals?
❑ Windows Server 2003 VPN servers need to be upgraded to Windows Server 2008.
❑ In the RADIUS solution, you must consider that a NAP solution will ultimately be
❑ Remote access is currently administered in a distributed fashion. Central administration
of remote access policies is a primary goal.
2. Which components are required of a RADIUS solution for each branch office and the
❑ For all U.S.-based branch offices, only a VPN server is necessary because it will act as
the RADIUS client, forwarding the authentication requests to the Ft. Lauderdale–
based RADIUS proxy servers.
❑ For all Caribbean branch offices, only a VPN server is necessary because it, too,
will act as a RADIUS client by forwarding the authentication requests to the Ft.
Lauderdale–based RADIUS proxy servers.
❑ At the Ft. Lauderdale main office, you need a hierarchy of VPN servers acting as
RADIUS clients forwarding requests to RADIUS servers, along with RADIUS
proxy servers receiving requests from the Cayman Islands, to forward those
requests to the appropriate RADIUS servers in the appropriate domain.
■ Perimeter networks serve as the external barrier between the unsecured Internet and the
secure internal network.
■ Servers deployed in the perimeter network service direct requests from public computers.
Servers in the perimeter network are semi-protected by a perimeter firewall.
■ Servers containing sensitive data such as SQL database servers should be located on the
■ Network Policy Server (NPS) has replaced Internet Authentication Server (IAS) to provide
authentication, authorization, and accounting for RADIUS, management of connection
request policies, and network connection policies.
■ Computer certificates can be distributed through Group Policy for managed computers.
■ VPN servers providing the initial point of access for VPN clients should be deployed in
the perimeter network. A VPN server can provide the authentication or forward the
authentication request to a central location by using RADIUS.
Lesson 1: Perimeter Networks and Remote Access Strategies 253
■ RADIUS can provide centralized authentication, authorization, and accounting for
remote access, 802.1x, and application services.
■ A RADIUS configuration involves an access client (which is actually an access server)
that forwards the authentication request to a RADIUS server or a RADIUS proxy. If a
RADIUS proxy is involved, it too acts much like a RADIUS client and forwards the
request to a RADIUS server.
■ The RADIUS clients and the RADIUS proxy are usually deployed in the perimeter networks.
You can use the following questions to test your knowledge of the information in Lesson 1,
“Perimeter Networks and Remote Access Strategies.” The questions are also available on the
companion CD if you prefer to review them in electronic form.
Answers to these questions and explanations of why each answer choice is correct or incorrect are
located in the “Answers” section at the end of the book.
1. Which of the following performs RADIUS authentication?
A. Access client
B. Access server
C. RADIUS proxy
D. RADIUS server
2. Which of the following does not describe an appropriate function of a RADIUS proxy?
A. Processing requests from access servers and forwarding them to a RADIUS server
B. Processing incoming connection attempts from access clients
C. Load balancing RADIUS requests among servers of the RADIUS Server Group
D. Providing support for multi-forest authentication
254 Chapter 5 Designing a Network Access Strategy
3. Which of the following are true statements regarding authentication protocols used for
remote access? (Choose all that apply.)
A. EAP-TLS uses only the server certificate to create secure communication between
an authenticating client and the authentication server prior to the computer
B. With PEAP-TLS, the computer and server certificates are exchanged over a secure
encrypted tunnel created by only the server certificate.
C. MS-CHAP v2 uses only a user password to authenticate the user attempting a
remote access connection.
D. MS-CHAP v2 provides for mutual authentication of client and server