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

That should definitely work for you. Just remember that the Kerberos SSO profile needs a valid domain username and the domain name, not a password. I'd also recommend, because of the complex nature of Kerberos, that you develop and test this outside of the portal first if you can.

thanks Kevin, two more questions

 

- I do need a delegation user right? i can't get away with just providing the domain username and domain name?

 

- it will work fine without a Keberos server as AAA server? i login against Microsoft Active Directory, that is enough?

 

Correct. You need the AD delegation user account, a Kerberos SSO profile that points to that account, and you must pass valid AD username and domain values to the SSO (via the user name and domain source variables).

AAA is for client side authentication (client to APM). SSO is for server side (APM to server).

ok thanks, ill hope to give this a try next week and report back if it worked :)

im not quite getting there:

 

Websso Kerberos authentication for user 'user' using config '/DMZ/sso-kerberos'

 

adding item to WorkQueue

 

sid: ctx:0x92384d8 server address = ::ffff:192.168.8.21

 

sid: ctx:0x92384d8 SPN = HTTP/ext-hostname.domain.uk@DOMAIN.UK

 

S4U ======> ctx: , sid: 0x92384d8, user: user@DOMAIN.UK, SPN: HTTP/ext-hostname.domain.uk@DOMAIN.UK

 

Kerberos: Failed to get ticket for user user@DOMAIN.UK

 

failure occurred when processing the work item

 

as im not quite sure were to check id like to double check some things:

 

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

 

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

 

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

 

 

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.

 

thanks Kevin, I believe i have the delegation user clear now and that is how i created the user.

 

 

for the rest i seem to do what you advise, the little piece of log shows that all information seems to match: username, domain, server IP,...

 

 

it only still fails to get that ticket. is there any debugging i can do here? i checked the AD event log, but don't see an error, just some successful kerberos events.

 

 

A few things:

 

 

1. Turn up debug logging for SSO in the GUI (System - Logs - Configuration - Options)

 

 

2. Run a WireShark capture from the DC and look at Kerberos traffic.

 

 

Can you post those logs?

SSO logging is set to debug.

 

 

the error "Kerberos: Failed to get ticket for user ..." is gone when removing the IP of the AD server from the KDC field. but now i have a feeling no ticket is requested. i see nothing in the AD log around the time to SSO is attempted. only a "A Kerberos authentication ticket (TGT) was requested." for the user when the user logs in to the webtop.

 

should i expect an entry in the AD when access to the site is attempted?