Using RADIUS Authentication with the ISA Firewall’s VPN Server (2004)
Using RADIUS Authentication with the ISA Firewall’s VPN Server (2004)
By Thomas W Shinder M.D.
Got questions? Discuss this article over at
Like the ISA Server 2000 firewall, the ISA firewall (ISA Server 2004) supports RADIUS authentication for VPN clients. RADIUS authentication is most useful when the ISA firewall is not a member of the Internal network domain.
Situations where you would not want to make the ISA firewall a member of the Internal network domain would include those where the ISA firewall is the Internet edge firewall and there are other back-end firewalls on the network. While it is completely acceptable to make the ISA firewall on the Internet edge a domain member in a single ISA firewall network, the preferred configuration in a multiple firewall setup is to make the back-end ISA firewall a domain member and let any front-end ISA firewalls remain standalone devices.
There are also circumstances where the corporate security officer, who does not understand firewalls in general, (and the ISA firewall in particular) requires that the ISA firewall, regardless of its location, not be a member of the domain. In this case, you can still authenticate VPN users against your internal network Active Directory domain database by using RADIUS authentication.
When the non-domain member ISA firewall uses RADIUS to authenticate VPN users, the ISA firewall forwards user credentials to a RADIUS server on the back-end. The Microsoft implementation of RADIUS is called the Internet Authentication Server (IAS). The RADIUS server forwards the user credentials to an authentication server. In an Active Directory environment, the authentication server is an Active Directory domain controller. The authentication server sends its response to the RADIUS Server and the RADIUS server sends the response to the ISA firewall. If the credentials are valid and the user has dial-in permissions, the VPN connection is allowed. If the credentials are not valid or if the user does not have dial-in permissions, then the connection is dropped.
The ISA firewall is a RADIUS client when it is configured to use RADIUS authentication. The ISA firewall must be configured to use one or more RADIUS servers and the RADIUS servers must be configured to communicate with the ISA firewall as a RADIUS client. So, both the ISA firewall and the RADIUS server must be configured to "know" each other in order for RADIUS authentication to work correctly.
In this article we will use the simple lab setup as seen in the figure below:
Notice the domain controller a RADIUS server. You could place the RADIUS server another machine in the same domain. You could also configure RADIUS proxies, but we’ll talk about those and how to use them in another article. The domain controller in this scenario is also a DHCP server, DNS server, WINS server and Certificate server. We will take advantage of each of this services except for the Certificate Server.
Will we discuss in detail the following procedures:
- Configuring the RADIUS Server
- Configuring the User Account for Dial-in Permission
- Enabling and Configuring the ISA Firewall’s VPN Server
- Configuring Firewall Policy to Control VPN Client Access
- Making the VPN Remote Access Client Connection
Installing the RADIUS server is a basic procedure so we won’t discuss the step by step procedures for installing the Microsoft IAS Server.
Configure the RADIUS Server
You can start setting up the RADIUS Server right after installing it. There’s no need to restart the server. There are two things we need to do at this point: configure the RADIUS server to recognize the ISA firewall as a RADIUS client and then create a Remote Access Policy for the VPN clients.
Perform the following steps to configure the RADIUS server to use the ISA firewall as a RADIUS client:
- At the IAS Server machine, click Start and point to Administrative Tools. Click Internet Authentication Service.
- In the Internet Authentication Service console, right click the RADIUS Clients node in the left pane of the console and click New RADIUS Client.
- On the Name and Address page, enter a Friendly name for the ISA firewall. In this example the friendly name will be ISA Firewall. Enter the IP address on the internal interface of the ISA firewall in the Client address (IP or DNS) text box. Click Next.
- On the Additional Information page, confirm that the Client-Vendor option is set to RADIUS Standard. Enter a password in the Shared secret text box and confirm the password in the Confirm shared secret text box. Make the password complex, with more than 8 characters and a mix of upper and lower case letters, numbers and symbols. Put a checkmark in the Request must contain the Message Authenticator attribute checkbox. Click Finish.
The next step is to create a Remote Access Policy that is applied to the VPN clients. We will use a default VPN clients Remote Access Policy in this example.
Perform the following steps to create the VPN clients Remote Access Policy:
- In the Internet Authentication Service console, right click on the Remote Access Policies node in the left pane of the console and click New Remote Access Policy.
- Click Next on the Welcome to the New Remote Access Policy Wizard page.
- On the Policy Configuration Method page, select the Use the wizard to set up a typical policy for a common scenario option. Enter a name for the Remote Access Policy in the Policy name text box. In this example we will name the policy VPN Clients. Click Next.
- On the Access Method page, select the VPN option and click Next.
- On the User or Group Access page, select the Group option. Click the Add button.
- In the Select Groups dialog box, enter Domain Users in the Enter the object names to select text box. You can create your own custom domain Global Groups if you want to limit access to the ISA firewall’s VPN server. Click the Check Names button to confirm that you have entered the group name correctly. Click OK in the Select Groups dialog box.
- Click Next on the User or Group Access page.
- Leave the checkmark in the Microsoft Encrypted Authentication version 2 (MS-CHAPv2) checkbox. You might want to use EAP to provide stronger authentication, by selecting the Extensible Authentication Protocol (EAP) checkbox. We will not go over the details of using EAP authentication with the ISA firewall’s VPN server. There are detailed instructions on how to do this in the ISA 2004 VPN Deployment Kit. Click Next.
- On the Policy Encryption Level page, enable the checkboxes that are appropriate for your VPN clients. Since we use exclusively Windows XP and Windows 2000 clients (for security reasons), we will remove the checkmarks from the Basic encryption and Strong encryption checkboxes. Click Next.
- Click Finish on the Completing the New Remote Access Policy Wizard page.
Configure the User Account for Dial-in Permission
The next step is to enable the user account’s dial-in permission. If your Active Directory domain is in native mode or Windows Server 2003 mode, then you do not need to perform this step because the default dial-in permission setting for user accounts is to control dial-in access via Remote Access Policy.
In a mixed mode domain, each user account must be individually configured to allow dial-in permission. In this example we will configure the Administrator account so that it has dial-in permissions.
Perform the following steps to allow dial-in permissions fro the Administrator account:
- Open the Active Directory Users and Computers console.
- Expand the domain name in the left pane of the console and click the Users node.
- Double click the user name in the right pane of the console.
- Click on the Dial-in tab. Select the Allow access option.
- Click Apply and then click OK.
Enable and Configure the ISA Firewall’s VPN Server
Now we’re ready to enable and configure the ISA firewall’s VPN server component. The VPN server will be configured to allow remote access VPN client connections. A separate procedure is required to allow site to site VPN connections and we’ll examine the procedures required to accomplish that task in a future article on this site.
Perform the following steps at the ISA firewall to enable and configure the ISA firewall’s VPN Server:
- Open the Microsoft Internet Security and Acceleration Server 2004 management console and expand the computer name. Click the Virtual Private Networks (VPN) node.
- On the Virtual Private Networks (VPN) node, click the Tasks tab in the Task Pane. Click the Configure VPN Client Access link.
- In the VPN Clients Properties dialog box, put a checkmark in the Enable VPN client access checkbox. Enter a value in the Maximum number of VPN clients allowed text box. The Standard Edition of the ISA firewall can support up to 1000 concurrent VPN client connections.
- Click the Groups tab. This tab only applies to those organizations that run in Active Directory native mode or Windows Server 2003 mode. This is an interesting and confusing dialog box because it implies that if you don’t enter any groups here, then no groups will be allowed access! In addition, the ISA firewall needs to be a member of the Active Directory domain to have access to domain groups. Since we do not want to make the ISA firewall a member of the domain in this scenario, we do not need to add any groups on the Groups tab.
- Click on the Protocols tab. The default setting is to enable PPTP. If you want to support L2TP/IPSec VPN connections, put a checkmark in that checkbox. I always put a checkmark in that checkbox, even if I’m not ready to use L2TP/IPSec. However, if you have no plans to implement a PKI and distribute certificates, then do not put a checkmark in this checkbox. In this example we will enable only the PPTP option to keep things simple.
- Click the User Mapping tab. This is another one of those "what the heck does this thing do" tabs and its one that will get you into trouble if you don’t understand its functionality. The first and most important thing to know is: do not enable User Mapping if the ISA firewall is not a member of the domain. The ISA firewall must have access to the Active Directory database to map users who do not supply domain information (such as RADIUS clients) to the ISA firewall itself (the information is supplied to the RADIUS server, it is not given to the ISA firewall).
This actually sort of makes sense when you read the text on the User Mapping page. It says User mapping is used to map VPN clients from non-Windows namespaces (RADIUS or EAP authenticated users) to the Windows namespace. As a result, Access Rules applied to the Windows user sets are also applied to user from non-Windows namespaces. Since the ISA firewall in this scenario isn’t part of a Windows domain, there is no Windows domain namespace accessible to the firewall. The confusion primarily lies in the term Windows Authentication. What the heck is Windows Authentication? From what I can tell, it’s any type of authentication that isn’t RADIUS or EAP authentication ;-).
Even more problematic then trying to figure out what this dialog box means and does is the fact that if you enable user mapping on an ISA firewall that is not a domain member, and then configure the VPN server to use RADIUS authentication, no one can connect to the ISA firewall. You will see an error dialog box like the one below. If you do a Network Monitor trace, you’ll see that the VPN client sends a disconnect message to the ISA firewall.
However, as firewall administrators we need to get to the bottom line: do not use user mapping unless the ISA firewall is a member of an Active Directory domain. You will not be able to use the ISA firewall’s strong user/group based access control for VPN clients if the ISA firewall is not a member of the domain. Hopefully we’ll get some guidance on exactly how this feature works some time in the future and we’ll be able to use the ISA firewalls strong user/group based access controls.
I’ll be glad to recant the above statement and revise this article when Microsoft provides information on exactly what this feature does and how it works. Until then, DO NOT enable User Mapping if the ISA firewall is not a member of an Active Directory domain.
Now we configure the RADIUS server the ISA firewall will use:
- Click on the Specify RADIUS Configuration on the Tasks tab of the Task Pane.
- On the RADIUS tab, put a checkmark in the User RADIUS for authentication checkbox. Put a checkmark in the User RADIUS for accounting (logging) checkbox.
- Click the RADIUS Servers button.
- In the RADIUS Servers dialog box, click the Add button.
- In the Add RADIUS Server dialog box, enter the IP address of the RADIUS server in the Server name text box. You could enter a name in the text box, but the ISA firewall would need to be able to resolve the name correctly. Since the IP address of a RADIUS server is unlikely to change over time, you’re fairly safe using an IP address.
- Click the Change button. Enter the same password you entered on the RADIUS server when you configured the RADIUS server to use the ISA firewall as a RADIUS client. Put a checkmark in the Always use message authenticator checkbox. Click OK.
- Click OK in the RADIUS Servers dialog box.
- Click Apply and then OK on the Virtual Private Networks (VPN) Properties dialog box.
- Click Apply to save the changes and update the firewall policy.
- Click OK in the Apply New Configuration dialog box.
Configure VPN Access Policy
You need to create an Access Rule allowing the VPN clients network access to the Internal network. Because we’re using RADIUS authentication on an ISA firewall that is not a member of the domain, we cannot apply strong user/group based access control over the VPN client connections. If you require this, then make the ISA firewall a member of the Active Directory domain. I strongly recommend that you do make the ISA firewall a member of the domain when appropriate, as discussed at the beginning of this article.
However, you can still control access to protocols and servers. The only limitation is that you will not be able to allow selective access to VPN clients based on user credentials.
For example, you might want to allow members of the OWA Users group access to the OWA Web site when connected to the VPN server. You won’t be able to do this because all users will be able to connect to the OWA server. The good news is that you can still allow access to a single protocol and server, which is still far better than most VPN servers on the market today.
In the following example we will create an Access Rule allowing VPN users access to the OWA site using SSL only. If the VPN users try to access the OWA server using any other protocol, the connection will be denied. If they try to access any other server on the network, the connection will be denied. Of course, if you want VPN users to access other protocols or servers, you create additional rules that will allow access. The only limitation when using RADIUS authentication is that you will not be able to control access on a user/group basis.
Perform the following steps to create the Access Rule:
- In the Microsoft Internet Security and Acceleration Server 2004 management console, click the Firewall Policy node and then click the Tasks tab in the Task Pane. Click the Create New Access Rule link.
- On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example we will name the rule VPN Clients to Internal. (the name of the rule doesn’t exactly match the purpose of this Access Rule, but I changed my mind about what this would do when writing this article). Click Next
- Select Allow on the Rule Action page.
- On the Protocols page, select the Selected protocols option in the This rule applies to list. Click Add.
- In the Add Protocols dialog box, click the Common Protocols folder and double click HTTPS. Click Close.
- Click Next on the Protocols page.
- On the Access Rule Sources page, click Add.
- In the Add Network Entities dialog box, click the Networks folder and double click VPN Clients. Click Close.
- Click Next on the Access Rule Sources page.
- On the Access Rule Destinations page, click Add.
- In the Add Network Entities dialog box, click the New menu. Click Computer.
- In the New Computer Rule Element dialog box, enter a name for the Computer in the Name text box. In this example we will name the computer OWA Site. Enter the IP address of the OWA site in the Computer IP Address text box. Click OK.
- In the Add Network Entities dialog box, click the Computers folder. Double click the OWA Site entry and click Close.
- Click Next.
- On the User Sets page, click Next.
- Click Finish on the Completing the New Access Rule Wizard page.
- Click Apply to save the changes and update the firewall policy.
- Click OK in the Apply New Configuration dialog box.
Make the VPN Remote Access Client Connection
Create the VPN connectoid on the VPN client computer and log on to the ISA firewall’s VPN server. After creating the connection you’ll find that you can access the OWA site using HTTPS only.
The log file has some interesting information in it. You can see the user name on the fourth line from the top, as the VPN connection is established. You can also see another line where a user name is included in the request in the 14th line from the top, where a DNS query is issued. This seems to indicate the ISA firewall has access to user information when requests are made for various protocols and servers. However, when using RADIUS authentication, you cannot use this information to create user or group based access controls. Even when you use RADIUS users in a Firewall Group. Very strange!
the VPN client address assigned by the ISA firewall is 10.0.0.101.
If we look further down in the log we can see the connection request to the OWA site. In the 6th line from the top you can see the HTTPS request which is allowed by our VPN Clients to Internal rule. What happened to the user name?
I tried an FTP connection from the VPN client to the FTP server on the Internal network. Since there is no rule allowing FTP connections, I expected it to be denied, and it was. You can see in the 3rd, 4th and 5th lines from the top that the VPN client initiated an FTP connection to the FTP server at 10.0.0.2. Hey, we even have a user name here! There’s got to be a way to use this user name information to control access from RADIUS clients even when the ISA firewall is not a member of the domain. We just haven’t discovered it yet.
So, given the findings above, I’m hopeful that someone from Microsoft will beat me with a cluestick that provides the key piece of information required to allow strong user/group based access control over VPN client connections when the ISA firewall is not a member of the domain and clients use RADIUS authentication to connect.
- What happens to VPN client connections when the non-domain ISA firewall uses RADIUS authentication?
- True or False: The RADIUS server must be on a domain controller
- True or False: When the ISA firewall is on the Internet edge of the network, it should never be made a member of the domain.
- Under what circumstances do you not need to configure Dial-in permission on a per-user basis?
- In this article, is the ISA firewall a RADIUS client, RADIUS server or RADIUS proxy?
Check out the forum discussion link at http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=30;t=000170 for the answers to these questions.
In this article we examined the procedures required to connect to an ISA firewall’s VPN server using RADIUS authentication. We configured the IAS RADIUS server to use the ISA firewall as a RADIUS client and we configured the ISA firewall to use the RADIUS server as its RADIUS server. We then enabled the ISA firewall’s VPN server and configured the VPN server components. We finished up by making the VPN connection to the ISA firewall and examined log entries that indicate that the ISA firewall does have user information in some circumstances.
This article will be updated if information becomes available providing guidance on how to allow a non-domain member ISA firewall to use RADIUS authentication to provide strong user/group based access control for VPN client connections.
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=30;t=000170 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom
If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our 'Real-Time Article Update' by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy.