For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Kevin_Stewart's avatar
Kevin_Stewart
Icon for Employee rankEmployee
Feb 28, 2014

I do have a Kerberos SSO profile applied to the policy (which doesn't seem to be doing anything) but I use a Kerberos AAA profile in the access policy. I'm guessing this is the main point where I'm going wrong.

I see. The Kerberos AAA, Kerberos Auth agent, and 401 agent are for client side Kerberos, where the client can retrieve its own Kerberos ticket from a local KDC. I'm assuming that's not your intention. Server side Kerberos is controlled via the Kerberos SSO profile applied to the access policy.

Is Citrix XML broker IIS integration a requirement for CAC authentication? I don't remember seeing that anywhere. It's easy enough to setup and there isn't any reason I can't go that way.

It's sadly not documented anywhere (publicly) that I know of, but in order to authenticate to an XML broker with anything other than user/pass, you need to enable IIS-integration.

So, if I understand what needs to happen: I need to drop the client side (401 response) method and request a certificate from the user. Then take that cert's SAN and map it to the user's UPN in AD using a Kerberos SSO policy? Am I thinking correctly on this?

Sort of. Here's a play-by-play of how it would work:

  1. APM configured with On-Demand Cert Auth agent to collect the client certificate (you could also skip this and request the cert in the client SSL profile).

  2. APM then extracts the UPN from the cert. The easiest way to do this is with an iRule agent in the VPE (right after ODCA):

  3. Because you're using a (DoD) CAC, the UPN in the cert(s) will not match the UPN in the AD. To complicate that further, because APM is not officially a member of the Windows domain, it cannot participate in the Enterprise Canonical Naming mechanism that AD uses when an AD client uses an alternate UPN suffix. It's like a CNAME for Kerberos that tells the client/server which domain the user belongs to based on a GC query. In other words, the UPN on the cert is EDIPI@mil, and even though you've established "mil" as an alternate UPN suffix in the AD domain, APM will not follow the redirect. To get around this behavior, you use a rather simple trick of performing a quick LDAP or AD query (LDAP is faster) with the cert UPN to fetch the user's sAMAccountName. 

    LDAP SearchFilter: userPrincipalName=%{session.cert.upn}

  4. You then apply the SAM value as the username source in your Kerberos SSO profile, and then apply the Kerberos SSO profile to the Citrix remote desktop config. Assuming all of the other Kerberos stuff is configured correctly, this is how you authenticate to the XML broker.

    Kerberos SSO Username Source: session.ldap.last.attr.sAMAccountName

  5. Apply all of the settings from my previous post and you should be good to go. If you run into Kerberos issues, we can address those afterwards.