kerberos and sharepoint

Maybe a little misinterpretation, but basically for Kerberos SSO to work in this environment you need THREE AD accounts:

1. The user's account (obviously)

2. The target service's account - this is OWA's account. It is the account bound to the web/OWA service and it must have a servicePrincipalName associated with it. If bound to the local machine then the SPN will likely be the HTTP/ SPN of the machine itself (ex. HTTP/owa-server1.myinternal-domain.com).

3. The APM Kerberos delegation account - this is a standard user account that has an arbitrary and unique servicePrincipalName applied to it (ex. HOST/krbsso.myinternal-domain.com). This is the account that APM will bind to for the purpose of performing Kerberos Protocol Transition and Constrained Delegation.

So basically APM uses this account to request an initial Kerberos ticket granting ticket (TGT) for itself (AS_REQ). Once it has the initial TGT, it then performs an S4U2Self TGS_REQ protocol transition request for itself on behalf of the user, and then performs a second TGS_REQ to to S4U2Proxy constrained delegation to the target service on behalf of the delegated user. If you look at a WireShark capture, you should see:

AS_REQ
AS_REP (probably at least 3 of these pairs)
TGS_REQ - S4U2Self
TGS_REP
TGS_REQ - S4U2Proxy
TGS_REP
AP_REQ - in the form of the HTTP request with the Authorization: Negotiate header and encoded Kerberos ticket

It fails because the service account used with OWA is not the same account in the F5 SSO config

Right, so there's essentially two modes the SSO can work with (actually 3 but I'll stick to the more important ones):

1. By default the SSO will take the load balanced server IP, perform a reverse DNS lookup to get the name, and then derive a server SPN from that host name. This is assuming the service is bound to the local machine and is how you load balance Kerberos.

2. If a reverse DNS lookup would not return the correct name/SPN, then you can short circuit this process with a static SPN in the "SPN Pattern" field of the SSO (ex. HTTP/owa-service.internal-domain.com). This tells the SSO the exact name of the target service without requiring the reverse DNS lookup. This method assumes that all of the target services (in the pool) are using the same service account and therefore the same SPN.