Using RADIUS Authentication for ISA Server 2004 VPN Remote Client Connections

One of the fundamental capabilities of Microsoft Internet Security and Acceleration (ISA) Server 2004 is the ability to apply a firewall policy to specific users. By default, ISA Server can authenticate users against local accounts on the ISA Server computer, communicate with the Active Directory directory service servers (for Microsoft Windows authentication) and with Remote Authentication Dial-In User Service (RADIUS) servers.

RADIUS is an industry standard authentication protocol. RADIUS authenticates users through a series of communications between RADIUS clients and the RADIUS server. A RADIUS client (in this case, ISA Server) passes information about a user to a designated RADIUS server, and then acts on the response that the RADIUS server returns. Transactions between the RADIUS client and the RADIUS server are authenticated through use of a shared secret, which is never sent over the network.

The client creates an Access-Request message that contains user information, including attributes such as user name, password, and port that the user is accessing. The Access-Request message is submitted to the RADIUS server over the network, and any user password between the client and server is encrypted using the shared secret. If no response is returned within a specified length of time, the request is resent.

When the RADIUS server receives the request, it first validates the RADIUS client. If the RADIUS client cannot be validated, the RADIUS server does not respond, not even to reject the connection request. After validating the RADIUS client, the RADIUS server then checks a user database to match the user making the request. The RADIUS server returns a response in the form of Access-Accept or Access-Deny to the client. Note the following behavior with ISA Server:

• The RADIUS response may carry authorization information in the form of access attributes as part of the response to the client. Typically RADIUS implementations apply these returned access restrictions. ISA Server does not support this functionality, it simply acts on the accept or deny response.
  
• When ISA Server receives a deny response, this may indicate that the RADIUS server does not authorize the client. Even if the credentials have been authenticated, ISA Server may reject the client request based on the RADIUS server authorization policy.
  

For more information about RADIUS authentication and accounting, see RFC 2865 and RFC 2866.

On This Page

• Internet Authentication Service
  
• Reasons for Deploying ISA Server with RADIUS authentication
  
• Configure RADIUS Authentication for VPN Connections
  
• Appendix A: Best Practices for RADIUS Server Configuration
  
• Appendix B: Authentication Protocols Overview
  
• Appendix C: Connection Protocols Overview
  

Internet Authentication Service (IAS) is the Microsoft implementation of a RADIUS server. IAS performs centralized connection authentication and authorization, and accounts for many types of network access. If you install IAS as an Active Directory domain member, IAS validates credentials against user accounts in Active Directory. An IAS server can authenticate 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. For increased performance, you can install IAS on a domain controller, but that is not necessary. If you install IAS in workgroup mode, and not as a domain member, IAS validates credentials against user accounts in the local Security Accounts Manager (SAM). For more information about configuring IAS as a RADIUS server, see IAS Concepts, and Overview of IAS deployment in the Microsoft Windows Server™ 2003 documentation.

On IAS servers, the authentication process can be summarized as follows:

1. The RADIUS client (ISA Server) sends the authentication request to an IAS server in the form of a RADIUS Access-Request packet.
   
2. The IAS server verifies that the Access-Request packet is sent from a configured RADIUS client by checking the source IP address.
   
3. If the Access-Request packet was sent by a valid RADIUS client and message authenticator (also known as the digital signature) is enabled for the RADIUS client, the digital signature in the packet is checked using the shared secret. Each IAS server must have a shared secret for each RADIUS client, and the shared secret must be exactly the same for both server and client. If a digital signature is enabled and fails (or is not present), IAS silently discards the packet. In an Active Directory environment, if the IAS server cannot connect to the domain controller or find the domain controller to which the user belongs, it silently discards the packet. If the RADIUS client does not receive a response within its time-out period, it retries the request. Note the following:
   
   1. You can configure the time-out period for retrying the request in ISA Server Management. For instructions, see To configure the RADIUS server in ISA Server Management.
      
   2. The message authenticator attribute is always used with Extensible Authentication Protocol (EAP) authentication. If you want to enable the use of the message authenticator attribute for the Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), and MS-CHAP version 2 (MS-CHAP v2), enable it on both the IAS server and on ISA Server. You can configure the message authenticator attribute in ISA Server Management. For instructions, see To configure the RADIUS server in ISA Server Management.
      
