ISA and TMG firewalls enable the use of Kerberos Constrained Delegation (KCD) to accomplish pre-authentication at the firewall and authentication protocol transition. What does this mean? This means that external users can use one protocol to authenticate to the ISA firewall and then the ISA firewall can authenticate on behalf of the user using a different authentication method.
For example, suppose you want to allow users to gain access to your Exchange 2007 OWA Web site. The Web site requires that you use Windows integrated authentication. The ISA or TMG firewall is configured to use forms-based authentication. What happens?
The external user fills out the form. This information is passed as clear text inside an SSL tunnel; that is to say, the credentials are not encrypted or encoded hashed -- they are just made private inside the SSL connection between the external user and the external interface of the ISA firewall.
The ISA or TMG firewall then uses these credentials to authenticate the user against the AD. Once the user is successfully authenticated by the ISA or TMG firewall, the next step is to have the user authenticate with the OWA Web site on the Exchange Server.
There are two ways this could be accomplished:
- The external client can authenticate directly with the OWA Web site -- this would generate a second authentication prompt and the user would have to enter credentials a second time. This is guaranteed to make your users unhappy
- The ISA or TMG firewall can authenticate on behalf the client; essentially impersonating the client by sending the authentication request to the OWA Web site. This is a better solution, since the ISA or TMG firewall is sending credentials on behalf of the client, thus removing the need for the client to enter the credentials again himself
The problem is that forms-based authentication is a free text authentication protocol. If there were no authentication protocol transition, the free text credentials would be passed to the OWA Web site and the OWA Web site would say "hey, we only uses Windows integrated authentication here, go away!"
However, because the ISA and TMG firewall can use protocol transition, it can take the credentials information obtained from FBA and forward (delegate) those credentials using Windows Integrated authentication.
Sounds pretty good, eh? That's because it is! However, the type of protocol transitions that are available depend on what authentication protocol you use to authenticate with the ISA or TMG firewall.
For example, in order to use integrated authentication with the Outlook RPC/HTTP client, you need to use integrated authentication when authenticating to the ISA or TMG firewall if you don't want to have to enter credentials when opening up the Outlook client (that is to say -- allow cached credentials to be used). That means you have to set the client to use integrated authentication. While the ISA or TMG firewall's Web listener can be configured to accept integrated authentication, integrated to integrated authentication is not supported. You have the options:
- No delegation, but client may authenticate directly
- No delegation, and client cannot authenticate directly
- Kerberos constrained delegation
The first option doesn't solve the problem of repeated authentication prompts, and the second option doesn't solve the problem, since it will not allow the client to authenticate to the RPC/HTTP site at all. However, the third option does solve our problem.
When KCD is used, the ISA or TMG firewall will be able to accept the integrated authentication receipt of client credentials and delegate (forward) them to the RPC/HTTP Web site as Kerberos credentials. This is what enables the RPC/HTTP users to not need to enter their credentials each time they open Outlook.
For a good explanation of KCD, check out the this nice article by Karin Galli Bauza at
Thomas W Shinder, M.D., MCSE
Sr. Consultant / Technical Writer