Designing IAS

After taking an inventory of your network environment, the first step in designing an IAS solution is to determine the role of the IAS server. For example, determine whether you need the IAS server to authenticate the connection request that it receives, forward the request to another IAS server for authentication, or perform a mixture of both functions depending on context. Finally, an important step in the design process is to configure IAS to work with different types of clients.

Figure 7.3 shows the process for designing IAS.

Figure 7.3: Designing IAS

Inventory Your Current Environment

When beginning your design process, make sure to have specifications about your current network environment available for use. Specifically, your hardware and software inventory and a map of network topology can be very helpful in reducing time spent during the design phase. For more information about creating those documents, see "Planning for Deployment" in Planning, Testing, and Piloting Deployment Projects of this kit.

Determine the Role of the IAS Server

You can configure your IAS server to act as a RADIUS server, a RADIUS proxy, or both, depending on where you want network access requests to be authenticated.

RADIUS server

If you want your IAS server to authenticate the connection requests that it receives, rather than forwarding connection requests to another IAS server, use the IAS server as a RADIUS server. For example, if your access servers connect directly to your network, then the IAS server is configured as a RADIUS server to authenticate the connection.

Figure 7.4 shows an IAS server configured as a RADIUS server. An access client connects to an access server. The access server sends a connection request to an IAS RADIUS server located on the corporate network, which authenticates and authorizes the connection attempt.

Figure 7.4: IAS Configured as a RADIUS Server

RADIUS proxy

If you want an IAS server to forward connection requests to another IAS server, use IAS as a RADIUS proxy. Use the RADIUS proxy capabilities in the following situations.

Using IAS proxy at a third-party ISP

You are an ISP providing outsourced network connection services to multiple customers. Your network access servers send connection requests to the IAS RADIUS proxy. Based on the realm portion of the user name in the connection request, the IAS RADIUS proxy forwards the connection request to a RADIUS server maintained by the customer that can authenticate and authorize the connection attempt.

Figure 7.5 shows an IAS server configured as a RADIUS proxy. An access client contacts an access server at an ISP. The ISP access server sends a connection request to an IAS RADIUS proxy. Based on the realm portion of the user name in the connection request, the IAS RADIUS proxy forwards the connection request to a RADIUS server located on the corporate network, which authenticates and authorizes the connection attempt.

Figure 7.5: IAS Configured as a RADIUS Proxy at a Third-Party ISP

Using IAS proxy with multiple forests

You have multiple forests and want to perform cross-forest authentication with Extensible Authentication Protocol-Transport Layer Security (EAP-TLS). Rather than configuring your access servers to send their connection requests to an IAS RADIUS server, configure them to send their connection requests to an IAS RADIUS proxy.

Figure 7.6 shows an IAS server configured as a RADIUS proxy forwarding RADIUS messages to RADIUS servers in multiple forests. The IAS RADIUS proxy uses the domain name portion of the user name and forwards the request to an IAS server in each forest.

Figure 7.6: IAS as a RADIUS Proxy with Multiple Forests

Using IAS proxy for load balancing

You want to increase the capacity for connection requests. In this case, rather than configure your access servers to attempt to load balance across multiple RADIUS servers, configure them to send their connection requests to an IAS RADIUS proxy. The IAS RADIUS proxy can load balance across multiple RADIUS servers and scale up to large numbers of RADIUS clients and authentications per second.

Figure 7.7 shows an access server forwarding a request to a RADIUS proxy to load balance to multiple RADIUS servers. The remote client connects to a RADIUS client, such as an access server. The access server sends the authentication request to the RADIUS proxy, which load balances the request across different IAS servers.

Figure 7.7: Load Balancing

RADIUS server and proxy

If you need your IAS server to authenticate some requests and forward other requests, use IAS as both a RADIUS server and a RADIUS proxy. For example, if you are performing cross-forest authentication, use your IAS server as a RADIUS server to authenticate users in the same forest, and use it as a RADIUS proxy to forward authentication requests to another IAS server for users in another forest.

Figure 7.8 shows an IAS server configured to be both a RADIUS server and a RADIUS proxy. The remote client connects to an IAS server configured as both a RADIUS server and a RADIUS proxy. Based on the realm portion of the access client user name, the IAS server determines whether to authenticate the request directly or forward the authentication request on to another IAS server in a different forest.