4. The IAS server queries the user database to validate the user credentials. If the IAS server uses Active Directory, and the credentials are authentic, the IAS server evaluates the connection attempt against configured remote access policies and the dial-in properties of the user’s account, to determine whether to authorize the request. For instructions, see To configure the RADIUS server in ISA Server Management. Note the following:
   
   1. If the request is authorized, IAS sends a RADIUS Access-Accept message to the RADIUS client. The Access-Accept message can also contain connection parameters based on the remote access policy profile settings and the dial-in properties of the user account.
      
   2. If the user is not authenticated, or the user’s connection attempt does not match at least one remote access policy, or matches conditions in a policy that denies access, IAS sends a RADIUS Access-Reject message to the ISA Server computer.
      

There are many advantages in deploying ISA Server with RADIUS authentication:

• RADIUS servers do not require domain membership of RADIUS clients from which authentication requests originate. As a result, ISA Server, as a RADIUS client, does not need to belong to a domain for authentication purposes.
  
• The RADIUS protocol is limited to a single User Datagram Protocol (UDP) connection. Added to the fact that ISA Server does not have to be a domain member for authentication purposes, this makes RADIUS useful in a perimeter network (also known as DMZ, demilitarized zone, or screened subnet) configuration.
  
• You can define remote access policies on the RADIUS server. This allows you to define network restrictions (for example, limiting the number of concurrent logons for a user).
  
• RADIUS authentication provides centralized RADIUS accounting to track network activity for remote virtual private network (VPN) clients.
  

For more information about deploying a RADIUS server securely with ISA Server, see the section Appendix A: Best Practices for RADIUS Server Configuration.

This section describes how to configure RADIUS authentication (using IAS) for VPN connections.

There are several configuration steps you need to perform to configure a VPN connection with RADIUS authentication, as follows:

• Step 1. Configure IAS with ISA Server as a RADIUS client, and in ISA Server, specify the RADIUS server that should be used for authentication. For more details, see Step 1: Configure IAS Server.
  
• Step 2. Configure VPN with RADIUS authentication. There are several general VPN properties you must configure before setting up a remote client-to-site connection, or a site-to-site connection. For more details, see Step 2: Configure General VPN Properties and VPN RADIUS Authentication.
  
• Step 3. Configure the VPN remote client-to-site connection. For instructions, see Step 3: Set Up a VPN Remote Client-to-Site Connection.
  

Step 1: Configure IAS Server

After installing the IAS Server (and registering it in Active Directory if it is a domain member), complete the following steps to configure IAS for VPN authentication, and specify the RADIUS server to use for authentication in ISA Server Management:

1. Configure ISA Server as a RADIUS client in IAS. For the IAS server to authenticate VPN connections from ISA Server, ISA Server must be configured as a RADIUS client.
   
2. Create a VPN Client account with dial-in permissions. If the IAS server is a domain member and authenticates against a domain controller, the user account requiring authentication must reside on that domain controller. For ease of management, you can create a domain group called VPN_clients, and add user accounts with dial-in access to that group.
   
3. Configure a remote access policy for VPN clients. In addition to allowing dial-in access for a user account, you can provide more granular access control by means of a remote access policy. For example, you can specify the time of day that access is allowed, or restrict connection properties. For simple management, you can grant authorization with remote access policy on a domain group account containing all user accounts, such as the VPN clients group described previously (with dial-in permissions enabled and control access with remote access policy set). Use this feature when IAS is a domain member using Active Directory for authentication, and Active Directory is running in Windows Server 2003 or Windows Windows 2000 native mode.
   
4. Configure the RADIUS server in ISA Server Management. When you configure the RADIUS server that ISA Server should use for authentication, specify the following:
   
   1. Select an IAS RADIUS server.
      
   2. Specify a shared secret (which must be identical on the ISA Server computer and on the IAS server).
      
   3. Select the port used by the RADIUS server for incoming RADIUS authentication requests. (The default is UDP port 1812.)
      
   4. Configure the time-out (in seconds) for retrying requests.
      
   5. Specify whether message authenticator should be used.
      Note: The RADIUS server configuration you specify is applied to all Web listeners or network objects using RADIUS authentication.
5. Enable the RADIUS system policy rule. Enable this RADIUS system policy rule to allow RADIUS and RADIUS accounting protocol traffic (UDP ports 1812 and 1813) from the ISA Server computer (Local Host network) to the Internal network. This rule assumes that the RADIUS server is located in the Internal network. You can modify this rule to indicate the specific RADIUS server rather than the entire Internal network.
   
6. Monitor the RADIUS server. At any time, you can monitor the RADIUS server. Create a connectivity verifier to monitor the status of the server. Configure alerts so that appropriate action is taken when the IAS server is not working.
   

