Sharepoint 2010 using Kerberos Authentication within the DMZ

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).