Sharepoint 2010 using Kerberos Authentication within the DMZ

This thread may be useful to you:

https://devcentral.f5.com/questions/kerberos-and-ntlm-authentication-using-apm

And a few thoughts:

1. The visual policy is going to strictly involve client side authentication.

    

2. This is where you're performing client side Kerberos auth to the APM VIP, so you need at a minimum a 401 agent and a Kerberos Auth agent.

    

3. The 401 agent is going to send a 401 response to the user in the absence of a valid session token in the request.

    

4. The 401 agent can be configured to send a Basic, Negotiate (NTLM and Kerberos), or both types of responses. This translates into an Authorization header in the 401 response and a keyword that tells the browser how to authenticate the user. I'm guessing you JUST want to do Kerberos, so you can probably remove the Basic options from the agent.

    

5. The client will see this Authorization header and, if capable, attempt to request a Kerberos ticket for the resource. By "if capable", I mean that the client must 1) be a member of a domain, and 2) trust this site enough to send it Kerberos tickets. In IE that usually means adding the URL to the "Local intranet" sites list.

    

6. The keytab that you use in the AAA must be exported from the account that you created in the user's domain. When a client requests a Kerberos ticket, it does so by service principal name (SPN) and TGT (ticket granting ticket - a ticket that tells the KDC that the client has already authenticated itself). The KDC generates a session ticket, encrypts it with the service's encryption key, then encrypts it again with the client's encryption key. The client unwraps this outer "shell" with its encryption key then sends the rest to the server. The server then decrypts the remaining data with its encryption key to expose the ticket. So the keytab in the AAA is basically the encryption key needed to decrypt and expose a Kerberos ticket, and it must be the SAME key used by the KDC to encrypt the data in the first place.

    

7. From your original post, you probably don't need the Logon page, nor the SSO Credential Mapping agent. Client side Kerberos auth is handled exclusively through the 401 and Kerberos Auth agents.

    

8. Once successfully authenticated on the client side, the Kerberos Auth agent exposes a single session.logon.last.username session variable that contains the user's userPrincipalName (name@domain). If you then need to do server side SSO with an APM SSO profile, you're limited to what you can actually do based on what you have to work with - a username and domain. Since this is SharePoint, your options are basically user/pass and Kerberos. User/pass SSO would require you to collect these values on the client side. Kerberos SSO would be your next, and probably most viable option. Please refer to the forum thread above for more information on setting up Kerberos SSO.