To configure ISA Server as a RADIUS client in IAS

You must configure IAS to recognize ISA Server as a RADIUS client. Note that you should specify the same details here as you will specify later when you configure RADIUS settings in ISA Server Management. Follow these steps:

1. On the computer running IAS, click Start, point to Administrative Tools, and then click Internet Authentication Service.
   
2. From the Internet Authentication Service management console, right-click the RADIUS Clients folder, and then click New RADIUS Client.
   
3. In Friendly name, enter a name for the ISA Server computer. In Client address (IP or DNS), enter the IP address of the ISA Server internal adapter. Click Next.
   
4. In Client-Vendor, ensure that RADIUS Standard is selected. In Shared secret, specify a password, and in Confirm shared secret, confirm the password.
   
5. Ensure that Request must contain the Message Authenticator attribute is selected.
   Note: You can specify IP addresses or DNS names for RADIUS clients. In most cases, it is more efficient to specify IP addresses, because this prevents IAS from needing to resolve client names at startup. 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. For more information about expressing such an address range for RADIUS clients, see Configure RADIUS clients in Help and Support Center for Windows Server 2003.

To create a VPN Client account with dial-in permissions

When the IAS server uses Active Directory authentication, the user accounts to be authenticated must be configured on the domain controller. For easy management, on the domain controller, create a new user group called VPN_clients with dial-in permissions. Then, add users to the group.

To create the group:

1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
   
2. In the console tree, click to expand the domain name.
   
3. Right-click Users, click New, and then click Group.
   
4. Type a name for the new group. For example VPN_clients.
   
5. Click to select Global Domain for the Group Scope, and then click to select Security for the Group Type.
   

To add users to the group:

1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
   
2. In the console tree, click to expand the domain name.
   
3. Right-click Users. For each user you want to add to the VPN_clients group, do the following:
   
   1. Double-click the user to display its properties.
      
   2. On the Member Of tab, click Add, choose VPN_clients, and then click OK.
      
   3. On the Dial-in tab, check that Control access through Remote Access Policy is selected. Then, click OK.
      Note: This option is only available in a Windows Server 2003 domain or Windows 2000 native mode.

To configure a remote access policy for VPN clients

Configure a remote access policy as follows:

1. In the Internet Authentication Service console, right-click Remote Access Policies, and then click New Remote Access Policy. Click Next.
   
2. In Policy Configuration Method, select Use the wizard to set up a typical policy for a common scenario. In Policy name, specify a name for the remote access policy. Click Next.
   
3. In Access Method, specify the type of connection for which policy conditions will be set. In this case, VPN. Then click Next.
   
4. In User or Group Access, click Group, and then click Add. In Select Groups, type the name of the group containing the clients you want to allow VPN access. In this case, VPN_clients.
   
5. Click Check Names to confirm you have specified the group correctly. Click OK, and then click Next.
   
6. To authenticate VPN clients using RADIUS, in Authentication methods, leave Microsoft Encrypted Authentication version 2 (MS-CHAP v2) enabled. You may also want to enable EAP authentication. Then, click Next. In Policy Encryption Level, select the check boxes appropriate for your VPN client. For Windows XP and Windows 2000 clients, you can disable Basic encryption and Strong encryption. Then, click Next.
   
7. Click Finish to complete the New Remote Access Policy Wizard.
   

To configure the RADIUS server in ISA Server Management

Configure the RADIUS server in ISA Server as follows:

1. In ISA Server Management, click to expand the Configuration node, and then click General.
   
2. In the details pane, click Define RADIUS Servers.
   
3. On the RADIUS Servers tab, click Add.
   
4. In Server name, type the name or IP address of the RADIUS server to be used for authentication. (In this case, the IAS server is in the Internal network with an IP address of 10.0.0.1).
   
5. Click Change, and in New secret and Confirm new secret, type the shared secret to be used for communications between the ISA Server computer and the RADIUS server. Be sure to specify the same secret you entered when configuring ISA Server as a client on the RADIUS server.
   
6. In Port, specify the UDP port used by the RADIUS server for incoming RADIUS authentication requests. The default value of 1812 is based on RFC 2138.
   
7. In Time-out (seconds), specify the time (in seconds) that ISA Server should try to obtain a response from the RADIUS server before trying an alternate server.
   
8. Select Always use message authenticator to send a message authenticator based on the shared secret with each RADIUS message.
   

To enable the RADIUS system policy rule

To enable the system policy rules allowing ISA Server to contact RADIUS servers in the Internal network for authentication purposes, do the following:

