kerberos and sharepoint

How do you have the Kerberos SSO configured?

Do you have the access policy configured for persistent session cookie?

Are your users inside the domain or external?

Yes, there's an access policy for persistent session cooike. Users are both internal and external. Below is the the config.

account-name host/f5sso.x.x.x.x.local account-password-encrypted kdc x.x.x.x realm x.x.x.x.LOCAL spn-pattern HTTP/lbtest username-source session.ldap.last.attr.sAMAccountName

apm aaa ldap /Common/aaa-eis-ldap { address x.x.x.x admin-dn cn=f5sso,cn=x,dc=x,dc=x,dc=x,dc=x,dc=local admin-encrypted-password use-pool disabled

So it looks like you're performing an LDAP query in the visual policy to get the sAMAccountName, and then using the SAM as the username source for the Kerberos SSO. So assuming the policy itself is always working, the next questions would be:

1. Does it behave this way for internal AND external users, or just one or the other?

    

2. When you say "prompt you to re-auth", are you talking about a dialog box for user/pass input?

    

3. If you set APM SSO logging to debug, do you see any Kerberos-related errors in /var/log/apm when the issue occurs? Do you ever see "S4U ==> OK!" in that log?

    

1. From what I understand it behaves the same for both.
2. Yes, a dialog box pops up.
3. How do you set the APM SSO logging to debug? That may point us to the source.

In the BIG-IP management GUI, go to System -> Logs -> Configuration -> Options. Toward the bottom of that screen under the "Access Policy Logging" section, set SSO to Debug. Remember to set this back to Notice when you're done troubleshooting.

These SSO logs will go to /var/log/apm

tail -f /var/log/apm

We had a troubleshooting session with Carlos Hernandez. He knows you Kevin. He said you're an iRule master! Basically, the Sharepoint (OWA) can't validate the user because auth is failing. It fails because the service account used with OWA is not the same account in the F5 SSO config. We saw this in the wireshark capture. Carlos can provide more details if needed. So will try to work out a solution with Microsoft since the OWA can't use any other account other than the one designated.

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.