LTM 11.3 with APM: smart card authentication not working

First thing to understand is that there's a significant departure from how you configure Netscaler here and how you use APM with a webtop to remove those components. The Kerberos pieces in WI are implicit and not something that you have to mess with. With the APM webtop approach though, you actually have to configure the Kerberos. The linchpin in this process, when dealing with DoD CACS, is that the realm in the SAN UPN on the card (@mil) is never going to match the realm of your AD domain name. Canonical referrals is an extension to Kerberos that is often seen in Exchange environments. You have multiple domains that a user can belong to (ex. dom1.example.com, dom2.example.com, dom3.example.com), but all users use an alias email address (bob.user@example.com). For email that's usually just the mail value in the user's attributes. For desktop smartcard logon, you have to apply an alternate UPN suffix to the domain to allow the @mil UPN realm. When a Kerberos client/service needs to authenticate itself, or a delegated user to the forest, the alias name doesn't map to anything, so the service will make a canonical enterprise referral request to its local KDC with the principal name. The local KDC will then query, either locally or via the global catalog, where that user really exists, and then return a referral to the correct realm for the client to follow. Sort of like a DNS CNAME for Kerberos. APM, as of 11.5, still doesn't support this extension, so you have to perform the query yourself and specify the real realm in the ticket request. And because the UPN realm doesn't match the real realm, the request would confuse the KDC. Luckily, a Windows DC can consume a few different forms of the user identity, so we'll use the cert UPN to make an LDAP query into the cd and fetch the user's sAMAccountName. We'll then use that returned SAM as the username source input to the Kerberos ticket request.

1. Set up an LDAP AAA.
2. Prompt the user for their certificate (On-Demand cert auth agent in the APM VPE or client SSL profile).
3. Use an iRule or branch rule in the VPE to extract the SAN UPN from the x509 extensions section of the cert and assign it to a variable (ex. session.ssl.cert.upn).

4. Prepare your LDAP query to search the AD for the userPrincipalName:

   userPrincipalName=%{session.ssl.cert.upn}        
   

5. Set the branch condition of that LDAP query to something reasonable. Could be as simple as an LDAP query passed result.

6. If the query succeeds, there should be a value returned for the SAM:

   session.ldap.last.attr.sAMAccountName        
   

7. You can use that session variable directly inside the username source value of the Kerberos SSO profile.

The UPN in th AD must of course match this value, so you'll need to set the @mil alternate UPN suffix, or potentially query another value in the AD to return the correct SAM.

Now, if you have multiple domains, you can perform cross-domain authentication as long as:

1. APM can directly resolve and communicate with the KDCs of each
2. There is a two-way trust between the domains. Kerberos protocol transition requires it.
3. The AD delegation account that you define in the Kerberos SSO is in the SAME domain as the resource (the XenApp servers). Kerberos constrained delegation requires this.
4. You can figure out and specify which domain the user actually belongs to. If this a forest trust, then you should be able to LDAP query the global catalog directly. Otherwise you have to query each domain successive to find the user. I'm hoping canonical referral support will come along soon to alleviate this process. Once you know which domain the user is from, assign that to the realm source variable in the Kerberos SSO (ie. session.logon.last.domain), and of course also assign the sAMAccountName to the username source variable.