APM ClientCert to Kerberos Transition - parsing SubjectAlternateName in Variable assign

This is what I typically do.

1. iRule event agent in the visual policy directly after the On-Demand Cert Auth agent.
2. Add this iRule to the VIP:

when ACCESS_POLICY_AGENT_EVENT {
    if { [ACCESS::session data get session.ssl.cert.x509extension] contains "othername:UPN<" } {
        ACCESS::session data set session.logon.last.username [lindex [split [findstr [ACCESS::session data get session.ssl.cert.x509extension] "othername:UPN<" 14 ">"] "@"] 0]
        ACCESS::session data set session.logon.last.domain [lindex [split [findstr [ACCESS::session data get session.ssl.cert.x509extension] "othername:UPN<" 14 ">"] "@"] 1]
    }
}

The UPN will usually be in user@domain form, so I split on the "@" sign and assign session.logon.last.username to the first half and session.logon.last.domain to the last.half. The session variables created here are the ones you have identified in the Kerberos SSO profile.

This also assumes that the cert UPN is the same as the domain UPN. This may be true for you, because it isn't always the case; and because APM doesn't (yet) support enterprise canonical cross-realm referrals, I'll typically save the UPN to a temporary session variable first, perform an LDAP query to get the sAMAccountName from AD, and then use that (and the realm domain realm) in the two Kerberos SSO profile session variables.

 

I should also add that you can technically do all of this directly in the VPE, but I like the iRule version because I believe it's easier to manage.

 

Dear Kevin,

many thanks for the answer. I had to split the UPN into username and UPN-suffix for RSA/LDAP, because it doesn't match the REALM. I retrieve it by performing a LDAP Query with the full UPN, because we have three AD Tree's with up to 40 Childdomains. The REALM is then retrieved from the DistinguishedName by some string operation in a Variable Assign: build REALM from Distinguishedname ( I think I will add a toupper):

expr { [string map -nocase {,dc= .} [string range [mcget {session.ldap.last.attr.distinguishedName}] [expr [string first ",DC=" [mcget {session.ldap.last.attr.distinguishedName}] 0] +4] end ] ]}

 

 

remove UPN from session.logon.last.username

expr { [string range [mcget {session.logon.last.username}] 0 [expr [string first "@" [mcget {session.logon.last.username}] 0] -1] ] }

 

 

Cheers JP

 

Hi Guys,

just came up with a nasty thing Microsoft throws at us 😄 It looks like the Kerberos Client Principal is build by sAMAccountName@REALM. I stumbled across this, while adding another division to my Virtual Server, which uses different values in the UPN and sAMAccountName field (e.g.: UPN = first.last@maildomain vs. sAMAccountName=last). Couldn't find a reference at Microsoft, but at least it's working with the following variable assignment (the ldap.attr.Name is case sensitive - gave me some headache too):

expr { [mcget {session.ldap.last.attr.sAMAccountName}] }

 

extracting the REALM from the DN remains the same:

expr { [string toupper [string map -nocase {,dc= .} [string range [mcget {session.ldap.last.attr.distinguishedName}] [expr [string first ",DC=" [mcget {session.ldap.last.attr.distinguishedName}] 0] +4] end ] ] ]}

 

Cheers JP

 

It looks like the Kerberos Client Principal is build by sAMAccountName@REALM

 

I think it's safer to say that Windows will accept both userPrincipalName AND sAMAccountName for identity assertion. Either can usually be in name@domain or domain\name format.

 

You can achieve the same result with a Variable Assign action in the Access Policy configured with the following values:

 

session.logon.last.domain = expr { [lindex [split [mcget {session_variable_with_user@domain}] "@"] 1] }

 

session.logon.last.username = expr { [lindex [split [mcget {session_variable_with_user@domain}] "@"] 0] }

 

In my case I wanted to populate the Username and Domain session variables from the "session.saml.last.identity" session variable which is created on the APM SAML SP after completing IdP authentication. The above syntaxes in a Variable Assign populated the Username and Domain session variables with the desired information.

 

• Jason