Design IAS as a RADIUS Server

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Designing IAS as a RADIUS server involves some or all of the following tasks:

  • Determining the IAS server domain membership

  • Planning for RADIUS clients

  • Planning authentication

  • Determining compatibility with third-party access servers

  • Adding RADIUS or vendor-specific attributes (VSAs) to the remote access policy

  • Installing a backup IAS server

For more information about configuring IAS as a RADIUS server, see "Deploy IAS as a RADIUS Server" later in this chapter and "IAS as a RADIUS server" in Help and Support Center for Windows Server 2003.

Determine IAS Server Domain Membership

You must determine which domain the IAS server computer will belong to. In multiple-domain environments, an IAS server can authenticate user credentials for user accounts in the domain in which it is a member and for user accounts in all domains that have a two-way trust relationship with the domain in which it is a member. For increased performance, install IAS on the domain controllers in the domain that will authenticate the users. If you install IAS on a domain controller, you do not have to add the domain controller computer account to the RAS and IAS Servers group of the domain.

For more information about configuring IAS servers, see "Implementing Your IAS Solution" later in this chapter.

Plan for RADIUS Clients

A RADIUS client can be an access server (for example, a dial-up or VPN server, a wireless access point, or an Ethernet authenticating switch) or a RADIUS proxy. IAS supports all access servers and RADIUS proxies that comply with RFC 2865, Remote Authentication Dial-in User Service (RADIUS).

Configure each access server or RADIUS proxy that sends RADIUS request messages to the IAS server as a RADIUS client. For each RADIUS client, you can configure a friendly name, an IP address or DNS name, the client vendor, the shared secret, and whether the RADIUS Message-Authenticator attribute is used.

You can specify IP addresses or DNS names for RADIUS clients. In most cases, it is better to specify RADIUS clients with IP addresses. When you use IP addresses, IAS is not required to resolve host names at startup and starts more quickly as a result. This is especially beneficial if your network contains a large number of RADIUS clients. You can use DNS names to specify RADIUS clients when you require something other than administrative flexibility (for example, the ability to map multiple RADIUS client IP addresses to a single DNS name).

If you are using Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, you can specify a RADIUS client by using an IP address range. All of the RADIUS clients in the range must use the same configuration and shared secret. This configuration is useful, for example, if you place many wireless access points on the same subnet.

The address range for RADIUS clients is expressed in the network prefix length notation w.x.y.z/p, where w.x.y.z is the dotted decimal notation of the address prefix and p is the prefix length (the number of high order bits that define the network prefix). This is also known as Classless Inter-Domain Routing (CIDR) notation. An example is 192.168.21.0/24. For more information, see "Configure RADIUS Clients" in Help and Support Center for Windows Server 2003.

Plan Authentication

When designing network authentication solutions, protecting the authentication channel can prevent potential security attacks.

Most password-based authentication methods, such as CHAP and MS-CHAP, do not provide privacy-protected channels to guard against offline dictionary attacks by hackers that intercept authentication traffic on the network. Because of this, ensure that password-based authentication methods are always deployed with protection from IPSec or PEAP.

EAP-TLS

Certificate-based authentication methods are much more secure than password-based authentication methods. Use certificate-based authentication methods, such as PEAP and EAP, in all possible circumstances because they protect the authentication channel and provide strong security. EAP-TLS is designed, in part, to protect against spoofing or other attacks and can be deployed without protection from IPSec or PEAP. EAP-TLS requires a public key infrastructure (PKI) and is an authentication method that can be used with all connection types supported by IAS (wireless, authenticating switch, VPN, and dial-up).

By using Group Policy in Windows Server 2003, you can easily distribute certificates to clients and servers with auto-enrollment. For the maximum strength user credentials, deploy EAP-TLS with a smart cards. Smart cards provide maximum strength with two-factor authentication. Certificates installed in the computer certificate store (without smart cards) offer single-factor authentication.

PEAP

PEAP uses Secure Sockets Layer (SSL) technology to privacy-protect authentication communications, and to key the encryption of link layer network connections. You can deploy PEAP with either EAP-MS-CHAPv2 or EAP-TLS as the authentication type. PEAP-EAP-MS-CHAPv2 is a secure password authentication method recommended for wireless deployments. However, PEAP is not available for VPN or dial-up connections.

PEAP provides protection for the EAP method negotiation that occurs between client and server through a TLS channel. This helps prevent an attacker from injecting packets between the client and the access server to cause the negotiation of a less secure EAP method.

Clients using PEAP as the authentication method have the ability to authenticate the IAS or RADIUS server. Because the server also authenticates the client, mutual authentication occurs.

PEAP fast reconnect, which reduces the delay in time between an authentication request by a client and the response by the IAS or RADIUS server, allows wireless clients to move between wireless access points without repeated requests for authentication. This reduces resource requirements for both client and server, and allows users to move between access points without reentering credentials.

If you deploy PEAP, do not deploy the same authentication type both inside of the PEAP Transport Layer Security (TLS) channel and outside of the PEAP TLS channel. For example, do not deploy both PEAP-EAP-TLS and EAP-TLS on the same network. You can deploy different authentication types inside and outside the TLS channel. For example, you can deploy PEAP-EAP-MS-CHAPv2 and EAP-TLS on the same network.

Authentication and PPP and PPTP Connections

For dial-up Point-to-Point Protocol (PPP) or Point-to-Point Tunneling Protocol (PPTP) VPN connections, it is recommended that you use EAP-TLS with smart cards or certificates as the authentication method.

For L2TP/IPSec VPN connections, you can use MS-CHAPv2 as the authentication method. Internet Protocol security (IPSec) uses computer certificates to establish a secure channel before authentication proceeds, providing the necessary protection for authentication and other communication.

When planning authentication:

  • For wireless connections, you can configure all the connection properties on the client (including authentication methods) using Windows Server 2003 Group Policy. For example, you can configure wireless connections to specific networks to require use of EAP-TLS.

  • You can use Connection Manager Administration Kit (CMAK) to create a Connection Manager profile for installation on client computers. With Connection Manager, you can manage the client connection properties (including authentication methods) used for access to your network.

  • Configure remote access policies at the IAS server to only allow the authentication methods you want to allow per connection type, such as dial-up or VPN. .

For more information, see "Authentication methods" and "Public Key Infrastructure" in Help and Support Center for Windows Server 2003.

Add RADIUS or VSA Attributes to Remote Access Policy

If you plan to return additional RADIUS attributes or VSAs with the responses to RADIUS requests, you must add the RADIUS attributes or VSAs to the appropriate remote access policy.

Install Backup IAS Servers

To provide fault tolerance for RADIUS-based authentication and accounting, you must always use at least two IAS servers working together in the same location. One IAS server is used as the primary RADIUS server, and the other is used as a backup. RADIUS proxies are configured to use both IAS servers. When the primary IAS server becomes unavailable, the RADIUS proxies automatically use the backup IAS server instead.