Lesson 5: Planning RADIUS Security

The Internet Authentication Service (IAS) in Windows 2000 allows centralized application of remote access security. IAS is Microsoft's deployment of the Remote Authentication Dial-In User Service (RADIUS) protocol. RADIUS allows centralized authentication, accounting, and management of remote access policy.

---

After this lesson, you will be able to

• Design a RADIUS deployment to allow single sign-on and provide centralized remote access policy deployment

Estimated lesson time: 30 minutes

---

Introducing RADIUS Authentication

In a Windows 2000 network, RADIUS allows single sign-on capabilities to remote users by allowing them to authenticate with the domain account and password. Single sign-on allows access to all resources on a network with a single user account and password, rather than having to provide different account/password combinations for connecting to the ISP and to the corporate network through a VPN connection. This single user account and password can be used at any remote access server or network device that's configured as a RADIUS client to the IAS server.

This lesson examines the components required for deploying RADIUS and explains how RADIUS enables centralized management of remote access policy.

Designing RADIUS Deployments

A RADIUS infrastructure requires servers that play different roles in the RADIUS authentication process. The servers required for a RADIUS deployment include

• RADIUS server. The RADIUS server provides remote access authentication, authorization, and accounting services. Rather than each remote access server providing these services, the services are centralized at a single RADIUS server.
• RADIUS clients. RADIUS clients include remote access servers, tunnel servers, and network access servers that can accept remote access client connections. A RADIUS client does not perform authentication, authorization, or account services. Instead, the requests are forwarded to the configured RADIUS server.
• Remote access clients. Remote access clients connect to the network using dial-up or VPN connections. Remote access clients may have to provide a prefix or suffix to identify the RADIUS server that a RADIUS proxy must forward the RADIUS authentication request to.
• RADIUS proxy. In some circumstances an organization such as an ISP may have network access servers that forward authentication requests to RADIUS servers from multiple organizations. A RADIUS proxy is able to determine the correct RADIUS server by inspecting prefixes and suffixes appended to the user name provided by the remote access clients.

NOTE

---

Windows 2000 does not provide a RADIUS proxy service. If you require a RADIUS proxy in your RADIUS deployment, you must deploy either a third-party RADIUS server or the RADIUS proxy that's included in the Internet Connection Services for RAS for Windows NT 4.0.

RADIUS authentication provides single sign-on capabilities to remote access clients. In other words, when connecting to the network by using a VPN, a single password can be used to authenticate with both an ISP and the corporate network. Understanding how RADIUS authentication takes place will help you design server placement for a RADIUS deployment. Figure 13.12 shows how RADIUS authentication proceeds when a user connects to the corporate network by first connecting to an ISP.

Figure 13.12 The RADIUS authentication process for a VPN client

1. The remote access client connects to an ISP by dialing the phone number of the ISP's modem. The modem is attached to the ISP's NAS.
2. The NAS is configured as a RADIUS client to the RADIUS proxy server located at the ISP. The NAS sends the authentication request to the RADIUS proxy server in a RADIUS authentication message format.
3. The RADIUS proxy server looks at its table of known suffixes and prefixes. For example, if the user name provided was [e-mail], the RADIUS proxy would forward the authentication request to the dial.hotmail.com RADIUS server.
4. The RADIUS proxy forwards the authentication request to the appropriate RADIUS server. This request is known as a proxied RADIUS authentication message.
5. The RADIUS server verifies the credentials in the proxied authentication request and accepts or rejects the request. The request is compared to remote access policy to determine if the connection attempt should be accepted or rejected. If the attempt is accepted, the RADIUS response is sent to the RADIUS proxy in a RADIUS authentication acknowledge message.
6. The RADIUS proxy forwards the RADIUS authentication message as a proxied RADIUS authentication acknowledge message to the NAS.
7. The NAS informs the user that she is successfully authenticated on the network. In addition to authentication, the NAS then assigns TCP/IP configuration information to the remote access client. This TCP/IP configuration information includes the client's IP address, default gateway, and subnet mask.

   Now that the connection to the Internet is authenticated and established, the client can begin the process of connecting to the corporate network by establishing a VPN to the corporate office.

8. The remote access client sends the user's authentication request to the configured tunnel server at the user's local office using either PPTP or L2TP/IPSec as the VPN protocol.
9. The tunnel server, configured as a RADIUS client, creates a RADIUS authentication message and sends it to the RADIUS server.
10. The RADIUS server verifies the user's credentials in the authentication request and accepts or rejects the authentication request. The request is compared to remote access policy to determine if the connection attempt should be accepted or rejected. If the attempt is accepted, the RADIUS response is sent to the tunnel server.
11. The tunnel server passes the authentication message and any IP configuration details to the remote access client.

All authentication requests are passed to the directory source utilized by the RADIUS server. In the case of IAS, the authentication requests are forwarded to Active Directory.

