Sharepoint 2010 using Kerberos Authentication within the DMZ

Did you add your BIG-IP to your domain ?

I suggest you to follow this, you'll find everything you need Kerberos Authentication

Would I need to do this on the LTM or should I be getting the group who look after the Domain Controller to run these commands within AD?

Joining a domain To use Kerberos authentication, you need the client joined and connected to a domain and you need a keytab file. 1.Create a surrogate user in the domain. In this example, the hostname of the virtual server on the BIG-IP system is testbed.lab.companynet and the user name is john. setspn -U -A HTTP/testbed.lab.companynet john 2.Map the user account to the service account and generate a keytab file for the service. You can use the ktpass utility to do this. In this example, LAB.COMPANYNET specifies the Kerberos authentication realm. c:>ktpass -princ HTTP/testbed.lab.companynet.com@LAB.COMPANYNET -mapuser john@LAB.COMPANYNET -crypto rc4-hmac-nt -ptype KRB5_NT_SRV_HST -pass password -out c:\temp\john.keytab

You have to do this on your Domain Controller.

Within the document you mentioned, the basic-kerberos-auth policy is confusing me. It shows the username and password as options within the HTTP 401 Response box under Logon Page Agent and I am not seeing that.

I only see a Basic Auth Realm as an option (LABDMZ.DOMAIN.COM)

and HTTP Auth Level (Negotiate) as another.

It looks like a combination of the Login Page and HTTP 401 Response. Is that possible?

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.

    

Oddly, the image above looks like a cross between a logon page and a 401 response agent. I can't say I've seen, or remember seeing anything like this in APM, and guessing this might have been an early version. What you have in your last post is to be expected in a 401 response agent.

I'm wondering if I'm barking up the wrong tree here.

Within this document http://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-aaa-auth-config-11-3-0/3.html it mentions that the client becomes a member and connects to the domain. I'm not sure we want this in our setup.

Here is what we are trying to do...

An external contractor who's not on our domain browses to our external sharepoint site. (https://sharepoint-vip.domain.com) and enters their username, SecurID token code and domain credentials. From here we want the client to pass through directly to Sharepoint IIS Servers via SSO on the back end.

I'm wondering if my testing is not working because the test machine is not a member of the LABDMZ.DOMAIN.COM domain.

Okay, for client side Kerberos authentication, the client authenticating to the front of the APM VIP, the client 1) must be a member of a domain, 2) must be in the same domain that you've extracted the keytab from for the AAA, and 3) must be able to request a Kerberos ticket from its local KDC (domain controller).

Server side Kerberos (called "SSO"), the APM VIP authenticating to the web server, you need 1) an AD user account for delegation, 2) this account configured in the Kerberos SSO profile, and 3) valid domain username and domain session values to send to the Kerberos SSO.

The real beauty of this authentication proxy is that the client side and server side are completely separate processes. It makes thinks like smart card authentication to SharePoint (where you don't have a password and even when the cert username doesn't exactly match the domain username) incredibly easy. So to your point, I think you have a few options depending on what it is the client is submitting for authentication.

1. You mention domain credentials in your last post, but started the thread by saying that there would be different domains. If the credentials (username and password) that the client is presenting is the same as that of the domain that SharePoint lives in, then you could do a logon page on the client side with username, password, and SecurID token, validate that user by some pre-authentication process (AD/LDAP auth or query, etc.), and then do form-based SSO into SharePoint with the provided username and password.

    

2. If the credentials provided are truly from a different, non-trusted domain, the you could do a logon page on the client side with username, password, and SecurID token, validate that user by some pre-authentication process, and then do Kerberos SSO into SharePoint (given a common username value or something else that matches between the two domains).