Windows Server 2008 : Perimeter Networks and Remote Access Strategies (part 3) - Designing a RADIUS Solution for Remote Access

4. 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.

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 displays a real RADIUS design from a high-level overview.

Figure 5. RADIUS infrastructure, support elements, and example application support

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.

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 protocol.

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. 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.

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 proxied to the correct RADIUS servers to provide a successful authentication for the user. Figure 6 displays the design details.

5. 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 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. Lauderdale office.

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 local authentication.

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.

▸ Exercise 2 Design the RADIUS Solution