SharePoint 2007 with DoD CAC authentication

Carlos,

You can use this iRule, applied to the virtual server, and change the ID in the VPE to CERTPROC.

    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::policy agent_id] eq "CERTPROC" } {
    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 ">"]
    }
    }
}

I'm in the same boat we need to configure and Access Policy with DoD CAC auth

Mike, I used the APM module and was sitting on 11.2.0 when we did it. As far as doing it with 9.4.8 you would need to do it all in iRules and LTM. It is going to be a bit of a different struggle. What branch are you in? I can't see 9.4.8 getting past navy Stig requirements. Can you upgrade or is your big-ip a 2400 or lower?

Carlos, Are you using APM? Can you give me so insite into what you have provisioned on the BIP? Do you need to use PIV or the E-mail Cert of the CAC? AD backend? There is so much going on here that can be tweaked. If you just want to do OCSP revocaton based on CAC that is easy, if you want to marry an EDIPI up to an AD user and SSO Kerberos to the backend that is a different beast all together.

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.

1. For Account Name & password, I'm assuming that this credentials are for my local DC.

If you're talking about the AAA profile needed for the AD or LDAP query, then yes the user/pass is a domain account with privileges to perform the query.

 

1. The iRule all I get is ID field, See pic below. There is now way of entering the anything else.

You need to create a standard iRule that gets applied to the VIP. The iRule event agent in the visual policy will trigger the ACCESS_POLICY_AGENT_EVENT event. In this case the agent's ID value isn't important.