Figure 7.8: IAS Configured as Both a RADIUS Server and a RADIUS Proxy

Design IAS as a RADIUS Server

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

Design IAS as a RADIUS Proxy

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

• Planning the connection request policy

• Adding RADIUS and VSA attributes

• Planning for load balancing and failure detection

• Installing backup IAS proxies

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

Plan the connection request policy

The default connection request policy Use Windows authentication for all users is configured for IAS when it is used as a RADIUS server. To create a connection request policy to use IAS as a RADIUS proxy, complete the following steps:

1. Create a remote RADIUS server group on the domain that will authenticate the users.

2. Create a connection request policy that forwards authentication requests to the remote RADIUS server group.

3. Either delete the default connection request policy, or set the new connection request policy first in the order before the default connection request policy so that it is evaluated first.

Add RADIUS attributes and VSAs

If you plan to return additional RADIUS attributes and VSAs with RADIUS requests, you must add the RADIUS attributes and VSAs to the appropriate connection request policy.

Plan for load balancing and failure detection

When you configure multiple servers in a remote RADIUS server group, you can configure settings that determine how the IAS proxy server balances the load of authentication and accounting requests over the RADIUS servers in the group. You can use additional settings to configure IAS to detect and recover from the failure of a remote RADIUS server group member.

For more information about load balancing for remote RADIUS server group members, see "Configure the load balancing properties of a group member" in Help and Support Center for Windows Server 2003.

Install backup RADIUS proxies

To provide fault tolerance for RADIUS-based authentication and accounting, you must always use at least two IAS proxy servers. One IAS server is used as the primary RADIUS proxy, and the other is used as a backup. RADIUS clients (access servers or other RADIUS proxies) are configured on both IAS proxy servers. In addition, configure both the primary and backup IAS proxy servers on each RADIUS client. When the primary IAS proxy becomes unavailable, the access servers automatically use the backup RADIUS server instead.

For more information about synchronizing the configuration of multiple IAS servers, see "Managing multiple IAS servers" in Help and Support Center for Windows Server 2003.

Designing Support for Client Access

After you have designed your IAS infrastructure and determined what role IAS will play in your network, you must consider what types of network and remote access clients you will need to support. For each type, your IAS server configuration will differ, and you will need to make different planning decisions.

Windows Server 2003 IAS supports the following forms of network access:

• Dial-up remote

• VPN

• Wireless

• Authenticating switch

Note

You can use the Routing and Remote Access service included with Windows Server 2003 or the Microsoft Windows 2000 operating system to provide network access. However, you can also use third-party network access servers with Windows Server 2003 IAS. To ensure that the third-party access server works with Windows Server 2003 IAS, check with the manufacturer to confirm that the product supports RFCs 2865, 2866, and 2869.

Designing Support for Dial-up Access

Windows Server 2003 has extensive support for remote access technology to connect dial-up and other types of remote clients to corporate networks or to the Internet. For information about how to plan, design, and implement Windows Server 2003 components (such as Routing and Remote Access Service and Connection Manager) in an enterprise environment, see "Deploying Remote Access Clients Using Connection Manager" in this book.

IAS supports both voluntary and compulsory tunneling. Table 7.1 describes the differences between both types of tunneling and when you might use each type.

Table 7.1: Comparison of Voluntary and Compulsory Tunneling

Tunnel Type	When to Use It	Which IAS Components to Use
Voluntary tunneling	Use this option if your clients need to choose their tunneling location themselves. For example, the user dials in to an ISP. At the client's request, the ISP creates a tunnel to the corporation. The user can alternatively request a tunnel to somewhere else, such as the Internet.	The ISP uses IAS as a RADIUS proxy to forward the request to the corporate IAS server. The corporation uses IAS as a RADIUS server to authorize and authenticate the request. Either the ISP or the corporation can use a third-party RADIUS server.
Compulsory tunneling	Use this option if you want to use one tunnel for many clients. For example, if a corporation has clients in geographically dispersed locations, it can contract with an ISP to deploy regional tunnel servers. Any client can dial in to any of the tunnel servers, which then creates a compulsory tunnel to the corporation. Compulsory tunneling is typically used for dial-up clients, but can also be used for VPN clients.	The ISP uses IAS as a RADIUS server to authorize the request. The corporation uses IAS as a RADIUS server to authorize and authenticate the request. Either the ISP or the corporation can use a third-party RADIUS server.