1. In ISA Server Management, right-click the Firewall Policy node, and then click Edit System Policy.
   
2. In the Authentication Services section of the Configuration Groups list, click RADIUS.
   
3. On the General tab, ensure Enable is selected.
   

To monitor the RADIUS server

To monitor the RADIUS server, do the following:

1. In ISA Server Management, click the Monitoring node.
   
2. In the details pane, click the Connectivity tab.
   
3. In the task pane, on the Tasks tab, click Create New Connectivity Verifier.
   
4. On the Welcome page of the wizard, type a name for the connectivity verifier, and then click Next.
   
5. On the Connectivity Verification Details page, do the following:
   
6. In Monitor connectivity to this server or URL, type the name of the server to monitor.
   
7. In Verification method, select Send a Ping request.
   
8. Click Next, and then click Finish.
   
9. In the details pane, select the rule you just created.
   
10. On the Tasks tab, click Edit Selected Verifier.
    
11. On the Properties tab, verify that Trigger an alert if the server response is not within the specified timeout is selected.
    

Step 2: Configure General VPN Properties and VPN RADIUS Authentication

Complete the following steps to configure general VPN properties and specify that RADIUS authentication should be used for VPN connections. You must configure general VPN properties before setting up a VPN connection, and these properties apply to all such connections. Follow these steps:

1. Select access networks. Specify the ISA Server network that listens for incoming remote VPN client requests.
   
2. Assign addresses to VPN clients. Specify how VPN remote clients are allocated IP addresses. You can specify that addresses should be allocated from a Dynamic Host Configuration Protocol (DHCP) server, or from a static address pool.
   
3. Select the authentication protocol. Specify the authentication protocol that will be used to authenticate the VPN connection. This example uses the default MS-CHAP v2 protocol. For more information about authentication protocols, see Appendix B: Authentication Protocols Overview.
   
4. Enable RADIUS for VPN connections. Specify that RADIUS should be used to authenticate VPN connections, and enable RADIUS accounting for VPN connections.
   Important: You may be required to restart the ISA Server computer after you make VPN configuration changes. To check whether a restart is needed, in ISA Server Management, expand the ISA Server computer node, and click Monitoring. In the details pane, on the Alerts tab, look for an alert that reads ISA Server computer restart needed. The alert information for that alert will read Changes made to the VPN configuration require the computer to be restarted. If you see that alert, you are required to restart the ISA Server computer.

To select access networks

For VPN remote client connections, select the networks that are listening for VPN remote client requests. In this example, client requests originate from the External network. Follow these steps:

1. In the console tree of ISA Server Management, select Virtual Private Networks (VPN).
   
2. In the task pane, on the Tasks tab, click Select Access Networks.
   
3. On the Access Networks tab, select the networks from which clients can initiate VPN connections.
   

To assign addresses to VPN clients

Specify how VPN remote clients are allocated IP addresses. In this example, there is a DHCP server in the Internal network. Follow these steps:

1. In the console tree of ISA Server Management, select Virtual Private Networks (VPN).
   
2. In the task pane, on the Tasks tab, click Define Address Assignments.
   
3. On the Address Assignment tab, specify how IP addresses should be assigned to VPN clients (both for remote client-to-site connections, and site-to-site connections).
   
   1. To assign IP addresses to VPN clients from a static address pool, select Static address pool.
      
   2. To dynamically assign IP addresses to roaming VPN clients from DHCP, select Dynamic Host Configuration Protocol (DHCP).
      
   3. From the drop-down menu below Use the following network to obtain DHCP, DNS and WINS services, select the network in which these DHCP and DNS servers are located (Internal), and then click OK. You may be prompted to restart the computer.
      

To select the authentication protocol

Select the authentication protocol to be used for the VPN connection. This example uses the default MS-CHAP v2 setting. Follow these steps:

1. In the console tree of ISA Server Management, select Virtual Private Networks (VPN).
   
2. In the task pane, on the Tasks tab, click Select Authentication Methods.
   
3. On the Authentication tab, select the authentication protocol you want to use to authenticate the VPN connection.
   
4. Click OK to close the dialog box.
   

To enable RADIUS for VPN connections

To configure RADIUS for VPN configuration, do the following:

1. In the console tree of ISA Server Management, select Virtual Private Networks (VPN).
   
2. In the task pane, on the Tasks tab, click Specify RADIUS Configuration.
   
3. On the RADIUS tab, select Use RADIUS for authentication.
   
