With ISA Server 2006 we have a whole new range of supported authentication and delegation methods. They are very well explained in the excellent planning and architecture document Authentication in ISA Server 2006. Because I’m particular interested in two-factor authentication using forms-based authentication for any published Web server, I’ve played quite a bit in my lab with the concept of one-time password support for Remote Authentication Dial-In User Service (Radius OTP).

One of my primary objectives is to find out what the limitations are when we would require the use of two-factor authentication such as Safeword, Vasco or other hardware tokens. By using two-factor authentication we are hoping to avoid that users have to enter domain credentials on non-trusted, read unmanaged, computers. Another objective is that by no means should there be a special software agent required on the clients or the servers to make it work. Otherwise that would defeat the anywhere access goal. In other words, only the ISA server should be aware of the use of the Radius OTP service. This implies that the Radius OTP service doesn’t need to be capable to authenticate the users against the internal domain but instead that the ISA server should use Kerberos constrained delegation to authenticate the users against the published service.

Note: most Radius OTP services have a component that integrates with Active Directory. However, that doesn’t mean the users are authenticated against the internal domain. That integration is very often done to avoid the complexity of synchronizing the Radius OTP and the Active Directory users. In other words, the Active Directory user names are used and the OTP parameters are just extra attributes of those users.

To be able to test it out in a generic way, that means independent of any real hardware token system, I’ve setted up the following scenario in my lab:

On the LAN there is a Windows 2003 SP1 server running Active Directory, Certificate services, DNS/DHCP/IAS, Exchange 2003 and IIS. The installed IAS service (Radius) is domain integrated, that means that the user database used is Active Directory, and is used for the custom remote access policy for the VPN users.  Of course the ISA server is domain integrated.

On the Perimeter there is a stand-alone Windows 2003 SP1 running IIS and a public DNS server. On this server I added the IAS service to be used as the Radius OTP service. This IAS service is completely independent of the internal domain and uses therefore the local SAM as the user database. I’ve created a couple of local users with exact the same user name as in the internal domain. However, take note that the password used should be different to facilitate the testing.

For a general discussion how to setup and configure an IAS service, check out Tom’s two part article Using ISA Server 2004 RADIUS Authentication in Web Publishing Rules.  

The first problem I have to solve has to do with the fact that the Radius servers defined on ISA are global for the whole box and are therefore not configured per web listener. Because I have to support VPN access with a domain integrated IAS as well as a Web publishing rule with a stand-alone IAS, there should be a way to forward the Radius requests to the proper IAS service. Therefore I installed an IAS Proxy service on ISA itself and configured two Connection Requests Policies to route the incoming Radius requests on the basis of some Radius attributes in those requests.

The challenge here is to find the Radius attributes which are a distinctive characteristic of the VPN and Web Publishing Radius requests. After monitoring the Radius requests for a while, it turns out that only the Radius attributes NAS-Port-Type and Authentication-Type are really useful. For VPN Radius requests the NAS-Port-Type is set to Virtual (VPN) and the Authentication-Type is usual MS-CHAP v2 or EAP. For Web Publishing requests the NAS-Port-Type is *not* set at all (why didn’t the designers set it for example to Web instead of leave it empty?) and the Authentication-Type is set to PAP. Moreover, only the Radius attribute NAS-Port-Type can be used in a Connection Request Policy, not the Radius attribute Authentication-Type. To workaround the lack of consistency in the Radius atribute NAS-Port-Type I implemented the following policies:

• On the domain integrated IAS I configured two Remote Access Policies to ensure that only VPN Radius requests are allowed:

  

• On the stand-alone IAS I configured two Remote Access Policies to ensure that only Web Publishing Radius requests are allowed:

  

• On the IAS Proxy I configured two Connection Request Policies to properly route the Radius requests:

  

The second problem I have to solve is related to the fact that the IAS Proxy service is installed on the ISA Server itself. I made that choice due the limited number of servers I can run in my ISA lab (VPC 2004 SP1). It turns out that it is best to configure all IP addresses assigned to all ISA interfaces as Radius Clients of the local IAS Proxy service, otherwise you will get the following Event log:

The third problem I have to solve has to do with the way the users are providing their user name.  Within the user name there are two elements: the identification of the user account name and the identification of the user account location, also known as the realm.  The realm name can be specified in two ways, either as a prefix (e.g. microsoft\) or as a suffix (e.g. @microsoft.com). By default, the IAS service uses as realm the domain name of which the IAS server is member of, or in case of a workgroup environment, the host name of the computer where IAS is installed on. You can change this default behavior by specifying the IAS-supplied domain name through the following registry setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\PPP\ControlProtocols\BuiltIn\DefaultDomain

To avoid that the users must remember two different realms, one for the Web publishing and one for the VPN, we can make the realms the same with the help of the above registry setting. Another way to achieve the same result is to manipulate the realm name in a Connection Request Profile by rewriting the realm or simply dropping it so that only the user account name is passed on for authentication. In that case the IAS service will use his default realm. In my lab I opted for the latter solution and replaced on both the domain integrated and stand-alone IAS the default Connection Request Policy Use Windows authentication for all users with a custom Connection Request Policy Windows authentication with realm stripping as shown below:

Note: to learn more on how Radius attributes can be manipulated, check out the Internet Authentication Service web site.

Once the above Connection Request and Remote Access Policies were implemented, the Radius stuff was working very smoothly for this specific scenario. Looking now a little bit into the difference between the Radius and Radius OTP authentication validation method on ISA server, I see three main differences so far.

First of all, when you select Radius OTP on the Web Listener than the advanced authentication settings Client Credentials Caching is greyed out.  The reason for this is that by definition the passcode of an OTP system can’t be used a second time. Therefore ISA Server does not revalidate the credentials for each request or after a certain time. Rather, ISA Server issues a cookie to the client that allows continued communication without reauthenticating.

Secondly, the default Radius OTP HTML form doesn’t provide you with the choice between a private or public computer as with the default Radius HTML form, although the Application Settings in the properties of the Web Publishing rule let you choose between Always public and As selected by user (public or private). As you probably know, the choice between a private or public computer determines the value of the HTTP header element X-LogonType sent by ISA server to the published service. With the default Radius OTP HTML form the X-LogonType is always set to “public”.  

Thirdly, I have observed that in the case of Radius OTP the field Passcode in the default HTML form is limited to 16 characters maximum. Looking into the HTML code generated by the default Radius OTP HTML form, you can clearly see that there is a limit on the maximum length of the variables username and passcode:

The obvious question is why have the designers done that? Is there a particular reason for or can that be easily changed without negative effect? Honestly, I don’t see any reason why there should be any limitation imposed except for those defined in the Radius RFC’s.  

As from ISA Server 2006 onwards, the preconfigured HTML logon forms can be used in their default configuration, or can be customized, allowing you to provide a different look for the logon forms for different published Web sites. For more information, check out the document Customizing HTML Forms in ISA Server 2006 on the Microsoft ISA Server web site. However, whether the choice between a public and private computer can be easily added to the default or a custom Radius OTP HTML form, is something we’ll have to investigate further. Nevertheless it seems that changing the maximum length of the variables username and passcode in the Radius OTP HTML form is as simple as changing the corresponding Radius OTP HTML file ‘usr_pcode.htm’.

 
HTH,
Stefaan