If you would like to read Using ISA Server 2004 RADIUS Authentication in Web Publishing Rules (Part 1), please click here.
Using RADIUS in this role of authenticating Web access is slightly unusual in comparison to the traditional use of RADIUS to authenticate dial-in and VPN access, but is potentially very useful. RADIUS authentication for Web access is provided by one of three Web authentication filters introduced with ISA Server 2004. These authentication filters (the other two are Forms Based and SecurID) enhance ISA Server’s ability to authenticate Web traffic before allowing it to pass to the published Web servers and may be used to provide a further layer of security.
RADIUS authentication might best be used whenever you consider using Basic authentication for Web access. RADIUS authentication in place of Basic authentication for Web access doesn’t necessarily enhance security, Forms Based and SecureID perform that role, but it is available when the clients are incapable of supporting these other methods.
RADIUS authentication can be used to authenticate incoming requests handled by Web publishing rules and also outgoing requests by Web Proxy clients. RADIUS offers a solution when Windows authentication of domain users isn’t possible because your ISA Server is not a domain member server. However its use is not restricted to non-member servers.
In Part 1 of this article we configured our RADIUS server to handle the type of requests our ISA Server will be sending it. In this instalment we will configure the ISA Server to use our RADIUS server, illustrate the configuration of a Web publishing rule that uses RADIUS authentication, and optionally configure the Web Proxy service to use RADIUS authentication. We will also explore ‘User sets’ that define users in the RADIUS ‘namespace’ to further fine-tune access.
Configuring Trusted RADIUS Servers
ISA Server 2004 must know where to send its RADIUS authentication requests to. A list of RADIUS servers is defined and ISA Server uses the first server in this list when sending requests; if that fails it tries the second, and so on. If you configured more than one RADIUS server you can list them all in order of priority to provide fault tolerance.
In ISA Server 2004 we list RADIUS servers in the ISA Server management console whereas previously we may have used the Routing and Remote Access Service (RRAS) console: RRAS is still there, but ISA Server2004 now handles most of its configuration. Also, when we define RADIUS Servers for ISA Server 2004 we define them for all ISA Servers Web publishing rules, VPNs and so forth; you can’t be selective about which RADIUS server is used for which purpose.
Open the ISA Server management console and navigate to Configuration, General in the left pane. Here you find the Define RADIUS Servers option; click it, and when the RADIUS Servers dialog box opens, click Add.
In the Add RADIUS Server dialog box enter your RADIUS server’s IP address, a suitable description and the shared secret you configured on your RADIUS server for this ISA Server (RADIUS client). The default UDP port of 1812 and timeout of 5 seconds can be left alone, but as our RADIUS server has been configured to expect the ‘message authenticator’, ensure Always use message authenticator is ticked. Then click OK.
Back in the RADIUS Servers dialog box we can see the server we just defined and add further servers, order them, and so forth as required. Typically you would configure at least two RADIUS servers and list them here, this would allow the ISA Server to attempt to use the second RADIUS server in the list should it fail to get a response from the first. Click OK to return to the management console and click Apply to make the changes.
By default the ISA Server 2004 System Policy enables the ISA Server to communicate with trusted RADIUS servers on the ‘Internal’ network. You may want to confirm this: Right-click Firewall Policy in the left pane of the ISA Server management console and select Edit System Policy. In the System Policy Editor that opens you will see RADIUS amongst the Configuration Groups listings: click this and ensure the Enable checkbox is checked.
The To tab defines the servers that the rule applies to. By default this is any server in the ‘Internal’ network, but you may narrow this down to individual servers if you prefer.
Configuring Web Publishing Rules for RADIUS Authentication
ISA Server 2004 authentication methods are applied to ‘Listeners’ and Web publishing rules are configured to use a particular listener. A Web publishing rule might share a listener with other rules, or may have one dedicated for its use.
Listeners are configured to ‘listen’ on a particular IP address or group of IP addresses, and either a non-SSL ports (normally TCP port 80) or an SSL port (443 by default) or both of these ports. No two listeners can share the same address and port combination.
For most authentication methods (such as Basic and Integrated) you may configure a listener with as many authentication methods as is needed, and the listener will negotiate a mutually acceptable one with the connecting client. However, this is not the case for the methods using a Web authentication filter such as RADIUS authentication: The listener can only be configured to use one of these authentication methods to the exclusion of all others. What this means is that if you want to use Forms Based and RADIUS authentication methods on ISA Server’s external interface, that interface is going to require two IP addresses for the two listeners required. There are clever tricks to help get around this, but that’s beyond the scope of this article.
With the above understanding drilled into our heads, we’ll start by creating a new Web publishing rule with a new listener configured for RADIUS authentication. After this, and for those that have already created rules and listeners, we’ll go on in the last part of this section to illustrate how existing rules and listeners can be configured for RADIUS authentication.
Creating a New Secure Web Server Publishing Rule
Begin by opening the ISA Server management console, right-clicking the Firewall Policy node and selecting New and Secure Web Server Publishing Rule. A secure publishing rule is essential here because we will be dealing with plain-text passwords across public networks.
The New SSL Web Publishing Rule Wizard will open where you can give this rule a name.
Click Next which will take you to the Publishing Mode page. As this isn’t an article on creating Web publishing rules we will skip quickly to the relevant section:
- Leave SSL Bridging selected on the Publishing Mode page and click Next.
- On the Select Action page leave Allow selected and click Next.
- On the Bridging Mode page leave Secure connection to client and Web server selected and click Next (you could use just Secure connection to clients if appropriate to your network).
- Define the internal Web server being published by entering its name and allowed path on the Define Web Site to Publish page and, unless you have very specific reasons not to, select the Forward the original host header option too.
- On the Public Details page select the option to accept requests for the domain name typed below and enter your Web site URL under Public Name. You now arrive at the Select Web Listener page.
At this point you have a choice: You can create a new Web listener which will then need editing (the New Web Listener Definition Wizard doesn’t let you configure authentication methods), or you can select an existing Web Listener from the pull-down list and edit it. We’ll run through creating a new listener; if you are editing an existing listener, skip the next steps and go on to the ones about editing the listener. Click New.
Creating a New Web Listener
The New Web Listener Definition Wizard opens. Give the Listener a name and click Next. On the following IP Addresses page select External and click Address.
If you have multiple IP addresses on your external interface you would normally select a single appropriate address for this listener. Click OK to return to the wizard, and then click Next.
In the Port Specification page you can unselect Enable HTTP because we are dedicating this listener to RADIUS authentication only and won’t be using it for non-SSL connections. Check Enable SSL and use the Select button to select a certificate that matches the public name of the site you are publishing. Click Next and then click Finish to complete this wizard.
If your listener is going to be used with more than one Web publishing rule you might use a wildcard certificate with the listener to cover more than one Web site. However, be careful with wildcard certificates as not all clients support them: A good example of such a client is Windows Mobile 2003 used on many PDAs and an excellent candidate to publish Exchange ActiveSync for together with RADIUS authentication.
Editing the Web Listener for RADIUS Authentication
With the new Web listener created using the New Web Listener Definition Wizard selected, or by having selected an existing one from the Web Listener pull-down list, click Edit.
In the listener properties sheets that open, select the Preferences tab and click Authentication. Note that if you are editing an existing listener and haven’t configured it for SSL, this is where you would do that. You would also use the Networks page to select on which network interface and IP address the listener operates on.
In the Authentication dialog box remove all the checks listed under Method (‘Integrated’ is selected by default) and then select only RADIUS. Ensure Require all users to authenticate is un-checked. Click Select Domain and type in your default domain name (the one used if the client doesn’t specify one). The default domain step can be skipped if your ISA Server is on a member server in your default (or only!) domain. Click OK and OK again to the property sheets to complete the listener configuration.
The Require all users to authenticate option could be checked to force this listener to authenticate all connections through it. Because this listener is to be dedicated to RADIUS authentication, this could actually be appropriate. However, in this case we will be enforcing authentication through configuration of the Web publishing rule using this listener, and this makes the option here un-necessary.
The RADIUS Servers button allows you to select RADIUS servers as we did earlier in this article. The process is identical to what we did earlier and any changes here apply to all listeners, VPN configurations, and so on. The appearance of this option on this dialog box seems to suggest that you can configure specific RADIUS servers for specific listeners, and that may have been the intention of the developers, but this is not the reality so don’t make that mistake! For some reason this option is also available when other methods are selected yet it has no impact on them. Why it is here at all is just one of those mysteries we occasionally see in Microsoft software!
Finishing the New Secure Web Server Publishing Rule Wizard
Having configured the listener and returned to the New SSL Web Publishing Rule Wizard, click Next to the Select Web Listener page to arrive on the next page titled User Sets. This page allows us to enforce authentication at the ISA Server for this Web publishing rule, but first remove the All Users entry which is basically saying ‘don’t bother authenticating any client connections’. Click Add.
In the Add Users dialog box select All Authenticated Users, click Add and then click Close.
‘All Authenticated Users’ means exactly that, any user who has been authenticated by any of the means configured at the listener. Later on we’ll look at making this a little less broad in scope.
You’ll have returned to the User Sets page, so click Next and then Finish. As always in ISA Server 2004 your new configuration isn’t available until you click the Apply button that has now appeared in the management console. However, there isn’t much point doing that just now because we are missing one more step that will require editing our newly created Web server publishing rule. Unfortunately wizards are not always that magical; read on!
Editing an Existing Web Server Publishing Rule and Listener
You’ve reached this step having created a new Web server publishing rule in the steps above, or you already had one created and skipped here wishing to configure it for RADIUS authentication: Either way, right-click your rule and select Properties from the menu.
When the property sheets open click on the Users tab. Ensure the Forward Basic authentication credentials (Basic delegation) is checked. Your Web site most likely demands authentication too and you’ll want your ISA Server to impersonate clients with the credentials passed to it. Without this option the clients will receive more than one logon request and most likely a 401 error when the combination of authentication requests from different sources breaks the whole process!
If you were finalising the creation of a new Web server publishing rule you’ll have completed the other options and it only remains to click OK and then click Apply back in the management console.
For those editing an existing rule there are a few more steps. The first is to ensure that All Authenticated Users, not All Users, appears under This rule applies to… by using the Remove and Add buttons in the same way as described for the wizard above. After that, click the Listener tab.
On the Listener page use the New button to create a new listener if required, and the Properties button to edit the new listener or any existing listener selected from the drop-down list. This process is the same as described for the new Web server publishing rule wizard above, so follow those steps entitled ‘Creating a New Web Listener’ and ‘Editing the Web Listener for RADIUS Authentication’. Finally click OK and then click Apply back in the management console.
Configuring User Sets for RADIUS Authenticated Users
Our Web server publishing rule should now allow access to any user authorised by the RADIUS remote access policy we configured in Part 1 of this article, and the policy used as an example was set to authorise any user in the ‘Domain Users’ group. That policy could be edited and configured with a more restrictive group to control access, and we could also have created a group of uses with no access and configured a deny policy with this group.
Remote access policies do provide a degree of control over who has and who hasn’t got access to your published Web site. But policies have one disadvantage is this regard; they apply to all your Web server publishing rules that employ RADIUS for authorisation. If you need site-by-site access control you need other mechanisms in place.
The Web site itself can provide a more restrictive access. Just because ISA Server has authenticated the user doesn’t mean that user can’t be rejected by the Web site! This is probably the mechanism most would choose, but it is still possible for ISA Server to filter users on a site-by-site basis before they get that far.
ISA Server 2004 introduced User Sets which are collections of users that can be granted or denied access. We have already mentioned two built-in user sets in this article; the All Users and All Authenticated Users sets allow us to allow access to anyone or only authenticated users. But we can also create custom user sets.
There is one difficulty with custom user sets and RADIUS authentication: RADIUS was designed to authenticate a user, it is designed to be platform independent, and it is therefore designed not to have any idea about Microsoft Windows security groups! You cannot create a user set that is based on a Windows security group for RADIUS authenticated users. But you can create a user set that lists individual RADIUS authenticated users; depending on what you are trying to achieve, using this feature could be a blessing or else an administrative nightmare!
Take a look by opening the ISA Server management console, selecting the Firewall Policy node, right-clicking your Web server publishing rule and selecting Properties from the menu. When the property sheets open click on the Users tab.
Note we have a choice in that we can configure who the rule applies to and who it doesn’t apply to (Exceptions). If the rule will apply to only a few users, configure a user set for that option. If you have a few users you want to exclude from access, use the Exceptions option. If you have hundreds of users you want to put in either option, then perhaps this isn’t the approach you need!
As an example we’ll create a user set of users to be denied access. Click the Add button along-side the Exceptions pane.
With the Add Users dialog box open select New to open the New User Set Wizard.
On the New User Set Wizard welcome page give the user set a name and click Next. This takes you to the Users page of the wizard. Click Add and select RADIUS from the option menu.
An Add User dialog box opens. The term ‘Namespace’ is used to describe how the user has been authenticated. There is a somewhat un-necessary option to include all users in this namespace. Specify a user name to be excluded from access and click OK.
Notice the user’s domain has been specified. User sets for RADIUS aren’t very clever and you have to enter the exact string that user will login with. This means you’ll also need an entry for the same user but specifying their UPN! Note that UPN login does work with RADIUS authentication despite the Help documentation stating otherwise. If you are still up for the task, repeat the add user process until you are satisfied with the user set’s population, then click Next followed by Finish to complete the wizard.
High-light your new user set in the Add Users dialog box, click Add then Close to return to the Web server publishing rule’s property pages.
It only remains to click OK and then apply the changes in the ISA Server management console.
Configuring the Web Proxy for RADIUS Authentication
RADIUS authentication can also be used with Web Proxy clients attempting to access Web servers (and FTP servers) on other networks such as the Internet. This feature could be useful if your ISA Server 2004 is configured as a Web Proxy but isn’t on a member server in the forest used by your Web Proxy clients. However, RADIUS authentication of Firewall Clients is not possible and support for Firewall Client will require the ISA Server to a domain member server. In this latter scenario RADIUS authentication of Web Proxy clients would be rather pointless when ‘Integrated’ authentication would provide a better solution.
There may be other scenarios where RADIUS authentication could be an option whether the ISA Server is a member server or not: For example you may have networks of non-Windows clients that, for whatever reason, you would prefer to authenticate via a RADIUS server.
If your setup would benefit from RADIUS authentication of Web Proxy clients, here is what to do:
Open the ISA Server management console and navigate to the Networks node in the left pane. In the right pane click on the Networks tab and right-click the network where your Web proxy clients exist. Select Properties from the menu.
On the properties pages click the Web Proxy tab. Here you will see a page that is remarkably similar to the listener property pages we came across earlier, but the Web Proxy listener is far more restricted on configuration options: You can’t directly dictate the IP address the Web Proxy listener listens on, and you can only configure one listener per network. Click Authentication.
Again, this dialog box is much like that for a Web listener but the Web Proxy listener has fewer authentication methods on offer. Select RADIUS and configure the default domain much like we did for a Web listener. OK out to finish. Use access rules in Firewall Policy to fine tune access.
Forms Based Authentication and RADIUS
Forms Based Authentication (FBA) is a secure cookie driven authentication method provided by another Web authentication filter. This method authenticates a user either with the target Web site or with the Active Directory depending on how you configure it; but it doesn’t allow authentication through RADIUS: This is unfortunate to say the least.
However, this omission isn’t permanent and a hotfix (KB884560) is available via PSS for the impatient. It requires a registry change that disables FBA’s use of Active Directory authentication and forces it to use a trusted RADIUS server such as configured earlier in this article. The next service pack will probably see incorporate this feature.
These two articles have extensively covered ISA Server’s RADIUS authentication method for Web access. It allows ISA Server to authenticate domain clients at the firewall, a very useful security feature, without the ISA Server actually belonging to a domain itself. Even ISA Servers that are domain members can use RADIUS and leverage the additional controls that RADIUS offers. RADIUS authentication for controlling Web access is one of a long list of powerful features that is placing ISA Server 2004 high in the league of firewall products!