Multiple apps doing kerberos

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.