An ever recurring topic on the message boards is the inability to connect to a VPN server with multiple VPN clients from behind a NAT device. We can assure you that if you run an up-to-date ISA 2004/2006 server, that means one with all the latest ISA and Windows service packs, the culprit is *not* the ISA server but definitely the NAT device not handling properly multiple VPN clients. In this blog we will analyse this scenario for PPTP based VPN clients.

As always, we will use my ISA lab running in VPC 2007 to setup this scenario. The ISA 2006 Server used is listening on the Local External Network (192.168.1.0/24) and the PPTP VPN clients are sitting on the Remote External Network (192.168.11.0/24). Both networks are interconnected with a Windows 2003 RRAS box acting as a NAT device (N:1). As you probably know, RRAS implements a PPTP aware NAT editor to fully support such a scenario. 

Before diving into the details, it’s necessary to have a good understanding of how the PPTP protocol works. Of course the authorative resource is the IETF document RFC 2637 - Point-to-Point Tunneling Protocol (PPTP). If you take the pain reading that RFC, be aware that the VPN client is acting as PNS (PPTP Network Server) and the ISA Server as PAC (PPTP Access Concentrator). However, we can recommend an excellent written Cable Guy article called PPTP Traffic Analysis. It explains very well how the PPTP protocol works and what you have to watch out for when NAT is involved along the path. This is definitely a must read!

When tracing a normal PPTP session setup with a network monitor, you should see the following sequence of frames:

In this example the VPN client is 192.168.1.20 and the VPN gateway (the ISA server) is 192.168.1.10. So, both are connected to the same network ID (192.168.1.0/24). As mentioned in the Cable Guy article the negotiation of the Call ID in the PPTP Outgoing Call Request and Outgoing Call Reply messages is extremely crucial. If we expand those frames 6 (left) and 7 (right) in the above example we get:

You can clearly see that the VPN client chooses the value 256 as his Call ID and the VPN gateway the value 63881. Take note that the VPN gateway repeats the client’s Call ID in the Outgoing Call Reply message as Peer’s Call ID. This must match the Call ID of the corresponding Outgoing Call Request message. Also, those Call ID’s will be further used in the Enhanced GRE header of the PPTP data packets to multiplex/demultiplex the different tunnel sessions between the VPN client (PNS) and the VPN gateway (PAC).  More precisely, each sending party will use the peer’s Call ID in the Call ID field to indicate to which session the packet belongs. In other words, the tunnel is identified by the source and destination IP address and the Call ID field in the Enhanced GRE header. To illustrate this, we expanded the frames 9 (left) and 10 (right) in the above example:

Now that we know what to look for, we can finally analyse the N:1 NAT scenario. To accomplish that we placed two VPN clients behind a NAT device (in this case an RRAS server) and simultaneously traced with a network monitor the PPTP session setup on both sides of the NAT device for the first and the second VPN client. When analysing the traces, we carefully looked into the PPTP Outgoing Call Request and Outgoing Call Reply messages, as well into a PPTP data packet in each direction belonging to that session.

For the first VPN client we can summarise the result in the following diagram:

Because this is the first VPN client connecting to that specific VPN gateway, the NAT editor may but must not do anything special except the normal translation of the IP addresses in the IP header (PPTP control connection and PPTP data packets) and the TCP port numbers in the TCP header (PPTP control connection). Remember that the VPN gateway (the ISA server in this case) will see the NATted IP address as source of the tunnel. Also, take note that the VPN client assigns itself again a Call ID value of 256. Apparently this is the standard value for the Windows VPN clients we used on Windows XP and Vista.  

For the second VPN client we can summarise the result in the following diagram:

Because the second VPN client is completely unaware of the first one, the second might also pick the same Call ID value, as in this case. Therefore, the NAT editor on the NAT device must also be capable to monitor the PPTP tunnel creation and if necessary translate the Call ID generated by the VPN client to a unique value just like the TCP/UDP source port numbers are translated. Otherwise, the tunnel can not be unambiguous identified between the NAT device and the VPN gateway. Remember that the triple source IP, destination IP and Call ID must always be unique per tunnel. Also, take note that the Call ID generated by the VPN gateway will always be unique because the gateway is perfectly aware of the other tunnels from/to that specific NAT device (NATted IP address).

