In my blog Playing with Radius Authentication and ISA Server 2006 I created the necessary environment to test out in a generic way, that means independent of any real hardware token system, the use of a two-factor authentication system with ISA Server 2006. That test environment is based on a non-domain joined Radius OTP service (IAS) as authentication provider for the users and on the capability of the ISA Server 2006 to use Kerberos constrained delegation for authentication on behalf of the users to the published service.
For normal Web publishing such as Outlook Web Access this works great. As shown in the diagram below, the basic configurations steps are: (1) on the Web Listener we use Forms Based Authentication (FBA) and select Radius OTP as Authentication provider and (2) on the Web Publishing rule we use Kerberos constraint delegation to the published Web Server.
Keep in mind that for Radius OTP the authentication is only done once per session. ISA Server issues a cookie to the client that allows continued communication without re-authenticating.
In my quest for strong user authentication I want to find out if the above concept could also be used for RPC over HTTP services such as Outlook Anywhere (Outlook 2003/2007) and the upcoming TS Gateway in Longhorn. So, let’s draw a little diagram to outline the different components:
On the client side we have two main components. First of all the client programme itself which can be the Outlook 2003/2007 client (OLK) or the Remote Desktop Connection client (RDC) version 6. Secondly we have the RPC over HTTP Proxy client (RPC Proxy Cln) integrated in the OS from Windows XP SP2 onwards.
On the server side we have also two main components. First of all the server programme itself which can be the Exchange 2003/2007 Front End server (Exch FE) or any Terminal Server service (TS Srv) as well as any Remote Desktop service (e.g. Windows XP). Secondly we have the RPC over HTTP Proxy server (RPC Proxy Srv) as an extra Windows Networking Service that integrates into IIS on Windows 2003 and Longhorn. Take note that on Windows 2003 the RPC over HTTP Proxy server only supports the Exchange 2003/2007 server programme. On Longhorn the RPC over HTTP Proxy server together with some additional components can be used as TS Gateway too.
On the ISA Server we extended the Outlook Web Access publishing rule with the RPC over HTTP functionality, this means adding the correct RPC path. Thus, as shown in the diagram above, the basic configurations steps are still: (1) on the Web Listener we use Forms Based Authentication (FBA) and select Radius OTP as Authentication provider and (2) on the Web Publishing rule we use Kerberos constraint delegation to the published Web Server. Take note that ISA Server will evaluate the user-agent field in the HTTP header. For RPC over HTTP the value of the user-agent field is set to “MSRPC” by the RPC over HTTP Proxy client. Because ISA Server knows this user-agent doesn’t support Forms Based Authentication, Basic authentication will be used as a fall-back mechanism instead.
The first thing we have to find out is if the RPC over HTTP Proxy client itself is capable of supporting a different set of credentials to authenticate against the ISA Server (1) and the published server (3). In the Windows Server 2003 Resource Kit Tool you can find a little tool called the RPC Ping utility. It can be used to troubleshoot connectivity issues with RPC over HTTP and it’s usage is explained in the KB article How to use the RPC Ping utility to troubleshoot connectivity issues with the Exchange over the Internet feature in Outlook 2007 and in Outlook 2003. In my lab environment the RPC Ping utility was used as follows:
- Create in Active Directory two users ‘SP’ and ‘Test’ with different passwords. The user ‘SP’ has an Exchange mailbox.
- Create in the non-domain joined IAS also the user ‘Test’ but with a different password from the password used within Active Directory.
- From an external host use the rpcping command to test the connectivity to the Exchange Information Store service (6001):
C:\>rpcping -t ncacn_http -s adc.intranet.splab.net -o RpcProxy=mail.intranet.splab.net -P "test,SPLAB,*" -I "sp,SPLAB,*" -u 10 -a connect -H 1 -u 10 -v 3 -F 3 -e 6001
which give the following successful result:
RPCPing v2.12. Copyright (C) Microsoft Corporation, 2002 OS Version is: 5.1, Service Pack 2 Enter password for server: Enter password for RPC/HTTP proxy: Completed 1 calls in 501 ms 1 T/S or 501.000 ms/T
Take note we used the IAS user ‘test’ to authenticate against the ISA Server (1) and the AD user ‘sp’ to authenticate against the published server (3).
- In the IIS logging of the RPC over HTTP Proxy server we have the following entry:
2006-11-28 08:28:54 192.168.22.3 RPC_OUT_DATA /rpc/rpcproxy.dll adc.intranet.splab.net:6001 443 SPLAB\test 192.168.22.1 MSRPC 200 0 0
This proves that the ISA Server can authenticate successful on behalf of the user ‘test’ with the help of the Kerberos constraint delegation mechanism (2).
The above test scenario demonstrates clearly that the RPC over HTTP Proxy client itself is capable of supporting a different set of credentials to authenticate against the ISA Server (1) and the published server (3). However, does that also mean it can support the use of a two-factor authentication system with ISA Server 2006?
The pitfall here is the authentication method used to authenticate against the ISA Server (1). As far as I know the RPC ping utility exposes all the methods the RPC over HTTP Proxy client is capable of. That means that only Basic and NTML authentication is supported (rpcping -H argument). Also, on the ISA Server you have to select Forms Based Authentication on the Web Listener in order to be able to check either Radius OTP or RSA SecureID as Authentication provider. However, with the RPC over HTTP Proxy client (user-agent = MSRPC) the ISA Server will fall-back to Basic authentication, even when FBA is configured.
The problem is now that if you change the authentication method on the Web Listener to Basic authentication instead of FBA than you can’t select neither Radius OTP nor RSA SecureID as Authentication provider. In other words, FBA itself seems to be the only valid method to acquire the Radius OTP credentials. This isn’t that illogical because the authentication should only be done once per session and ISA Server must issue a cookie to the client that allows continued communication without re-authenticating. We can’t ignore that those requirements doesn’t fit well the characteristics of the Basic authentication method.
If we look now at the client side than we see that the Outlook 2003/2007 client cannot use two different set of credentials to authenticate against the RPC Proxy server and the Exchange Server. In other words, it will send to the Exchange Server the same credentials used to authenticate against the RPC Proxy server. This is by design and there is no work around possible. Moroever, although the Remote Desktop Connection V6 client prompts for two sets of credentials, it supports only NTLM and Smart Card to authenticate against the RPC Proxy server. As a result it looks very much we are stuck with the client capabilities too.
With confirmation from Microsoft PSS and Jim Harrison, I can assure you that what I want to achieve is *not* possible with the current RPC over HTTP code in the client. In other words, it’s unreasonable for us to expect any non-browser such as an RPC over HTTP client to have any FBA capabilities. Moreover, it can not been solved by “fixing a bug”, but rather it would require Design Change Requests (DCRs) within multiple products. Therefore, it’s very unlikely it will happen unless there is a huge customer demand.
Thus, my conclusion is that if single-factor authentication (read passwords) is good enough than the RPC over HTTP stuff is really useful. Otherwise, a VPN is the only current Microsoft answer for “more” authentication with the ISA Server 2006. Maybe we should take a look at the new Microsoft product Intelligent Application Gateway (IAG) 2007 to find out if it can solve this kind of problems. The IAG 2007 product is announced as the comprehensive, secure remote access gateway that provides secure socket layer (SSL)-based application access and protection with endpoint security management.
HTH,
Stefaan