Preparing the ISA Server 2006 for Kerberos Constrained Delegation
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
Stefaan Pouseele Blog » Blog Archive » Playing with Radius Authentication and ISA Server 2006 Says:
December 26th, 2006 at 11:50 am
[…] 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. […]
Thomas Shinder Blog » Blog Archive » How to Enable Integrated Authentication for Outlook RPC/HTTP Clients to Prevent Authentication Prompts with 2006 ISA Firewalls Says:
September 6th, 2007 at 6:22 am
[…] http://blogs.isaserver.org/pouseele/2006/11/16/pre...ation/ […]
Nelson Puello Says:
September 7th, 2007 at 6:45 am
Stefaan,
You should point out in your article that IIS on an Exchange Server computer runs under the Network Service account, which is basically the computer account. Because of this the SPN on the ISA server should specify the host name, and not the website. However, when you’re dealing with websites that have different host headers and are running in application pools that have different service accounts, then you must set the SPN to point to the appropriate website name and the SPN for that website must be registered to the appropriate service account. The point of an SPN is to help the KDC find which account a service is running under. Thanks.