Multiple apps doing kerberos

I think you might need to create 2 virtual servers with 2 different surrogate accounts. And you may have to close the browser(IE) before accessing the second virtual server.

There are actually a few ways to go about this, but first it's important to distinguish client side and server APM Kerberos as two completely separate things. I mention this because only client side (AAA) APM Kerberos requires a keytab, while server side (SSO) APM Kerberos does not. So with that aside, let's run through some of the options:

1. Create separate SSO profiles for each - as I'm sure you're aware, Kerberos is dependent on a unique servicePrincipalName (SPN) for each service. This unique SPN maps to an encryption key in the KDC's database, and that encryption key is used to encrypt and decrypt messages to/from the entity that owns that SPN. So for example, let's say you have a Kerberos-enabled web server. That web server service must be associated with a SPN. In IIS that is the SPN assigned to the account that owns a particular application pool (that is then assigned to a website). When a client requests a ticket for a service, it does so by name (SPN). The KDC validates the client's request, generates a ticket, encrypts that ticket with the requested service's key, and then encrypts it all again with the client's key. The client decrypts the outer "shell" and sends the rest to the service. If the client asked for the right service by the right name, the service should have the key necessary to decrypt the inner shell and expose the ticket. If each of your web applications are completely separate in the sense that they cannot share a single Kerberos SPN, then you could create a separate APM Kerberos SSL profile for each and either assign to a respective VIP, or use the WEBSSO::select command in an iRule to switch between the SSO profiles based on some request value (host name, URI pattern, cookie value, etc.).

2. Create a single SSO profile for all - if, however, the web servers can all share a single service account and corresponding SPN, then you could create a single APM Kerberos SSO profile and use for all of the services.

It's also worth taking a moment to discuss the "SPN Pattern" option in the Kerberos SSO profile. By default, and without this setting defined, the APM Kerberos SSO profile "builds" the SPN dynamically by first performing a reverse DNS lookup of the load balanced IP address, then adding "http/" to the front, and "@REALM_NAME" to the end (the actual uppercase name of the domain realm) to create a SPN (ie. http/server1.domain.com@DOMAIN.COM). It uses this SPN to request a ticket for the downstream service. If, however, that name doesn't match the actual SPN (owner) of the web server, then this process would obviously fail. To get around this, the SPN Pattern field in the profile allows you to specify a static SPN value. Populating this field overrides the reverse DNS process and uses the specified string as the SPN for the ticket request. Now here's where it gets really interesting. That SPN Pattern field can take "wildcard" parameters. The %s wildcard will take the load balanced IP address and query the local Hosts file on the BIG-IP. You can use this option if a DNS lookup isn't going to return the correct SPN host name.

http/%s@DOMAIN.COM

The %h option takes the Host header from the request to generate the SPN (an admittedly less used option). What this means is that you could also, as a third option, create a single Kerberos SSO profile, and either use reverse DNS or the %s wildcard and Hosts entries to dynamically generate the SPN for the ticket request. The AD service delegation account that you create to bind to the APM Kerberos SSO profile can be configured to delegate to all of the web server SPNs.

Yes.... that is a current limitation of APM Kerberos SSO. It basically means that if all of your services are in a single domain realm, you can only have one Kerberos SSO profile and AD delegation account. If the services are in different realms, this shouldn't apply. The alternative is to create a single Kerberos SSO profile, and then use either reverse DNS or SPN patterns and %s wildcards to dynamically generate the SPNs to be used.

Cross-realm limitations don't apply as long as the delegation account (used by APM) is in the same realm as the target service. Cross-realm constrained delegation does, however, require the users to be in a transitively trusted realm.

The only other issue is that APM doesn't support cross-realm referrals. It's something that would happen if a user was in a different realm and the current realm sent a referral to that realm (or at least the next realm closest to this realm). So since APM doesn't understand referrals, you have to tell it which realm the user is in. That may be an LDAP query up front in the access policy, either nested queries or a single GC query. Once you know which the realm the user belongs to, you need to use the user's sAMAccountName in that realm as the SSO username source, and the user's realm realm name as the SSO domain source.

In a multi-domain configuration, you MUST use the user's sAMAccountName as the SSO username source, and the user's real domain as the SSO domain name source. APM Kerberos SSO doesn't support referrals, so users in domain1 work because no referrals are needed there. So for example:

