Forum Discussion

Dev_56330's avatar
Dev_56330
Icon for Cirrus rankCirrus
Dec 03, 2015

Using Certificate Subject Name To Authenticate Users

Quick question in regards to using a certificate attribute to authenticate a user. Users have been issued a soft cert with a subject name that represents the users CN. The F5 compares the subject name to the OU to see if there is a user that matches the cert in the user ad object under user mappings. If this matches then the F5 will authenticate the user to the specified website. The problem is the F5 identifies the Subject Name in reverse order than Windows and will not authenticate the user. F5 = CN= OU= OU= OU= OU= DC= Windows alt security identities (user mappings) it reads: DC= OU= OU= OU= OU= CN= Because of this format change F5 will not authenticate the user. Is there a way to have the F5 change the output to the windows format?

 

3 Replies

  • You can use FindStr in order to pull out the specific value that you want to compare to whichever AD/LDAP attribute works best for your environment, predominantly userPrincipalName or sAMAccountName.

    https://devcentral.f5.com/wiki/iRules.findstr.ashx

    For example:

    if { [ACCESS::session data get session.ssl.cert.x509extension] contains "CN:" } {                
      set tmpupn [findstr [ACCESS::session data get session.ssl.cert.x509extension] 
        "CN:" [Arbitrary number of characters] ""]                
      ACCESS::session data set session.custom.certcn $tmpcn                    
    log local0. "Extracted OtherName Field: $tmpcn"            
    }
    

    You would then use the %{session.custom.certcn} in an LDAP/AD query to validate the user.

  • The thought from a fellow F5 administrator is that the Big IP is still unable to properly present a certificates SN which should have been resolved in BIGIP-9.3.0 per the notes in the article below. I personally cannot replicate this issue and I don't even know that I fully understand what or how he is attempting this type of authentication though he describes the issue just as it states in the article where the order of the Subject Name is reversed. Note There is a behavior change since BIGIP-9.3.0 for this command to support multiple languages and RFC 2253 compliance. Before the change 1 /CN=Name/OU=UNIT/O=ORG/C=US After the change 1 C=US,O=ORG,OU=UNIT,CN=NAME https://clouddocs.f5.com/api/irules/X509__issuer.html
  • Looking at using the same concept listed above to authenticate the user against user mappings via certificate subject and issuer comparison. i too get the same error listed above when utilizing the same irule.