4. To use RADIUS accounting to log VPN connections in the RADIUS server logs, select Use RADIUS for accounting (logging).
   
5. To view or modify the RADIUS server configured in ISA Server Management, click RADIUS Servers.
   
6. Click OK to close the dialog box.
   

Step 3: Set Up a VPN Remote Client-to-Site Connection

Complete the following steps to set up a VPN remote client-to-site connection. The procedures in this section presume you have already completed configuration settings outlined in Step 1 and Step 2.

The scenario is displayed in the follow figure.

In this scenario, note the following:

• The RADIUS server used for authentication is located in the Internal network.
  
• The RADIUS server belongs to an Active Directory domain. The ISA Server computer does not.
  
• Point-to-Point Tunneling Protocol (PPTP) is the VPN connection protocol.
  
• VPN remote clients will be allowed access to the entire Internal network.
  

Perform the following steps to configure VPN remote client properties:

1. Enable VPN remote client access. Enable VPN remote clients to connect to the ISA Server computer, and specify the maximum number of simultaneous VPN remote client connections allowed.
   
2. Specify the remote client-to-site protocol. This example uses PPTP. For more information about VPN connection protocols, see Appendix C: Connection Protocols Overview.
   Note: There are two more tabs available on VPN Client properties. In the procedure examples used in this document, these are not set because ISA Server is not a domain member.
   • Groups tab. On the Groups tab you can configure ISA Server to allow VPN client access to domain groups. This setting is only relevant when ISA Server is a member of Active Directory in native mode or Windows Server 2003. If ISA Server is not a domain member, do not specify any setting on this tab.
     
   • User Mapping tab. The User Mapping tab enables you to map non-Windows users to domain user accounts. Instead, if you want to apply user-based access rules to non-Windows users, create a user set for them. If ISA Server does not belong to a domain, do not specify any settings on this tab.
     
3. Create a VPN remote client-to-site access rule. Create an access rule to allow the VPN Clients network to access the Internal network. Note the following when creating the access rule:
   
   • If you are using RADIUS authentication and ISA Server is not a domain member, you cannot apply user authentication parameters to the access rule. You cannot specify that the rule be limited to a specific Active Directory user or group. Instead, you can limit access for the VPN Clients network to specific protocols, and to specific servers on the Internal network.
     
   • If ISA Server is configured as a VPN server and acts as a firewall server for Firewall clients, VPN client computers with Firewall Client installed will use port 1745 of the ISA Server Internal network interface. If ISA Server is configured as a VPN server and acts as a proxy server for Web Proxy clients, VPN client computers using the ISA Server computer as a proxy will use port 8080 of the ISA Server Internal network interface. By default, when you define a rule allowing access from the VPN Clients network to the Internal network, access is allowed to all ports. However, if you choose to limit the ports, you must allow access to ports 1745 and 8080, respectively, for these scenarios.
     
   • ISA Server also allows you to quarantine VPN clients in the Quarantined VPN Clients network, until their compliance with corporate security requirements is verified, and they can then be moved to the VPN Clients network. For more details, see the document VPN Roaming Clients and Quarantine Control.
     
   • When you installed ISA Server, a default network rule was created to define a routing relationship between the Internal network and two VPN remote clients networks (VPN Clients and Quarantined VPN Clients). Another default network rule was created at the same time, allowing access from the VPN Clients network to the External network. Although these networks are not associated with a physical network adapter, ISA Server handles them as having a virtual network adapter, to which traffic in routed. You can create new network rules to allow traffic from the VPN Clients network to other networks.
     
4. View the VPN remote client network rules. View the existing network rules.
   
5. Configure the VPN remote client computer. Set up a VPN connection on the remote client computer.
   
6. Test the VPN remote client connection. Test the remote client connection to the VPN server.
   

To enable VPN remote client access

Enable VPN remote client access as follows:

1. In the console tree of ISA Server Management, click Virtual Private Networks (VPN).
   
2. In the details pane, verify that the VPN Clients tab is selected.
   
3. In the task pane, on the Tasks tab, click Configure VPN Client Access.
   
4. In the VPN Clients Properties dialog box, on the General tab, select the Enable VPN client access check box. Then, in Maximum number of VPN clients allowed, specify a limit for the maximum number of simultaneous VPN client connections. For this example, change the default of 5 concurrent connections to 10.
   Note: ISA Server 2004 Standard Edition can support up to 1,000 concurrent client connections.

To specify the remote client-to-site protocol

Specify the remote client-to-site protocol as follows:

1. In the console tree of ISA Server Management, click Virtual Private Networks (VPN).
   
2. In the details pane, make sure that the VPN Clients tab is selected.
   
3. In the task pane, on the Tasks tab, click Configure VPN Client Access.
   
4. On the Protocols tab, specify what protocol you want to use for VPN remote client connections. For this example, only the default PPTP connections will be configured. Verify that the Enable PPTP check box is selected.
   
5. Click OK to close the VPN Clients Properties dialog box.
   
6. In the ISA Server details pane, click Apply to apply the changes.
   

To create a VPN remote client-to-site access rule

To create an access rule that allows the VPN Clients network to access the Internal network for all protocols, do the following:

1. In the Microsoft ISA Server Management console tree, select Firewall Policy.
   
2. In the task pane, on the Tasks tab, select Create New Access Rule to start the New Access Rule Wizard.
   
3. On the Welcome page of the wizard, type a name for the access rule, and then click Next.
   
4. On the Rule Action page, select Allow, and then click Next.
   
5. On the Protocols page, specify which protocols VPN remote clients can use for access. To allow all protocols, in This rule applies to, select All outbound traffic. Then, click Next. 
   
6. On the Access Rule Sources page, click Add to open the Add Network Entities dialog box. Click to expand Networks, click VPN Clients, click Add, and then click Close. Click Next.
   
7. On the Access Rule Destinations page, click Add to open the Add Network Entities dialog box. Click to expand Networks, click Internal, click Add, and then click Close. Click Next.
   
8. On the User Sets page, leave the default All Users setting, and then click Next.
   
9. Review the information on the wizard summary page, and then click Finish.
   
10. In the ISA Server details pane, click Apply to apply the new access rule.
    

To view VPN remote client network rules

To view the default network rules for the VPN clients networks created when you installed ISA Server, do the following:

1. In ISA Server Management, click to expand the Configuration node, and then click Networks.
   
2. In the details pane, click the Network Rules tab.
   
3. To view the properties, double-click the VPN Clients to Internal Network rule.
   

To configure the VPN remote client computer

This procedure is performed on the VPN client computer. The procedure is based on a Windows XP client.

1. Select Start, point to All Programs, point to Accessories, point to Communications, and then click New Connection Wizard.
   
2. On the Welcome screen, click Next.
   
3. On the Network Connection Type page, select Connect to the network at my workplace, and then click Next.
   
4. On the Network Connection page, select Virtual Private Network connection, and then click Next.
   
5. On the Connection Name page, provide a name for the new connection, such as VPN Connection, and then click Next.
   
6. On the Public Network page, select whether you want Windows to automatically dial the initial connection to the network, and which connection to dial, and then click Next.
   
7. On the VPN Server Selection page, provide the external IP address of the ISA Server computer. This will be the address of the network adapter that connects the ISA Server computer to the Internet (also referred to as the External network). Click Next.
   
8. On the Connection Availability page, select My use only to ensure that VPN access will only be available when you are logged on to the computer. Click Next.
   
9. On the Completing the New Connection Wizard page, you may choose to have a connection shortcut created on your desktop, and then click Finish.
   

To test the VPN remote client connection

You can test the connection, using the following steps:

• On the VPN client computer, check the connection to the ISA Server computer.
  
• On the ISA Server computer, view the VPN client connection.
  

To check the connection to the ISA Server computer, do the following:

1. On the VPN client computer, dial into the network with the credentials required for the VPN client connection. Ping the IP address of the HTTP server.
   
2. Browse to a site on the HTTP server.
   

To check ISA Server for connection information, do the following:

1. In ISA Server Management, click the Monitoring node.
   
2. In the details pane, on the Sessions tab, verify that your VPN client session is listed.
   

There are several tips and hints to help securely and efficiently deploy RADIUS with ISA Server, including:

• Well defined shared secrets. A shared secret is a text string that serves as a password between a RADIUS client and a RADIUS server.
  
• When a password-based authentication method is used between a RADIUS client and server, the RADIUS server encrypts the passwords by using the shared secret, and sends it in the Access-Request packet. If you are using this type of authentication, we recommend that you use MS-CHAP v2, MS-CHAP, or CHAP with strong passwords to provide password protection from dictionary attacks. Use the following tips when creating and using a shared secret:
  
  • Be sure to change the default preshared key on the RADIUS server.
    
  • You must use the same case-sensitive shared secret on both the RADIUS server and the RADIUS client.
    
  • Use a different shared secret for each RADIUS server-RADIUS client pair.
    
  • To ensure a random shared secret, generate a random sequence at least 22 characters long.
    
  • You can use any standard alphanumeric and special characters.
    
  • You can use a shared secret of up to 128 characters in length. To protect your IAS server and your RADIUS clients from brute force attacks, use long shared secrets (more than 22 characters).
    
  • Make the shared secret a random sequence of letters, numbers, and punctuation and change it often to protect your IAS server and your RADIUS clients from dictionary attacks.
    