Voluntary Tunneling

In voluntary tunneling, during the authorization phase, the corporate IAS server restricts the client connection to use a specific VPN protocol (PPTP or L2TP/IPSec) if an administrator has configured remote access policies to restrict connections to those using the specified protocol. The designated protocol must be installed on the client or the connection attempt is rejected. After the access request is authenticated and authorized, the client establishes a VPN tunnel to the corporate access server.

A user or client computer can issue a VPN request to configure and create a voluntary tunnel. In this case, the user's computer is a tunnel endpoint that acts as the tunnel client. Voluntary tunneling occurs when a workstation or router uses tunneling client software to create a VPN connection to the target tunnel server. In order to accomplish this, the appropriate tunneling protocol must be installed on the client computer. In a dial-up situation, which is the most common use, the client must establish a dial-up connection to the internetwork before the client can set up a tunnel. A good example of this is the dial-up Internet user, who must dial an ISP and obtain an Internet connection before a tunnel over the Internet is created.

Voluntary tunneling is not different from other types of network access, and IAS can be used for authentication, authorization, and accounting.

Compulsory Tunneling

Compulsory tunneling is the creation of a secure tunnel by another computer or network device on the client computer's behalf. Compulsory tunnels are configured and created automatically for users without their knowledge or intervention. With a compulsory tunnel, the user's computer is not a tunnel endpoint. Another device between the user's computer and the tunnel server is the tunnel endpoint, which acts as the tunnel client.

The computer or network device that provides the tunnel for the client computer is known as a front-end processor (FEP) in PPTP, an L2TP access concentrator (LAC) in L2TP, or an IP security gateway in IPSec. The term FEP is used to describe tunnel creation functionality, regardless of the protocol used. To perform its function, the FEP must have the appropriate tunneling protocol installed and must be capable of establishing the tunnel when the client computer attempts a connection. In Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; and Windows 2000, the Routing and Remote Access service cannot be used as a FEP.

An organization can contract with an ISP to deploy a nationwide set of FEPs. These FEPs can establish tunnels across the Internet to a VPN server that is connected to the organization private network, thereby consolidating calls from geographically diverse locations into a single Internet connection at the organization network.

There are two types of compulsory tunneling. In the first type, the tunnel is created before the access client is authenticated. Based on the realm name or the caller ID of the access client, the FEP sends an Access-Request message to an IAS server. The IAS server sends back an immediate Access-Accept message with RADIUS attributes for the tunnel creation without performing authentication and authorization. After the tunnel is created, the access client authenticates against the tunnel server.

In the second type of compulsory tunneling, the tunnel is created after the access client is authenticated by the FEP. In this case, the FEP sends the Access-Request message with the client credentials to an IAS server. The IAS server authenticates and authorizes the connection attempt and returns RADIUS attributes in the Access-Accept message, which specify to the NAS how to initiate a tunnel to a VPN server. The tunnel endpoint (the VPN server at which the tunnel is terminated), can be changed on the basis of conditions in a remote access policy. For example, the tunnel endpoint can be changed on the basis of the user name or the user account group membership. Controlling compulsory tunnels with remote access policies provides more flexibility than static tunneling (which requires a dedicated access server) or realm-based tunneling (which requires all users in a specific realm to use the same tunnel settings).

For more information, see "IAS and tunnels" in Help and Support Center for Windows Server 2003.

Designing Support for VPN Access

Depending on the credentials of the authenticating user, you can configure IAS to direct the traffic from a VPN client through a tunnel to specific parts of the enterprise network. Both voluntary and compulsory tunneling can be used for outsourced VPN access.

Special Considerations for VPN Access

Consider the following access server compatibility issues:

• IAS can provide compulsory tunneling connection attributes for network access servers (NASs) that support compulsory tunneling. However, the Windows Server 2003 Routing and Remote Access service does not support compulsory tunneling.

• VPN servers running the Microsoft Windows NT version 4.0 operating system must also be running Routing and Remote Access Service (RRAS) if you want to configure them as RADIUS clients.

For more information about Internet Authentication Service, including the authorization and authentication process used in voluntary and compulsory tunneling, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).

For information about the RADIUS attributes used with compulsory tunneling, see "Compulsory tunnels" in Help and Support Center for Windows Server 2003.

Designing Support for Wireless Access

