Configuring the ISA Firewall to Support Certificate-Based EAP-TLS Authentication (Part 1)

If you would like to read the next parts in this article series please go to:

• Configuring the ISA Firewall to Support Certificate-Based EAP-TLS Authentication (Part 2)
• Configuring the ISA Firewall to Support Certificate-Based EAP-TLS Authentication (Part 3)

Note:
While this article shows the configuration interface for ISA 2004, the same procedures apply to configuring ISA 2006 Firewalls for secure remote access VPN client connections using EAP/TLS authentication.

There are times when you might not want to join the ISA Firewall to the domain. While joining the ISA Firewall to the domain is an ISA Firewall security best practice, there are scenarios when you don’t need to join the ISA Firewall to the domain. For example, when you’re using a back to back ISA Firewall configuration, there’s little reason to join the front-end ISA Firewall to the domain. Instead, the front-end ISA Firewall is a standalone machine while the back-end ISA Firewall does the heavy security lifting and is joined to the user domain. This allows you to take advantage of all the ISA Firewall’s security, logging and reporting features. Another scenario when you might not want to join the ISA Firewall to the domain is when you use the ISA Firewall as a dedicated VPN server or VPN gateway in parallel with your outbound access control ISA Firewall.

ISA Firewalls that are not members of the user domain must use a mechanism other than Windows authentication to identify and authenticate domain users. The ISA Firewall can authenticate VPN users using the RADIUS (Remote Access Dial In User Service) protocol. The RADIUS protocol allows the ISA Firewall to forward user credentials of a RADIUS server on the Internal network. The RADIUS server then sends the authentication request to an authentication server, such as an Active Directory domain controller, for authentication.

In addition to authenticating users, the IAS server can be used to centralize Remote Access Policy throughout the organization. For example, if you have 6 ISA Firewall/VPN servers on your network, you can apply the same Remote Access Policy to all these machine by configuring it once at the IAS server.

The ISA Firewall supports all types of RADIUS servers. Microsoft’s RADIUS server is the Internet Authentication Services server (IAS). The Microsoft IAS server is included with all Windows 2000 and Windows Server 2003 server family products.

You can significantly improve the level of security applied to your VPN remote access solution by using EAP certificate-based user authentication. EAP (Extensible Authentication Protocol) allows you to extend the number of user authentication methods available to the VPN server. The Microsoft RADIUS (IAS) server also supports EAP. Examples of EAP user authentication methods you can use with the ISA Firewall/VPN server and RADIUS are user certificate authentication and smart card authentication. Smart card authentication requires additional hardware and software not included with the base Windows or ISA Firewall products.

You can use the built-in Microsoft Certificate Server included with both Windows 2000 and Windows Server 2003 family products to assign user certificates to users in your organization. Users can then configure their VPN client software to present the user certificate to authenticate to the VPN server. User certificate authentication is more secure because the user name and password are not transmitted over the Internet. In addition, the certificate must be installed on the user’s machine, so VPN connections requiring user certificate authentication cannot be made from untrusted machines that do not have the user certificate installed.

In this two-part article series we will discuss the procedures required to allow VPN clients to use RADIUS authentication to authenticate with the Internal network Active Directory domain. Then we will configure the ISA Firewall/VPN server to accept certificate authentication. Finally, we will issue a certificate to the VPN client and configure the VPN client to present the certificate for authentication.

Specific procedures discussed in this document include:

• Configure the IAS Server
• Create a VPN Clients Remote Access Policy
• Configure Remote Access Permissions and Domain Functional Level
• Enable the VPN Server on the ISA Server 2004 firewall and configure RADIUS Support
• Create a VPN Client Access Rule
• Issue Certificates to the ISA Server 2004 Firewall and VPN Clients
• Make the connection from a L2TP/IPSec VPN client
• Make the connection from a PPTP VPN client

Machines required:

• EXCHANGE2003BE – This is the domain controller and RADIUS Server
• ISALOCAL – This is the ISA Firewall/VPN server machine
• EXTERNALCLIENT – This is the external VPN client computer

Configure the Internet Authentication Services (RADIUS) Server