• Authentication mechanisms. In a VPN, you can use several authentication mechanisms with the RADIUS server. The order of authentication protocols, from the most secure to the least secure, is: PEAP-EAP-TLS (for wireless clients and authenticated switch clients only), EAP-TLS, PEAP-EAP-MS-CHAP v2 (for wireless clients and authenticated switch clients only), MS-CHAP v2, MS-CHAP, EAP-MD5, CHAP, and PAP. We recommend you use the strongest authentication protocols required for your configuration. For password-based authentication protocols, the use of strong passwords should be required.
  
• Message authenticator. Shared secrets are used to verify that RADIUS messages (except for the Access-Request message) are sent by a RADIUS-enabled device that is configured with the same shared secret. Shared secrets also verify that the RADIUS message has not been modified in transit (message integrity). By default, there is no cryptographic verification of the incoming Access-Request message. The RADIUS server verifies that the message originated from an IP address for a configured RADIUS client, but source IP addresses can be spoofed. The solution is to require the message authenticator attribute in all Access-Request messages. The message authenticator attribute is the Message Digest-5 (MD5) hash of the entire Access-Request message using the shared secret as the key. Note that if you select Always use message authenticator, make sure that your RADIUS server is capable of receiving, and is configured to receive, message authenticators.
  
• Internet Protocol security (IPsec). IPsec provides you with the ability to secure RADIUS servers against unwanted traffic by filtering specific network adapters (allowing or blocking specific protocols) and enabling you to choose source IP addresses from which traffic is allowed. For organizational units, you can create IPsec policies, which are stored in Active Directory. Or, you can create local policies on RADIUS servers, and apply these policies to specific computers. Use IPsec to provide additional security for RADIUS clients and servers. For more information, see Securing RADIUS traffic with IPsec.
  

Points to Note

Note the following:

• When user names are specified in any language other than English, ISA Server uses the current code page installed on the ISA Server computer to translate the user data. The user can be authenticated only if the client also uses the same code page.
  
• If you change the RADIUS server policy while RADIUS-authenticated users are logged on, the new policy is not applied to users who are currently logged on. This is because ISA Server caches the credentials of logged-on users when users accessing the published Microsoft Outlook® Web Access server authenticate using RADIUS authentication. To apply the RADIUS server policy immediately, you can disconnect the session.
  
• If you are using RADIUS for Web Proxy client authentication and VPN client authentication, you may want to split your remote access policies to prevent your VPN clients from using PAP. (Web Proxy clients support PAP only.)
  
• Every time a rule is encountered by a client, RADIUS reauthenticates the client. This potentially causes heavy RADIUS traffic on busy sites instead of regular domain authentications. There is an ISA Server COM setting available to reduce this traffic. SingleRADIUSServerAuthPerSession is a property of the FPCWebListener object that is valid for both network objects and Web listener objects. If you change the property from its default false value to true, user credentials sent to ISA Server and successfully validated by a RADIUS server are cached. For subsequent requests from the user, credentials sent to ISA Server are compared with credentials stored for that connection in the cache, rather than re-validating with the RADIUS server.
  
• ISA Server does not include much information in the Access-Request packet (for example, NAS IP, NAS Port, Username, and Password), so differentiation between ISA Server and other services may occur based on extra information included by those services, if they are run from the same computer. For example, Routing and Remote Access acting as a VPN server provides more information in the Access-Request packet than ISA Server. So if you need different VPN and Outlook Web Access authentication policies on the same ISA Server computer, you may need to resolve the differences between the two request types.
  
