Multiple apps doing kerberos

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.