The first thing you need to do is install the IAS server. You can do this in the Add/Remove Programs applet in the Control Panel.

After you install the IAS Server, perform the following steps to configure the IAS server:

1. Click Start, point to Administrative Tools and click on Internet Authentication Services.
2. In the Internet Authentication Services console, right click on the Internet Authentication Service (Local) node in the left pane of the console. Click the Register Server in Active Directory command.

Figure 1

3. This setting allows the IAS Server to authenticate users in the Active Directory domain. Click OK in the Register Internet Authentication Server in Active Directory dialog box.
4. Click OK in the Server registered: dialog box. This dialog box informs you that the IAS Server was registered in a specific domain and if you want this IAS Server to read users’ dial-in properties from other domains, you’ll need to enter this server into the RAS/IAS Server Group in that domain.
5. Right click on the RADIUS Clients node in the left pane of the console and click the New RADIUS Client command.

Figure 2

6. In the New RADIUS Client dialog box, type in a Friendly name for the ISA Firewall/VPN server. You can use any name you like. In this example we’ll use the DNS host name of the ISA Server firewall/VPN server, which is ISALOCAL. Enter either the FQDN or the IP address of the ISA Firewall/VPN server in the Client address (IP or DNS) dialog box. Do not enter an FQDN if your ISA Server firewall/VPN server has not registered its internal interface IP address with your internal DNS server. You can use the Verify button to test whether the IAS Server can resolve the FQDN. Click Next.

Figure 3

7. On the Additional Information page, leave the RADIUS Standard entry in the Client-Vendor drop down list box. Your ISA Server firewall/VPN server will use this setting. Type in a complex shared secret in the Shared secret text both and confirm it in the Confirm shared secret text box. The shared secret should be a complex string consisting of upper and lower case letters, numbers and symbols. Put a checkmark in the Request must contain the Message Authenticator attribute checkbox. This option enhances the security of the RADIUS messages passed between the ISA Server firewall/VPN and IAS servers. Click Finish.

Figure 4

Create a VPN Clients Remote Access Policy

You are ready to create a Remote Access Policy on the IAS Server. Remote Access Policies configured on the IAS Server are enforced against VPN clients calling the ISA Firewall/VPN server. The Windows Server 2003 IAS server has a Remote Access Policy Wizard that makes it easy to create a secure VPN client Remote Access Policy.

Perform the following steps to create a VPN client Remote Access Policy on the IAS Server:

1. In the Internet Authentication Service console, right click on the Remote Access Policies node and click the New Remote Access Policy command.

Figure 5

2. Click Next on the Welcome to the New Remote Access Policy Wizard page.
3. On the Policy Configuration Method page, select the Use the wizard to set up a typical policy for a common scenario option. In the Policy name text box, type in a name for the policy. In this example, we’ll call it VPN Access Policy. Click Next.

Figure 6

4. Select the VPN option on the Access Method page. This policy is used for all VPN connections. You also have the option to create separate policies for PPTP and L2TP/IPSec VPN links. However, to create separate policies for PPTP and L2TP/IPSec connections, you need to go backwards in the Wizard and create two custom policies. In this example we’ll apply the same policy to all VPN connections. Click Next.

Figure 7

5. You can grant access to the VPN server based on user or group. The best access control method is on a per-group basis because it confers less administrative overhead. You can create a group such as VPN Users and allow them access, or all your users access. It depends on who you want to give VPN access to the network. In this example, we will select the Group option and click the Add button. This brings up the Select Groups dialog box. Enter the name of the group in the Enter the object name to select text box and click the Check names button to confirm that you entered the name correctly. In this example we will use the Domain Users group. Click OK in the Select Groups dialog box and then click Next in the User or Group Access dialog box.

Figure 8