• When ISA Server 2004 performs RADIUS authentication, it does not take into account any RADIUS parameter in the RADIUS server’s response except Allow or Deny. ISA Server 2004 tries to match an access rule. If the rule requires credentials, it returns an HTML error page that causes the browser to prompt the user for credentials (or in the case of Outlook Web Access , causes the Outlook Web Access filter to display the authentication form. On received credentials it sends them to the RADIUS server. The RADIUS server returns an allow or deny response based on authorization process results. If ISA Server receives an allow response, and the rule applies to all users in the RADIUS namespace, it allows access. If the rule applies to a specific user name, and a string comparison (case-insensitive) between credentials in the rule and credentials sent by the user account match, it allows access.
  
• For VPN clients, EAP messages are always sent with a message authenticator
  
• For Web proxy clients, only PAP is supported.
  

You can specify that ISA Server should use several protocols for authenticating VPN connections to the RADIUS server. The most highly secure protocols supported are:

• Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2). MS-CHAP v2 provides mutual authentication, strong initial data encryption keys, and different encryption keys for sending and receiving. To minimize the risk of password compromise during MS-CHAP exchanges, MS-CHAP v2 drops support for the MS-CHAP password change and does not transmit the encoded password. MS-CHAP v2 uses a two-way challenge/response exchange of credentials, utilizing encryption of the password on the responses. The connecting client sends proof of the client password without actually sending the password, and the access server sends proof that it has access to the client password without actually sending the password.
  
• Extensible Authentication Protocol (EAP). EAP extends Point-to-Point Protocol (PPP) by allowing arbitrary authentication methods that use credential and information exchanges of arbitrary lengths. By using EAP, you can support additional authentication schemes, known as EAP types. These schemes include token cards, one-time passwords, public key authentication using smart cards, and certificates.
  

ISA Server also supports several less secure authentication protocols, including:

• Challenge Handshake Authentication Protocol (CHAP)
  
• Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
  
• Password Authentication Protocol (PAP)
  
• Shiva Password Authentication Protocol (SPAP)
  

These protocols can be useful for VPN clients running Windows NT® Server 4.0 or Windows 98 that do not have the latest VPN client software installed. Enable these authentication protocols only when required by your access clients.

ISA Server supports several VPN connection protocols, including:

• Point-to-Point Tunneling Protocol (PPTP). PPTP is a VPN tunneling protocol based on Point-to-Point Protocol (PPP) that enables IP traffic to be encrypted, and then encapsulated in an IP header to be sent across a corporate IP network or a public IP network such as the Internet. PPTP encapsulates PPP frames in IP datagrams for transmissions. PPTP can be used for a remote access client-to-site VPN, and for VPN site-to-site connections. PPTP uses a Transmission Control Protocol (TCP) connection for tunnel management, and a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames for tunneled data. Payloads of encapsulated PPP frames can be encrypted, compressed, or both. Frames are encrypted using Microsoft Point-to-Point Encryption (MPPE). MPPE uses the encryption keys generated from the specified authentication method. PPTP does not provide encryption services. It simply encapsulates a previously encrypted PPP frame.
  
• Layer Two Tunneling Protocol (L2TP). L2TP is a VPN tunneling protocol that, like PPTP, is also based on PPP. L2TP allows traffic to be encrypted, and then sent over any medium that supports point-to-point datagram delivery, such as IP, X.25, frame relay, or asynchronous transfer mode (ATM). When configured to use IP as its datagram transport, L2TP can be used as a tunneling protocol over the Internet. L2TP over IP networks uses User Datagram Protocol (UDP) and a series of L2TP messages for tunnel management. L2TP also uses UDP to send L2TP-encapsulated PPP frames as tunneled data.
  
• Internet Protocol security (IPsec). IPsec can be used in transport mode or in tunnel mode. In transport mode, application headers, TCP or UDP headers, and packet data are encrypted, but the IP header is not. IPsec can also be used as a tunnel mode, which encrypts the entire packet. IPsec protects data by encapsulating the original payload with either an IPsec header for transport mode, or an IPsec header and an additional IP header for tunnel mode. There are two IPsec protocols, Authentication Header (AH) and Encapsulating Security Payload (ESP), with some differences in the authentication, integrity, and confidentiality they provide. ESP is the only protocol that can be used with IPsec network address translation traversal (NAT-T). There are two modes:
  
  • IPsec tunnel mode. With Microsoft Windows installations, the IPsec protocol is commonly used for encryption in conjunction with L2TP. However, IPsec can be used as a tunneling protocol. IPsec in tunnel mode allows IP packets to be encrypted and then encapsulated in an IP header to be sent across a corporate network or a public network such as the Internet. It works only in IP-based networks. The primary reason for using IPsec tunnel mode is for interoperability with other routers or gateways that do not support L2TP over IPsec or PPTP tunneling.
    
  • L2TP over IPsec. Unlike PPTP, the Microsoft implementation of L2TP does not use MPPE for encryption. Instead, it uses a combination of L2TP as the tunneling protocol, and IPsec (ESP) in transport mode for encryption.