kerberos to web app

Just a thought- APM is performing reverse DNS looking to get the hostname for the backend note when it does Kerberos SSO. I've seen at least one situation where there were multiple records for the server nodes in DNS, and if the returned name by DNS did not match the SPN delegation setup, it caused havoc. I'd recommend checking reverse DNS and see if the resolved name always come back the same and not round-robins somehow.

If Michael's ideas are true, you can test this theory by adding the two host names and IP addresses to the local Hosts section (System - Configuration - Device - Hosts). This should effectively shunt the reverse lookup in favor of the local entry.

You can also (without doing the above) run a capture (preferably on the DC) and look at the Kerberos AND DNS traffic. I think you'd see the wrong name coming back if the above is true. Do you notice by chance if this happens on both servers or just one?

A few thoughts:

1. Are you certain that it's a server side SSO issue? Can you isolate it by temporarily turning off client side Kerberos and setting static (test) username and domain values for the SSO?

    

2. What is the hostname you're referring to? Are the users in a different domain than the servers?

    

to my understanding, a seperate account is used to run Kerberos from the F5 to the web server and that has to be in the host/apmsso.mydomain.com format, correct??

Correct. Mostly. For Kerberos SSO you need an account in the AD that can perform delegation. To be able to do delegation that account must have a servicePrincipalName value (without it the delegation tab is missing). Now, how APM accesses that account is another story. You can simply use the short NETBIOS name in the SSO profile config, but that can lead to ambiguity when doing cross-domain authentication. The recommendation then is to use the SPN value of that account (host/apmsso.mydomain.com) as the user logon name as well (host/apmsso.mydomain.com), and then also use that as the name in the Kerberos SSO profile - with REALM added (host/apmsso.mydomain.com@MYDOMAIN.COM). That account then delegates to all of the HTTP/ SPNs of the web servers.

It sounds like the users and servers are all in the same domain (mydomain.com). If that's true then the secondary domain doesn't affect the SSO as all three parties are in the same domain (users, servers, delegation account). Users from mydomain.com access an APM VIP that has a keytab from workdomain.com. The client goes out and does its own cross-domain auth to get a ticket for this VIP and then presents that to APM for validation. After that the username from the ticket and the domain (mydomain.com) is presented to the SSO for server side auth. Is that about right?

At this point I'd highly recommend those packet captures from the DC. You want to see the Kerberos and DNS traffic.

1.) I have the AAA and SSO account setup as you said. the only difference is that for the account name i use host/apmsso.mydomain.com and that works.. (see image)

2.) Question - Since the F5 is making a request to the DCs, couldnt i get the Kerberos and DNS traffic captures of that instead? or Does the DC do separate queries?

Just to verify, the servers, users, and delegation account are all in the SAME domain, correct? If so then the account name format isn't so important.

Any particular reason for using "On 401 Status Code"?

You can absolutely get the Kerberos and DNS traffic from the BIG-IP. I'd write to a file and import into Wireshark for better visibility.

absolutely weird.. today, i have had 8 testers try and it works for everyone.. didnt touch or change anything.. all the packet captures look clean.. F5 delegated acct makes the request to the web server, web server spits back a 401, and the F5 replies with the properly formatted machine name SPN..

hate the fact i dont know what is causing the failure.. trying to create a failure now..