session.sso.token.last.username = expr { "bob" }    <--- sAMAccountName
session.logon.last.domain = expr { "DOMAIN1.DOMAIN.COM" }

Are you switching between SSO profiles in the VPE? You don't need to do that if the delegation account and web service are in the same domain.

You also don't need the SSO credential mapping agent in a Kerberos SSO. You just need to populate the above SSO input variables.

Okay, just to be clear, the delegation account (used by APM) and the web service MUST be in the same domain. You don't need, and should not use multiple SSO profiles. You just need the one SSO profile.

If it still fails after removing the second SSO profile, take a tcpdump from the BIG-IP

 tcpdump -lnni [vlan between APM and KDC] -Xs0 -w [write to file.pcap]     

Or run a wireshark capture from the KDC directly and observe the Kerberos traffic. The error you see there will be more descriptive than the APM log.

I don't have my Kerberos testing lab up and running, so can't say specifically if that is an issue. The bad match error does indicate that the target KDC doesn't like something in the ticket though. I'd check the following things:

1. That transitive (two-way) trust is correctly established
2. That you're actually talking to the correct target domain KDC
3. That your delegation account is identified by a userPrincipalName and not a sAMAccountName. I didn't mention this earlier, but it's imperative that the Kerberos SSO delegation account is specified using a UPN format account@domain' versus 'domain\account' or simply 'account'.

We have a similar setup (users need to be authenticated to multiple back end applications), we are trying to do KCD but here is my confusion. We use lots of "easy to remember" aliases for sites not their computer names for users to access. For example - time recording site is "timekeeping.ourdomain.com" instead of the server name which is siteabbrfunctionnumber .int.ourdomain.com. So when reading about this in provisioning the service account and adding spns, I did select their computer names from AD and added to the account. However upon further reading, it would seem I need to set the spn's for the aliases as well, but cant do that through the gui so need to add them command line? Before I do that, this is the error I am getting:

Thanks in Advance

JdTokenRing,

Consider that the KDC stores encryption keys in its database based on the name of the services - its "principal name". When a client (or service) requests a ticket from the KDC, it must specify the correct principal name target, so that the KDC can retrieve the correct value. Since APM SSO is the delegate client in this scenario, it doesn't really matter what the DNS name is on the outside, as long as APM knows the real principal name. The APM Kerberos SSO config allows you a few ways to do that:

• With the SPN Pattern field left blank, SSO uses a reverse DNS lookup of the pool member IP. If DNS returns "siteabbrfunctionnumber.int.ourdomain.com" and "HTTP/siteabbrfunctionnumber.int.ourdomain.com@INT.OURDOMAIN.COM" is the correct SPN for this service, then that should be enough.
• If the service principal name is the same as the client-requested HTTP Host (which it isn't in your case), you can use the %h option in the SPN Pattern field. Example: "HTTP/%h@INT.OURDOMAIN.COM".
• If the service principal is something completely different, and unique per server, you can use a local Hosts entry on the F5 and the %s option in the SPN Pattern field. So for example, "HTTP/%s@INT.OURDOMAIN.COM", where %s resolves the pool member IP to an entry in the Hosts file.
• And if all services use the same principal name (because they use the same service account), you can simply type in a static SPN in the SPN Pattern field. Example, "HTTP/myservice.int.ourdomain.com@INT.OURDOMAIN.COM".

Most important though, the correct service principal name for the service isn't necessarily the name of the box. It depends on the account that owns the application service you're trying to authenticate to. If these are Windows servers, and the application service is owned by the machine account, the the SPN would indeed be based on the name of the box. If the application service is owned by a separate account, then the SPN for the service is that account's SPN.

Kevin,

Thanks so much! That explains alot! All of these services are running as the "App pool" I believe not a particular service account. However if we did this same practice to say Sharepoint which uses host names for site rendering and its running under a service account, is that where I would need to configure that account for delegation and add a SPN for it in particular? Is there a good Kerb reference you would recommend? I have a feeling this could get really complicated, and I do not want to unknowingly do something that would end up passing out "golden tickets" LOL! Many thanks for your help so far!!

John