In the planning and architecture document Authentication in ISA Server 2006 you’ll find a very good overview of the authentication process used by ISA Server 2006. The three major steps are: challenging the user for his/her credentials, validating those credentials against an authentication provider and delegating the validated credentials to the published servers. One of the delegation options you can use is the Kerberos constrained delegation method, which is described in the technical article Kerberos Protocol Transition and Constrained Delegation.
To implement the Kerberos constrained delegation method, the ISA Server must first be enabled on the domain controller to use Kerberos constrained delegation, constrained to a specific Service Principal Name or SPN in short. How to actually accomplish this isn’t very well described on the Microsoft ISA Server site. Lucky for us Tom has already written a two part article serie about Configuring ISA Firewalls (ISA 2006 RC) to Support User Certificate Authentication using Kerberos Constrained Delegation and documented in there how to configure the ISA Server computer account to be trusted for delegation. Despite this excellent step-by-step instructions, you could still make some ‘creative’ mistakes as I’ve learned from hard experience.
If you look at the Delegation tab of the ISA Server computer account in the active directory, you have three main choices as shown in the figure below:
I can’t stress it enough, resist the temptation to select Trust this computer for delegation to any service (Kerberos only), even in a lab environment because it simply won’t work. The reason is that the choices Trust this computer for delegation to any service (Kerberos only) and Trust this computer for delegation to specified services only *AND* Use Kerberos only implies that Kerberos was used to originally authenticate the user against the ISA Server. That’s clearly not the case because Forms Based or Basic authentication is normally used. Therefore, make sure you select Trust this computer for delegation to specified services only *AND* Use any authentication protocol.
As a consequence you have to add the services to which the ISA Server computer account can present delegated credentials. As suggested in the publishing rule, you can list, add and delete Service Principal Names (SPN’s) with the setspn tool. In my lab the Exchange and IIS services were installed on the active directory controller with the FQDN ‘adc.intranet.splab.net’ and the result of the command setspn -L was as follows:
Apparently not all SPN’s are shown with this command because I couldn’t find any entry for the http service. However, don’t panic and don’t start some setspn configurations. Instead you should use the Add wizard on the Delegation tab of the ISA Server computer account in the active directory. There you should find, after selecting the target computer (‘adc’ in my lab environment), the http service.
Another thing to watch out for is the FQDN used in the SPN. In my lab environment I have defined the friendly FQDN ‘mail.intranet.splab.net’ for the OWA and RPC Proxy access. This FQDN is a CNAME of the real computer name ‘adc.intranet.splab.net’. After creating the publishing rule on the ISA Server with the FQDN ‘mail.intranet.splab.net’ in the Public Name and To tab, the proposed SPN on the ISA Server is ‘http/mail.intranet.splab.net’ as shown in the figure below:
Obviously this setting won’t work because we don’t have a match with the SPN ‘http/adc.intranet.splab.net’ used in the Delegation tab of the ISA Server computer account in the active directory. By default the SPN in the Authentication Delegation tab of the publishing rule on the ISA Server seems to use what you have specified in the To tab. Again, don’t panic and don’t start some setspn configurations. Instead simply change this SPN on the ISA Server so it matches the SPN used in the Delegation tab of the ISA Server computer account in the active directory.
Update 31/05/2007: Microsoft released an excellent article Kerberos Constrained Delegation in ISA Server 2006.
HTH,
Stefaan