Making the Decision

When designing a RADIUS solution for your organization, you must determine which RADIUS roles are required to provide single sign-on capabilities. Table 13.15 outlines when to include the various RADIUS components in your remote access design.

Table 13.15 Planning RADIUS Component Use

Use	To Perform the Following Tasks
RADIUS servers	To centralize remote access policy application in a Windows 2000 network To centralize authentication requests to a single directory store To centralize accounting information for remote access at a single location
RADIUS clients	To forward all authentication and accounting requests to the configured RADIUS server To receive centralized remote access policy from the configured RADIUS server
RADIUS proxies	To allow the hosting of authentication services for multiple organizations through the same phone number or tunnel server IP address To provide informed routing of RADIUS authentication packets to the correct RADIUS server based on either a prefix or suffix provided by the remote access client

Applying the Decision

To provide centralized management of authentication, you must configure the remote access servers at the Warroad, Boise, and Calgary offices as RADIUS clients to a RADIUS server at the Warroad office, as shown in Figure 13.13.

Figure 13.13 The RADIUS authentication process for a VPN client

The RADIUS server allows all users to authenticate by using their domain account and password. In addition, the RADIUS server allows centralized management of remote access policy and centralized collection of accounting information for all remote access connectivity.

Planning Centralized Application of Remote Access Policy

Decentralized application of remote access policy can result in inconsistent configurations at each remote access server. Figure 13.14 illustrates a situation commonly caused by decentralized application of remote access policy.

Figure 13.14 Decentralized application of remote access policy

In this situation clients are denied remote access if they connect to the remote access server1 but gain access if they connect to the remote access server2. Such inconsistent application of remote access policy can result in authorized users being denied access and unauthorized users gaining access to the network.

RADIUS servers allow the centralization of remote access policy. When the remote access servers are configured as RADIUS clients, they no longer configure remote access policy locally. Instead the remote access policy is obtained from the RADIUS server, which acts as the repository for remote access policy, as shown in Figure 13.15.

With the remote access servers configured as RADIUS clients, the remote user gains access to the network no matter which remote access server she accesses. Both servers have the same remote access policy, which is stored locally at the RADIUS server.

Figure 13.15 Centralized application of remote access policy with RADIUS

IMPORTANT

---

RADIUS does expose a single point of failure if the server hosting the IAS service were to fail. Make sure that the configuration is backed up using the Netsh utility.

RADIUS servers allow you to centralize remote access policy at a single location for editing purposes. When a server running RRAS is configured as a RADIUS client, it receives its remote access policy from the RADIUS server. Remote access policy won't appear in the Routing And Remote Access console when the remote access server is configured as a RADIUS client.

In addition to configuring the existing remote access servers as RADIUS clients, you must prevent the deployment of new remote access servers that aren't configured as RADIUS clients. You can do this by using Group Policy to either enable or disable RRAS for Windows 2000–based computers. In addition to enabling or disabling RRAS, you can also change the permissions for the service to restrict who can start, stop, or pause the service.

To ensure that only the approved remote access servers are running RRAS, you can place the remote access servers in a dedicated organizational unit (OU). You can create a Group Policy object that enables RRAS. In addition, at the domain you can configure the Default Domain Policy to disable RRAS. Group Policy inheritance applies the service setting to all other OUs in the domain, as illustrated in Figure 13.16.

Figure 13.16 Configuring Group Policy to enable RRAS only for authorized servers

Making the Decision

To ensure that only centralized application of remote access policy takes place, you must include the following items in your security design:

• Ensure that a server on the network is configured with the IAS service. The IAS server will host the centralized remote access policy to be deployed to RADIUS clients.
• Configure all authorized remote access servers as RADIUS clients. Remote access servers configured as RADIUS clients will receive their remote access policy from the RADIUS server. The remote access policy option won't exist within the MMC console once the remote access server is configured as a RADIUS client.
• Ensure that RRAS is disabled on all unauthorized remote access servers. Use Group Policy to ensure that RRAS is disabled on all unauthorized remote access servers. Configure permissions to restrict the ability to start, pause, and start RRAS to Domain Admins.

Applying the Decision

Hanson Brothers requires centralized management of remote access policies from the Warroad office. To prevent unauthorized remote access servers from being deployed, you can configure the default domain Group Policy to disable RRAS on all domain computers. In addition, you can place the remote access servers for each office in an OU where Group Policy enables RRAS.

To ensure that centralized remote access policy is applied, the remote access servers must be configured as RADIUS clients to the RADIUS server located at the Warroad office as shown previously in Figure 13.13.

Lesson Summary

RADIUS gives you the ability to centralize remote access security management. By configuring servers running RRAS as RADIUS clients to a common RADIUS server, you ensure that remote access policy design and deployment is centralized at the RADIUS server. Centralized management of RADIUS policy prevents inconsistent security from being applied to remote access connections.