6. You can select the user authentication methods to allow on the Authentication Methods page. You may wish to allow both Microsoft Encrypted Authentication version 2 and Extensible Authentication Protocol (EAP). Both EAP and MS-CHAP version 2 authentication are secure, so we’ll select both the Extensible Authentication Protocol (EAP) and Microsoft Encrypted Authentication version 2 (MS-CHAPv2) checkboxes. Click the down arrow in the Type (based on method of access and network configuration) drop down list box and select the Smart Card or other certificate option then click the Configure button. In the Smart Card or other Certificate Properties dialog box, select the certificate you want the server to use to identify itself to VPN clients. The self-signed certificate appears in the Certificate issued to drop down list box. This certificate is used to identify the server when the VPN clients are configured to confirm the server’s validity. Click OK in the Smart Card or other Certificate Properties dialog box and then click Next.

Figure 9

Figure 10

Note:
If you do not see the certificate in the Smart Card or other Certificate Properties dialog box, then restart the RADIUS server and start over. The certificate will then appear in the dialog box after the restart.

7. Select the level(s) of encryption you want to enforce on VPN connections. All Microsoft clients support the strongest level of encryption. If you have clients that don’t support 128 bit encryption, select lower levels, but realize that you lower the level of security provided by the encryption method used by the VPN protocol. In this example we’ll select only the Strongest encryption (IPSec Triple DES or MPPE 128-bit) Click Next.

Figure 11

8. Review your settings on the Completing the New Remote Access Policy Wizard page and click Finish.

Remote Access Permissions and Domain Functional Level

The new Remote Access Policy requires the connection be a “virtual” or VPN connection. The VPN protocol can be either PPTP or L2TP/IPSec. MS-CHAP v2 or EAP-TLS must be used to authenticate and the client must support the highest level of encryption available for the VPN protocol they use to connect. The user must belong to the Domain Users group in the domain specified in the Remote Access Policy.

The next step is to configure Remote Access Permissions. Remote Access Permissions are different than Remote Access Policies. When a user calls the ISA Server firewall/VPN server, the parameters of the connection are compared against Remote Access Policy or Policies defined on the IAS Server. Remote Access Policies are a hierarchical list The policy on top of the list is evaluated first, then the second listed policy is applied, then the third and so forth.

VPN connection parameters are compared to the conditions of the policy. In the policy we created above, there were two conditions: the connection type is a virtual connection and the user is a member of the Domain Users group. If the connection request matches both of those conditions, then the Remote Access Permission of the account logging in is determined. Remote access permissions are determined differently depending on the type of domain the user account belongs to.

Windows Server 2003 domains do not use the Mixed and Native Mode designations you might be familiar with in Windows 2000 domains. Windows Server 2003 supports domains of varying functional levels. If all the domain controllers in your domain run Windows Server 2003, the default functional level is Windows 2000 mixed. All user accounts are denied VPN (Dial up) access by default in Windows 2000 Mixed Mode functional level. In Windows 2000 Mixed Mode, you must configure each user account to have permission to log on to the VPN server. The reason is that user account permissions override Remote Access Policy permissions in Mixed Mode domains.

If you want to control Remote Access Permissions via Remote Access Policy, you must raise the domain functional level of Windows 2000 Native or Windows Server 2003. The default Remote Access Permission in Windows 2000 and Windows Server 2003 domains is Control access through Remote Access Policy. Once you are able to use Remote Access Policy to assign VPN access permission, you can take advantage of group membership to allow or deny access to the VPN server.

When a connection request matches the conditions in the Remote Access Policy and the user is granted access via either the user account Dial-in settings or Remote Access Policy, the connection parameters are compared a number of settings defined by the Remote Access Profile. If the incoming connection does not comply with the settings in the Remote Access Profile, then the next Remote Access Policy is applied to the connection. If no policy matches the incoming connection’s parameters, the connection request to the ISA Server firewall/VPN server is dropped.

The VPN Remote Access Policy you created earlier includes all the parameters required for a secure VPN connection. Your decision now centers on how you want to control Remote Access Permissions:

• Allow Remote Access on a per group basis: this requires that you run in Windows 2000 Native or Windows Server 2003 functional level.
• Allow Remote Access on a per user basis: supported by Windows 2000 Native, Windows 2000 Mixed and Windows Server 2003 functional levels.
• Allow Remote Access on both a per user and per group basis: this requires Windows 2000 Native or Windows Server 2003 functional level; granular user based access control overriding group based access control is done on a per user basis.
• Procedures required to allow per user and per group access include:
• Change the Dial-in permissions on the user account in the Active Directory to control Remote Access Permission on a per user basis
• Change the domain functional level to support Dial-in permissions based on Remote Access Policy
• Change the Permissions settings on the Remote Access Policy