It should be obvious by now that in order to pass multiple PPTP VPN clients through a NAT device, the NAT device *must* have a specific PPTP NAT editor. So, if you have problems with multiple PPTP VPN clients behind a NAT device, don’t blame the ISA server but get out your favorite network monitor tool to determine if the NAT device is behaving well.

HTH,
Stefaan

In my blog Require 128-bit Encryption for HTTPS Traffic with ISA Server 2006 (Part2) we analysed what the setting Require 128-bit encryption for HTTPS traffic really means and how it works. By default the Web Proxy component on ISA checks for every HTTPS request if the secure channel used to pass that request has a strong Cipher Suite (at least 128-bit encryption) as property. However, it does *not* prevent the setup of a secure channel with a weak Cipher Suite.

In this last part, we extended the second scenario as outlined in part 2 of this blog series by adding an authentication scheme to that scenario, be it on the web listener or on the web publishing rule. First we tested this new scenario with Basic authentication and were very astonished we got an authentication prompt as shown below:  

Only *after* a successful authentication, we saw the expected IE error page: “Error Code: 403 Forbidden. The page requires 128-bit encryption, an enhanced security mechanism. To view the page contents, use a browser that supports this enhanced encryption (12212)”. Straightaway we tested this scenario with Forms Based authentication and got the same result. Hmm… this means that the authentication is done over a secure channel with a weak Cipher Suite!  

We contacted Microsoft PSS and logged a case for this issue. The outcome is that the ISA developers confirmed my observations and that they are a result of a limitation in the current ISA Server 2004/2006 versions. The good news is that this behavior will change in ISA Server 2006 SP1. For the current ISA 2006 version and all ISA 2004 versions up to and including SP3, you should implement the workaround I mentioned in part 2 of this blog series. Also, this issue will be documented in the upcoming KB Article 937293.

In conclusion, we can say that rolling out KB Article 245030 into all ISA installations to disable the weak SSL/TLS Cipher Suites should be part of the standard hardening exercise for any ISA Server. You can apply the following registry file to accomplish that:

REGEDIT4
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers]
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersDES 56/56]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNULL]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 128/128]
“Enabled”=dword:ffffffff
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC2 56/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128]
“Enabled”=dword:ffffffff
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 64/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168]
“Enabled”=dword:ffffffff

HTH,
Stefaan

Recently I reviewed my article A simple routing table trick and decided to finally check it out in my lab. I must admit that I didn’t test out that scenario at the time of writing that article, mainly because I could rely on a trusted source …   

In my lab http://users.skynet.be/spouseele/VPC-SPLAB.pdf I added the IP address 10.10.10.10/24 to the Local ISA external interface (192.168.1.10/24) and the IP address 10.10.10.30/24 to the Local ROUTER interface (192.168.1.30/24). The device ROUTER, a Windows 2003 SP2 RRAS server, was used to fulfil the role of the DSL Bridge shown in the original article.

The resulting IP configuration on the Local ISA server was:

The resulting routing tabel on the Local ISA server was:

The funny part was now that I did *not* need to define a static route to make sure that the source IP address ‘10.10.10.10′ was used for the traffic destined for ‘10.10.10.30′. It happened automatically as well when testing from the Local ISA server itself as from behind it (Local Internal Network 192.168.22.0/24). Take note that I tested this scenario with ISA 2006 on Windows 2003 SP2. Obviously, I was a little bit surprised and contacted Jim Harrison to check out if he could confirm my findings. Here is his answer:

[quote]
When I was working through that discussion (my own DSL bridge is what prompted the investigation), I noted that the routing table was built using the default gateway, rather than the local-net IPs. That’s what prompted my inclusion of the manual route.
Since then, I noted (as did you) that the manual route shouldn’t be necessary, and in fact, when I built a replacement ISA (moving to 2006), this was not required. I think it may have been because I had so many routes defined in RRAS that this was required, but I can’t say for certain now because it’s gone…
[/quote]

Thus, assuming no route is defined for a “super-net” of the subnet used between the ISA server and the DSL Bridge, it shouldn’t be necessary to configure a persistent static route to make it work. Also, it might be a good idea to minimize the mask of that subnet in order to avoid a possible IP conflict. In the above example, the smallest subnet we could create is 10.10.10.0/30 (mask 255.255.255.252). This gives us only two valid IP’s: 10.10.10.1 & 10.10.10.2. Of course, if such a “micro-net” can be used depends on the IP configuration capabilities of the LAN interface of the DSL Bridge, at least when playing by the book.

