SharePoint 2007 with DoD CAC authentication

Carlos, can I assume by "Access Policy" you mean APM? Mike was asking about the old ACA module, which is both mostly deprecated and an entirely different configuration. Apologies Mike if you're still out there. Didn't see your post. 😉

If you're talking about APM, then you have a MUCH easier road than Mike had with ACA. To enable DoD smartcard-based authentication to SharePoint, here's one way to do it:

1. Create a standard access policy with the "secure" option selected.

2. Create an APM Kerberos SSO profile. The client is presenting a certificate to APM so there is no password and not many options other than Kerberos on the server side. I won't get into the specifics of the Kerberos SSO profile configuration here (plenty of that in other forum posts), but I do want to bring up one important characteristic of APM Kerberos as it relates to DoD CAC. The SubjectAltName userPrincipalName in a DoD CAC is going to be a 10-digit number and an arbitrary realm name (@mil). This realm name won't match the realm of your (or any) Windows domain, and while you can (and will have to) establish an alternate UPN suffix in the domain for the "mil" realm, APM Kerberos doesn't provide what's referred to as Enterprise Cross-Domain Referrals. This is like a CNAME for Kerberos where the client presents a request to a KDC with a user@realm value that doesn't match the local domain. That KDC will look to the global catalog for this alternate realm, and then send the user a referral to go to the real realm. Even with a single domain, this process is required for the domain to accept the alternate realm (except for PKINIT which will accept it). In any case, because referrals aren't supported, you basically must perform a quick AD or LDAP query (LDAP is faster) to find the user's sAMAccountName in the domain from the UPN value. That value, the sAMAccountName, will be sent to the Kerberos SSO profile as the username session variable.

3. In the visual policy, start with an On-Demand Cert Auth agent set to "Require".

4. After the successful branch of the above, create an iRule event agent to extract the UPN from the cert and prepare it for the upcoming LDAP query. You can do this in VPE script as well, but I tend to prefer the iRule for its simplicity.

   when ACCESS_POLICY_COMPLETED {
       ACCESS::session data set session.logon.last.username [ACCESS::session data get "session.ldap.last.attr.sAMAccountName"]
   }
   when ACCESS_POLICY_AGENT_EVENT {
       if { [ACCESS::session data get session.ssl.cert.x509extension] contains "othername:UPN<" } {
           ACCESS::session data set session.custom.upn [findstr [ACCESS::session data get session.ssl.cert.x509extension] "othername:UPN<" 14 ">"]
       }
   }
   

5. With the UPN extracted from the certificate and staged for the LDAP query, insert an LDAP query agent. The SearchDN will be the DN path that the users can be found, and the SearchFilter will look like this:

   userPrincipalName=%{session.custom.upn}
   

   You can optionally add required attributes at the bottom of the query to make it return less data. In this case you'd add "sAMAccountName". Also change the LDAP query's branch rule expression to "LDAP Query" and "LDAP Query Passed".

6. With the returned sAMAccountName, the iRule will embed that value into the session variable that Kerberos SSO needs for the username. At this point, if LDAP is successful, end with an allow block. Kerberos SSO will take over from there.

7. Create a standard HTTPS VIP to hold this access policy, the pool, SNAT as requred, an HTTP profile, and a client SSL profile. The client SSL profile's client certificate authentication option should be set to "Ignore", but you will need a bundle of DoD CA certs in the Trusted Certificate Authorities option to validate the incoming client certificate.