mixing SSO methods, i.e. ntlm, basic http and kerberos

Here are some basic steps for configuring APM Kerberos (server side) SSO:

 

 

1. Create an AD use service account. You'll need to give this account a service principal name so that it can participate in delegation, so create something arbitrary and unique. I like to use the short name plus the domain, so for example if the account name is "krbsrv" in the domain "mydomain.com", the SPN might be "host/krbsrv.mydomain.com" (Use a host/ SPN service type here). In the User Logon Name property of the account, enter this SPN. The pre-Windows 2000 (short) name doesn't matter.

 

 

2. Add the SPN to the servicePrincipalName property of the account. In 2008 you can do Advanced View in Active Directory Users and Computers. In 2003 you can use ADSIEDIT.msc. You can also use SETSPN from the command line. Find the servicePrincipalName property and add the same SPN as above.

 

 

3. Close and re-open the account properties. Because you've added a servicePrincipalName property, the delegation tab will now be visible. Go to the delegation tab and click "Trust this user for delegation to specified services only" and "Use any authentication protocol". The former enables KCD and the latter enables KPT. Look for and add the HTTP service for each of the web servers that this will service.

 

 

4. Configure BIG-IP DNS. Make sure that you have a reverse zone created and that each web server has a forward and reverse entry.

 

 

5. Create the APM Kerberos SSO profile. The Kerberos realm is the UPPERCASE name of the AD domain. The Account Name can either be the user service account's short name or the SPN. I prefer the SPN because it removes ambiguity if you need to do cross-domain authentication. Make note of the Username and User Realm Source variables. Kerberos SSO does protocol transition based on these two values. Your access policy will need to populate these two variables with valid AD username and domain values before the SSO is called.

 

 

6. Create the access policy and apply the SSO profile.

 

 

 

A few words on how the Kerberos SSO profile works:

 

 

By default, the Kerberos SSO profile uses a reverse DNS lookup from the domain to determine the service principal name value from the selected (load balanced) IP address for the purposes of load balancing Kerberos-based traffic. If the web server application pool is running in the context of the host machine, then the derived service principal name will correspond to the actual service principal name (HTTP/machine-name@DOMAIN) of the web server. If, however, the web services are running in the context of another account, then that account must have an HTTP service principal name, and that value will have to be applied to the SPN Pattern section in the Kerberos SSO profile configuration. This effectively overrides the default reverse DNS lookup mechanism.

 

 

 

So to answer your questions:

 

 

[Q] on the SSO profile should be user be in the format host\delegation_user.domain ? or just delegation_user

 

[A] Could be either. See 5 above.

 

 

[Q] should on AD side be HTTP/ext-hostname.domain.uk@DOMAIN.UK allowed as service? or is HTTP/ext-hostname enough?

 

[A] Not sure I understand this question. You'll add the HTTP SPN of each web server to the AD user service account used for SSO.

 

 

[Q] although the SPN appears to be HTTP/ext-hostname.domain.uk@DOMAIN.UK the actual website is hostname.domain.uk, is that an issue?

 

[A] You're referring to client side authentication (AAA). In that case the SPN would need to match the address for the browser's sake. For SSO though, you're creating an arbitrary SPN for the user service account that only the SSO profile knows about.