HTH,
Stefaan

In my blog Require 128-bit Encryption for HTTPS Traffic with ISA Server 2006 I posted a workaround for enabling Redirect all traffic from HTTP to HTTPS *and* Require 128-bit encryption for HTTPS traffic in a web publishing rule. However, what does that setting Require 128-bit encryption for HTTPS traffic really means and how does it work?

According to the ISA help file, the setting Require 128-bit encryption for HTTPS traffic means: Click to specify that HTTPS requests that do not use 128-bit encryption will be blocked. Hmm… does that mean that the ISA Server will refuse HTTPS requests if they are send over a secure channel (SSL/TLS) that uses a weaker encryption algorithm, or that a secure channel (SSL/TLS) will not be setted up in the first place when both parties don’t agree on a strong encryption algorithm?

To find it out, we have to watch the SSL/TLS handshake protocol with a sniffer like NetMon or Wireshark. Particular we are interested in the Client Hello and Server Hello messages used to negotiate the Cipher Suite, that is a list of key-exchange algorithms and Cipher Specs supported.  Of course, this means that you need a basic understanding on how the SSL/TLS handshake protocol works. Some good resources to learn more about the SSL/TLS handshake protocol are:

• Secure Socket Layer
• Welcome to the SSL Tutorial

Now that we know what to look for and assuming that we have a properly configured ISA Server with a sniffer enabled on the external interface, we also need a method to define which Cipher Suites will be offered by the client and/or will be accepted by the server during the SSL/TLS handshake. In that way we can determine how ISA Server will treat a none compliant client (or a bad guy). The key to the whole discussion here is the Microsoft Knowledge Base Article 245030 How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll. Take note that the SChannel is the heart of the Windows cryptographic mechanisms. Therefore ISA server rightly defers to Windows for all encryption. In other words, ISA server should just been seen as a consumer of the Windows SChannel stuff, not as the owner of it.

In the first scenario we use a standard Windows XP SP2 client and a standard ISA 2006 SE server (on Windows 2003 SP2) with the setting Require 128-bit encryption for HTTPS traffic enabled. Here is an excerpt of the SSL/TLS handshake:

If we go into the details of the Client Hello message (frame #4), we get the following information:

As you can clearly see, the Session ID is zero which means that a new connection for a new SSL/TLS session is being negotiated. Also, the client proposes 11 Cipher Suites to the server from which the server should choose one, normally one of the strongest. The Cipher Suite chosen by the server is then reported back to the client in the Server Hello message (frame #5-6) as shown in the figure below:

As you can see a strong cipher is chosen by the server. This completes the analyses of the SSL/TLS handshake in the context of this blog.

In the ISA logging you should find the following sequence of events:

In the second scenario we configure the client so that only weak ciphers are proposed to the server. To accomplish that we use KB245030 to disable the SChannel Ciphers RC2 128/128, RC4 128/128 and Triple DES 168/168 located under the HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL key in the registry. When we try now to access the exact same published web site as in the first scenario, IE gives the following error page:

 

This sounds good because we can’t access anymore that published web site as expected. However, due to the fact we get a specific error page ”Error Code: 403 Forbidden”, we can assume that ISA reported the error code back to the browser. As a result the SSL/TLS session must have completed successful, otherwise no communication path was available between the browser and the ISA server to send that message. So, let’s verify that with the help of a network trace. Here is an excerpt of the SSL/TLS handshake:

If we go into the details of the Client Hello message (frame #6), we get the following information:

As you can clearly see, the Session ID is zero which means that a new connection for a new SSL/TLS session is being negotiated. Also, the client proposes now only 7 Cipher Suites to the server from which the server should choose one, normally one of the strongest. The Cipher Suite chosen by the server is then reported back to the client in the Server Hello message (frame #7-8) as shown in the figure below:

As you can see the server could not select a strong cipher because no one was offered. Thus a weak one was indeed chosen by the server to be able to report back the error page ”Error Code: 403 Forbidden” to the client. Take note that no other data is allowed by the ISA server because the negotiated cipher didn’t fulfil the Require 128-bit encryption for HTTPS requirement.

In the ISA logging you should find the following sequence of events:

In the third scenario we additional configure the server so that only strong ciphers are accepted. To accomplish that we use again KB245030 to make sure that only the SChannel Ciphers RC2 128/128, RC4 128/128 and Triple DES 168/168 located under the HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL key in the registry are enabled. All other SChannel Ciphers should be disabled. When we try now to access the exact same published web site as in the first scenario, IE gives the following error page:

Again, this sounds good because we can’t access anymore that published web site as expected. However, due to the fact we get a generic error page, we can assume that the server actively refused the SSL/TLS session. As a result the Web Proxy component on ISA was never aware of that connection attempt. So, let’s verify that with the help of a network trace. Here is an excerpt of the SSL/TLS handshake:

If we go into the details of the Client Hello message (frame #8), we get the following information:

As you can clearly see, the Session ID is zero which means that a new connection for a new SSL/TLS session is being negotiated. Also, the client proposes again only 7 Cipher Suites to the server from which the server should choose one, normally one of the strongest. However, instead of responding with a Server Hello message, the server closes the TCP connection (frame #9-13). The obvious reason for this is that the client was configured to only propose weak ciphers and that the server was tuned to only accept strong ciphers. Thus no common Cipher Suite could be negotiated and therefore the SSL/TLS negotiation was aborted. 

In the ISA logging you should find the following sequence of events:

In conclusion we can say that if the setting Require 128-bit encryption for HTTPS traffic is enabled then the Web Proxy component on ISA checks for every HTTPS request if the secure channel used to pass that request has a strong Cipher Suite (at least 128-bit encryption) as property. However, it does *not* prevent the setup of a secure channel with a weak Cipher Suite. If you want that level of control then the registry changes to limit the SSL/TLS Cipher Suites (KB245030) are the right answer. Take note that limiting the SSL/TLS Cipher Suites is a machine global configuration. Thus you can’t control that on the rule level.

We can debate about which approach is the best. Personally, I would like to see that a new Global HTTP Policy Setting was added to the ISA Server MMC (Configuration -> General) which gives us the choice to only enable the strong SSL/TLS Cipher Suites. Of course, when this new Global HTTP Policy Setting would be enabled then the Require 128-bit encryption for HTTPS traffic setting on the rule level should be automatically deactivated (greyed out).

HTH,
Stefaan

—– Begin Original Message —–
From: isapros-bounce@freelists.org On Behalf Of Jim Harrison
Sent: zaterdag 17 maart 2007 22:45
To: isapros@freelists.org
Subject: [isapros] WS03 SP2 and ISA 2004/6 Ent Edition

For those of you who are considering deployment of Windows 2003 SP2 on your ISA 2004 or 2006 CSS server, you better be reading the SP2 relnotes (you better be doing it anyway, yanumpty).

The short story is this. If you install WS03 SP2 over ADAM RTM (as is delivered in ISA 2004 & 2006 for WS03 RTM & SP1), you will break ADAM. This does not occur if your ADAM instance was installed as part of WS03 R2. Otherwise, you *MUST* get and install ADAM SP1 before installing WS03 SP2.

You can get ADAM SP1 (already part of WS03 R2) here:
http://www.microsoft.com/downloads/details.aspx?Fa...B5C8E4

You can get Windows 2003 SP2 here:
http://www.microsoft.com/technet/windowsserver/sp2.mspx

You can check out the readme here:
http://go.microsoft.com/fwlink/?LinkId=75002

You can get the WS03 SP2 Relnotes here:
http://go.microsoft.com/fwlink/?LinkId=75107  

Ain’t life grand?

Jim
—– End Original Message —–

HTH,
Stefaan

You create a secure web publishing rule (SSL Bridging). In the tab Traffic on the Web publishing rule you will see that:

• the checkbox Notify HTTP users to use HTTPS instead is not available (greyed out).
• the checkbox Require 128-bit encryption for HTTPS traffic is available.

Next, you want to change the rule so that HTTP traffic will be redirected as HTTPS traffic. Therefore you go to the Web Listener, tab Connections and make the following changes:

• check the box Enable HTTP connections on port (default port is 80).
• select the radio button Redirect all traffic from HTTP to HTTPS.

You apply the changes and verify that everything is working as expected.

Finally, you want to enforce 128-bit Encryption for HTTPS traffic. So, you go the Web publishing rule, tab Traffic and see that:

• the checkbox Notify HTTP users to use HTTPS instead is not available (greyed out).
• the checkbox Require 128-bit encryption for HTTPS traffic is also not available (greyed out).

Why?!?! Hmm… how can we redirect HTTP to HTTPS *and* require 128-bit encryption in one step?

After some experimenting I found out that you can get it to work if you perform the following steps in sequence:

• go to the Web Listener, tab Connections and make sure you select the radio button Do not redirect traffic from HTTP to HTTPS.
• next go to the Web publishing rule, tab Traffic and you will see that the check box Notify HTTP users to use HTTPS instead becomes available. Check that box.
• by doing that the check box Require 128-bit encryption for HTTPS traffic becomes also available. So, check that box too.
• finally, go back to the Web Listener, tab Connections and now select the radio button Redirect all traffic from HTTP to HTTPS.

Now, apply the changes and verify that on the Web publishing rule, tab Traffic you see the following:

• the checkbox Notify HTTP users to use HTTPS instead is checked but not available (greyed out).
• the checkbox Require 128-bit encryption for HTTPS traffic is checked and available.

Why this strange dependencies in the GUI? This really sounds like a bug because I can’t figure out the logic behind this!

So, I contacted Microsoft PSS and logged a case for this GUI problem. They confirmed my findings and are investigating how to fix that GUI problem. In the mean time, you can use the workaround I posted above.

HTH,
Stefaan

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 SPLABtest 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

In my blog Redirecting OWA Users to the Correct Directories and Protocols with ISA Server 2006 I reported a problem with my OWA publishing rule with ISA Server 2006. Removing the special path mapping I used with ISA Server 2004 to translate the root path “/” to the special Exchange path “/Exchange\” solved the problem. To resolve the redirection problem, I implemented the redirection in the ‘default.htm’ file in the root directory of the OWA site as described in my blog.

On January 24, 2007 Microsoft published a new KB article You cannot apply an OWA Web publishing rule that redirects users who connect to the root of the OWA Web site to an internal folder by using ISA Server 2006 that seems to apply to the OWA path mapping problem I reported. To resolve this problem, you need to install the update that is described in the KB article Update is available that supports publishing Microsoft Exchange Server 2007 behind Internet Security and Acceleration (ISA) Server 2006.  I downloaded this update and installed it in my ISA lab. Next, I implemented once again the special path mapping to translate the root path “/” to the special Exchange path “/Exchange\” and removed the redirection in the ‘default.htm’ file in the root directory of the OWA site. Finally, I rebooted the ISA server to be sure that there are no startup problems and tested out the redirection by just entering the FQDN of the OWA site in IE. The redirection of the protocol and the path was working flawless.  

HTH,
Stefaan

The very first article I wrote for ISAserver.org is Understanding the Firewall Client Control Channel. That article explains how the Firewall client talks to the ISA Server 2000 through the Control channel by using the Remote Winsock Protocol (RWSP). It shows how authentication credentials, name resolution queries and the Data channel negotiations are sent along the Control channel. Keep in mind that no real data is exchanged on this channel. 

The most significant improvement the ISA Server 2004 and later Firewall client has over the previous ISA Server 2000 version is that the Control channel is now encrypted by default. This means that user credentials, who are sent transparently with each request on the Control channel, will not be intercepted by someone who may be “sniffing” the network. The drawback is of course we can no longer monitor the Control channel for diagnostic purposes. Apart from the document Internal Client Concepts in ISA Server 2006 there is no much information found on how exactly the newer Firewall client version works. So, I assume that what I found out with my empirical study of the ISA Server 2000 Firewall client is still largely valid.

On January 18, 2007 a short article was published on the ISA Server Product Team Blog which confirms one of the findings in my article. A KeepAlive packet is sent by the Firewall client every 10 minutes. This means that if a device between the client and the ISA Server has an idle connection timeout configured for less than 10 minutes, then this device will force the closing of the Control channel, with the result that the ISA Server and the Firewall client will drop the Data connection shortly thereafter.

For more information, check out the article TCP connection established using Firewall client may close unexpectedly.

HTH,
Stefaan

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