Wireless networking technology is becoming more widespread with the adoption of industry standards such as IEEE 802.11 and 802.11b. Wireless networking allows a user to roam around a building or campus and automatically connect to the network after the user is in proximity to a wireless access point (wireless AP).

You can use IAS to support wireless access in the following scenarios:

• Wireless LAN access

• Outsourced wireless access

Countering Wireless Security Risks

While providing convenience, wireless networking technologies and wireless APs represent the following security risks:

• Anyone who has a compatible wireless network adapter can gain access to the network.

• Wireless networking signals use radio waves to send and receive information. Anyone within an appropriate distance to a wireless access point can detect and receive all data sent to and from the wireless access point.

IAS provides enhanced security for wireless access. To counter the first security risk, you can set up the wireless access point as a RADIUS client, and then configure it to send access requests and accounting messages to a central RADIUS server running IAS.

To counter the second security risk, you can encrypt the data sent between the wireless devices and the wireless access points. The authentication method used by the wireless client must be able to use encryption keys.

Special Considerations for Wireless Access

If you will be supporting wireless access, include the following elements in your design:

• An authentication mechanism. With wireless access, you can use Protected Extensible Authentication Protocol (PEAP), EAP-TLS, or unauthenticated wireless access. For more information on PEAP, see "PEAP" in Help and Support Center for Windows Server 2003.

• Certificates and a certification authority, if you are deploying authentication methods that use certificates on both the client and server, such as EAP-TLS. For more information, see "Integrate IAS with the Certificate Infrastructure" later in this chapter.

• The Wireless-IEEE 802.11 and Wireless-Other port types for the NAS-Port-Type condition of remote access policies. By using these port types, you can create a separate remote access policy that contains connection parameters and encryption settings specifically designed for wireless devices.

• The Ignore-User-Dialin-Properties attribute in the profile settings of a remote access policy. The dial-in properties of the user account are designed for clients dialing into an access server, not for clients connecting to a wireless port or authenticating switch. You can disable them on the remote access policy. For more information about profile settings, see "Dial-in properties of a user account" in Help and Support Center for Windows Server 2003.

Designing Support for Authenticating Switch Access

A network switch filters the traffic received on each port of the switch and allows better traffic management by segmenting a network. A typical switch, however, sends and receives packets to any node that is connected to it. This can create a security risk, especially for switch ports in a conference room of an organization, which might be accessed by visitors or employees of partner organizations.

Securing Authenticating Switch Access with IAS

To prevent physical layer access to the network, use authenticating switches as RADIUS clients and use the industry-standard RADIUS protocol to send access requests and accounting messages to a central RADIUS server. The RADIUS server has access to a user account database and a set of rules for determining whether to grant authorization.

If you need to grant access to different types of users for different parts of your network, you can use authenticating switch access. For example, a corporate conference room has a virtual local area network (VLAN) for visitors. A visitor logging on without presenting credentials is granted access to the conference room VLAN. At the same time, an employee logging on with appropriate credentials is granted access to the entire corporate network. Thus, administrators can use IAS with authenticating switch access to secure parts of the network from malicious users and from inexperienced users who might inadvertently cause errors in network configuration. You can also use VLANS with IAS for wireless access configurations.

Because the data sent between the node and the authenticating switch physically travels on a dedicated wire, encryption of the data is not required or typically implemented.

Special Considerations for Authenticating Switch Access

If you will be supporting authenticating switch access, include the following elements in your design:

• An authentication mechanism. You can use EAP-TLS or secure password-based authentication by using PEAP-EAP-MS-CHAPv2. For more information, see "Select Authentication Protocols" later in this chapter.

• Certificates and a certification authority, if you are deploying authentication methods that use certificates on both the client and server, such as EAP-TLS. For more information, see "Integrate IAS with the Certificate Infrastructure" later in this chapter.

• The use of the Ethernet port type for the NAS-Port-Type condition of remote access policies. By using this port type, you can create a separate remote access policy that contains connection parameters specifically designed for nodes connecting to the network through an authenticating switch. For more information, see "Elements of a remote access policy" in Help and Support Center for Windows Server 2003.

• The Ignore-User-Dialin-Properties attribute in the profile settings of a remote access policy. The dial-in properties of the user account are designed for clients dialing into an access server, not for clients dialing into a wireless port or authenticating switch. You can disable them on the remote access policy. For more information, see "Dial-in properties of a user account" in Help and Support Center for Windows Server 2003.