Remote Authentication Dial-In User Service (thankfully RADIUS for short) is a standard protocol described in RFC2865. The protocol defines communications between a RADIUS client and a RADIUS server.
A RADIUS client is typically a dial-in server, VPN server or wireless access point that sends user credentials and other connection details to a RADIUS server. In our scenario the RADIUS client is the ISA Server attempting to authorise a user for access to a published Web site.
The RADIUS server authenticates the client request and sends back a response that will either be an approval or a rejection. The RADIUS server not only authenticates the credentials (checks name exists and password is correct) but also authorises the user according to a RADIUS authorisation policy. The RADIUS server in our scenario will be a Windows domain member-server running the Internet Authentication Service (IAS) which can authenticate the user against an Active Directory.
In this, Part 1, of the article we will deal with the RADIUS server: IAS is Microsoft’s implementation of a RADIUS server, and it will need to be configured not only to accept requests from our ISA Server, but also with an authorisation policy specific to this purpose. We will also explore user configuration in Active Directory and security concerns and work-rounds when using RADIUS.
In Part 2 we will configure Web publishing rules on ISA Server that will use RADIUS for user authorisation. It will also cover features in ISA Server 2004 that can ‘fine-tune’ authorisation down to a site-by-site level.
In the scenario we have here RADIUS is primarily intended to allowing non-domain ISA Servers to authenticate domain users, but there is at least one argument for using RADIUS even if the ISA Server belongs to a domain. This will be discussed later in the article.
Installing the Internet Authentication Service
You may already have IAS installed to handle VPN access, but if not our first step is to install the Internet Authentication Service on a Windows server that will act as our RADIUS server. Many administrators will use their domain controllers for this function, and will install IAS on more than one server to act as a backup. Once you have decided which server or servers will host IAS open Control Panel’s Add or Remove Programs applet on that server and click on the Add/Remove Windows Components icon.
With the Windows Components Wizard open, scroll down the list of components to find Network Services, hi-light this and click Options. Here you will find the IAS component, select it, click OK and click Next to install (you will probably be asked for the installation CD).
The installation will create a shortcut in Administrative Tools to an Internet Authentication Service console. Open this. The Help available here offers useful information on best practices and shouldn’t be missed, but for now our next task is to allow our new RADIUS server access to user dial-up properties in the Active Directory. Click on Action, then Register Server in Active Directory and finish by clicking OK to the dialog boxes that appear.
This process adds the server to the RAS and IAS Servers group in the domain. If you installed IAS on a domain controller, this step wasn’t strictly necessary, but does no harm. If you have multiple domains in a forest you should include your server in the RAS and IAS Servers group of each domain to which it will need access user details.
Configuring RADIUS Clients in IAS
IAS needs to know what RADIUS clients it is allowed to talk to. We need to include our ISA Server in this list, so start the process off by clicking on Radius Clients in the left pane of the Internet Authentication Service console and from the right-click menu in the right pane (or the Action menu) select New RADIUS Client.
The New RADIUS Client wizard will open. On the first page enter a friendly name (‘Firewall’ has been used in this example) and the ISA Server’s internal network IP address. Click Next to continue.
From the Client-Vendor pull-down list select Microsoft. The following options are to do with security so we’ll consider them in a little more depth. The Shared secret is a sort of password known to RADIUS client and server alike: It is used in an encryption process to obscure certain details in RADIUS messages such as user passwords. In addition to this we will select the Request must contain the Message Authenticator attribute option: This will require the client to calculate a ‘hash’ of its RADIUS message contents using the shared secret, and include it in that message. Our RADIUS/IAS server can compare this hash with one it produces of the same message to ensure the contents haven’t been tampered with and came from a known source.
This all sounds very secure, but any shared secret security should be considered as feeble. To avoid the secret being determined by brute force methods on captured packets it is currently recommended that the shared secret is at least 22 characters in length and complies with ‘strong’ password requirements (mixed case with numeric and symbol or punctuation characters): Even then the recommendations suggest it is changed frequently!
How concerned you should be depends on how much you trust those that have access to the network links between RADIUS client (your ISA Server) and RADIUS server (your server running IAS). Remember user passwords are at stake here, if security is a concern IPSec with ESP encryption should be deployed.
All this security only applies to messages between RADIUS client and RADIUS server. The communications across a public network between Web client and ISA Server (our RADIUS client) will, in this scenario, be secured using SSL (HTTPS).
That completes the configuration of the RADIUS clients in IAS. If you need to change any settings you’ve just made for this client, you can do so through its properties.
Configuring Remote Access Policies in IAS
A Remote Access Policy determines who is granted access and who isn’t. If you had already installed IAS you may well have created a policy for VPN access or other purpose and may be tempted to modify this for our purpose here. This probably isn’t a good idea: ISA’s RADIUS authentication for Web access uses some very low-key options that could lead to stricter conditions made for other purposes being bypassed and allowing passwords to be passed over public networks. The policy conditions we are about to configure are best kept isolated in their own policy.
The problem with isolating Remote Access Policies from one-another is that the rules are based on ‘will match this’ type conditions with no options for ‘will NOT match this’ criteria. Our policy to deal with ISA’s RADIUS authentication requests for Web access can’t be completely isolated from unintended use by configuring just the one policy; we will do what we can, but further action will be required.
Still in the IAS console click on Remote Access Policies in the left pane. Here you will see a couple of default deny rules (this example is from Windows 2003). Select from the right-click or Action menu the New Remote Access Policy option.
The New Remote Access Policy Wizard opens; click Next on the welcome page, select Set up a custom policy on the Policy Configuration Method page and give the policy a name before clicking Next.
On the Policy Conditions page click Add. Select Authentication-Type and click Add.
In the Authentication-Type dialog box select PAP and click Add before then clicking OK. ISA Server 2004 only uses PAP and unencrypted RADIUS messages in its RADIUS authentication method for Web access: This is most undesirable for any other form of RADIUS authentication (such as VPNs), hence why we are being so careful to try and isolate this policy. Apart from the small chance of configuring a VPN that could potentially use this policy with dire consequences, PAP is perfect for Web access authentication because the remote client will be using HTTP over SSL (HTTPS) to keep passwords safe and data encrypted over the public network.
Back on the Policy Conditions page click Add again, this time select NAS-IP-Address from the list of attribute types and click Add. In the dialog box enter the IP address for the ISA Server.
Finally repeat the step and select the Windows-Groups attribute type. The dialog box this opens requires a Windows security group (use the Add button). Here we’ve added the Domain Users group but you might use another more restrictive group.
Back on the Policy Conditions page you will have something looking like this:
The policy conditions we have just configured should ensure that only our ISA Server can send RADIUS authentication requests that fit this policy; any other RADIUS client you may configure will not match the IP address. However, as previously mentioned, if our ISA Server is also a VPN or dial-in server we must correctly configure it to avoid a VPN client using PAP and plain text passwords across the public network.
Click Next and select Grant remote access permission on the Permissions page before clicking Next.
The wizard’s Profile page appears next. The policy conditions configured above determined the criteria for matching a RADIUS authentication request with this policy. The profile determines the connection parameters this policy will enforce if the policy conditions match. Sometimes it could feel like it is repeating itself!
Hint: To view the attributes available for entering in policy conditions, enable logging of authentication requests in the System Event Log. You do this from the IAS property pages accessed by right-clicking Internet Authentication Service (Local) in the IAS console.
Click the Edit Profile button to open the Edit Dial-in Profile dialog box. In the next two steps we will ensure that any matching rogue RADIUS requests requiring encryption are rejected by this particular policy. Select the Authentication tab and remove all the default checks on this page and select only Unencrypted authentication (PAP, SPAP). Remember our policy conditions specified PAP only so any other checks here have no effect; but it does no harm to be tidy!
Select the Encryption tab. Remove all the default checks leaving only No Encryption. Click OK.
Click No to the offer of help which will pop up! You will be returned to the Profile page of the wizard. Click Next and click Finish on the final page of the wizard.
Should you require checking or editing of the policy you have just created, all the options you have just configured are available in the properties of the policy.
Further Isolation of the Policy
Provided you are careful when configuring your ISA Server for other RADIUS uses, such as VPN authorisation, the above configuration is probably enough to isolate our policy. However, if you are still unhappy that what you have done is not enough to prevent someone creating a VPN, or other access method, that would use this policy with its lack of security, you can go further:
Create a policy called, say, ‘Connections by legacy VPN clients’. In Policy Conditions include the attribute type of Authentication-type and have it match PAP again. Also include the attribute type of NAS-Port-Type and have it match Virtual (VPN), plus any other you may be worried about (ISA Server doesn’t set this attribute for Web access authentication so those requests will never match this policy). On the next wizard page select Deny remote access permission and finish off by clicking Next and Finish to subsequent pages (the profile is irrelevant in a deny policy). Of course you can add other conditions to further tighten the policy.
Ensure this deny policy is ordered above (smaller order number) the first policy we created by using the Action or right-click menu if necessary.
Configuring Domain Users for Remote Access
We should review those users who will be given access to Web sites that ISA Server controls by the RADIUS mechanism.
On a workstation or server where the suitable tools are installed, go to Administrative Tools and open the Active Directory Users and Computers console. Select a user and open their property sheets and select the Dial-in tab.
Under Remote Access Permission the Control access through Remote Access Policy option will generally be selected as this is the default. This selection is ideal for the scenario here, and for most other scenarios. You may possibly have users who you explicitly deny remote access to, but remember that in our scenario this setting will deny them access to Web sites on your Intranet too. A more administrator friendly approach might be to create security groups who have or have not got access, and use these groups in grant or deny Remote Access Policies.
Configuring Remote Access Lockout
Our final step in configuring our RADIUS server is an optional and precautionary one. It will involve editing the Registry of our RADIUS/IAS server and you should be aware of the damage that can be done by getting this step wrong. Always ensure you have good backups before messing with the Registry.
You are quite likely to have an Account Lockout Policy for your domain that locks out accounts after a number of failed logon attempts. There is a possibility that an unsavoury character with knowledge of a username can attempt to access a published Web site and enter incorrect passwords until the user is locked out. This could become a serious denial of service attack. If you haven’t got an Account Lockout Policy, you will be open to even more unsavoury characters attempting to gain access to your systems using dictionary attacks on passwords.
Fortunately there is a mechanism that will mitigate this kind of attack. It provides a second lockout counter and delay for Remote Access Policies that if configured correctly will prevent the domain lockout policy being triggered. It won’t help the attacked user if they are themselves remote at the time, but it will allow the user to carry on unaffected by the attack when in the office.
This mechanism could be an argument for using RADIUS authentication for Web access even if your ISA Server is a domain member!
The Registry settings can be changed using Regedit.exe, and the settings are located at:
There are two settings; MaxDenials and ResetTime (mins). MaxDenials is zero by default indicating it is disabled, but could be set to a value between 1 and 1 less than the Account Lockout Threshold in your domain’s Account Lockout Policy. For example, if your Account Lockout Threshold is set to 5, set MaxDenials to 3. ResetTime (mins) is an enormous 48 hours by default, but could be set to anything greater than Reset account lockout counter after in the domain’s Account Lockout Policy.
Unlocking an account for remote access before the reset time is a bit fiddly, requiring you to manually remove a registry key in the same location as above and named with the format DOMAIN:username. It is better to reach a balance between security and usability by setting a reset time that would avoid the need to perform this procedure.
If you would like us to email you when Paul Baldwin releases Using ISA Server 2004 RADIUS Authentication in Web Publishing Rules (Part 2) 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.