Changing the User Account Dial-in Permissions

You can enable dial-in permissions on a per account basis, or create Remote Access Policies that can be configured to enable dial-in permissions to entire groups.

Perform the following steps if you want to control access on a per user basis:

1. Click Start, point to Administrative Tools and click on Active Directory Users and Computers.
2. In the Active Directory Users and Computers console, expand your domain name and click on the User node.
3. Double click on the Administrator account in the right pane of the console. In the user account Properties dialog box, click on the Dial-in tab. The default setting on the account is Deny access. You can allow VPN access for the account by selecting the Allow access option. Per user account setting override permissions set on the Remote Access Policy. Notice the Control access through Remote Access Policy option is disabled. This option is available only when the domain is at the Windows 2000 or Windows Server 2003 functional level. Make no changes to the account setting at this time.

Figure 12

4. Click Cancel to escape this dialog box.

Changing the Domain Functional Level

If you want to control access on a per group basis, then you will need to change the default domain functional level. Perform the following steps to change the domain functional level:

1. On a domain controller in your domain, open the Active Directory Domains and Trusts console. Click Start, point to Administrative Tools and click on Active Directory Domains and Trusts.
2. In the Active Directory Domains and Trusts console, right click on your domain and click on the Raise Domain Functional Level command.

Figure 13

3. In the Raise Domain Functional Level dialog box, click the down arrow in the Select an available domain functional level drop down list, select either Windows 2000 native or Windows Server 2003, depending on the type of domain functional level your network can support. In this example we will select the Windows Server 2003 option. Click the Raise button after making your selection.

Figure 14

4. Click OK in the Raise Domain Functional Level dialog box. This dialog box explains the change affects the entire domain and after the change is made, it cannot be reversed.
5. Click OK in the Raise Domain Functional Level dialog box informing you that the functional level was raised successfully. Note that you do not need to restart the computer for the changes to take effect. However, the default Remote Access Permission will not change for user accounts until Active Directory replication and completed. In this example, we will restart the computer. Restart the computer now and log in as Administrator.
6. Return to the Active Directory Users and Computers console and double click on a user account. Click on the Dial-in tab in the user’s Properties dialog box. Notice how the Control access through Remote Access Policy option is enabled and selected by default.

Figure 15

Controlling Remote Access Permission via Remote Access Policy

Now that you have the option to control access via Remote Access Policy, let’s see how VPN access control via Remote Access Policy is performed:

1. Click Start, point to Administrative Tools and click on Internet Authentication Service.
2. Click on the Remote Access Policies node in the left pane of the console. You will see the VPN Access Policy you created and two other, built-in Remote Access Policies. You can delete these other Remote Access Policies if you require only VPN connections to your ISA Server firewall/VPN server. Right click on the Connections to other access servers Remote Access Policy and click Delete. Repeat with the Connections to Microsoft Routing and Remote Access server Remote Access Policy.

Figure 16

3. Double click on the VPN Access Policy in the right pane of the console. In the VPN Access Policy Properties dialog box there are two options that control access permissions based on Remote Access Policy: 

   – Deny remote access permission 
   – Grant remote access permission

   Notice that this dialog box does inform you that the user account settings override the Remote Access Permission settings: Unless individual access permissions are specified in the user profile, this policy controls access to the network. Select the Grant remote access permission to allow members of the Domain Users group access to the VPN server.
   
   
   
   
   

Figure 17

4. Click Apply and then click OK in the VPN Access Policy Properties dialog box to save the changes

Summary

In this article we began our discussion about how to configure the ISA Firewall to support secure EAP/TLS authentication for remote access VPN client connections. We began by configuring the RADIUS server and finished up by setting up Remote Access Policies and changing the domain functional level. In the next article we’ll look at how to configure the ISA Firewall’s VPN server to support our EAP/TLS VPN client connections. See you then! –Tom.