Configuring Smart Card Authentication and Kerberos Constrained Delegation in F5 Access Policy Manager (APM)

In previous articles, we have discussed the use of F5 BIG-IP as a SSL VPN and then followed up by adding endpoint security to the same Access Profile configuration we used for VPN access. I now wanted to take some time to discuss a use case that is certainly near and dear to those in the DoD and Federal government but is also being implemented more and more within the private sector. Prior to getting into the configuration of this use case, I wanted to clarify a few things. This solution is not meant to replace Windows Integrated Authentication or any type of certificate authority function but is rather used when the BIG-IP is configured as a reverse or to support those applications that do not support client certificate authentication.

As mentioned above describes the configuration of a full Webtop to establish full network access and then added which described adding endpoint security. Below are screenshots of what the APM VPE configuration looked like when configuring forms based authentication. In this example, I will be configuring access to Microsoft Outlook Web App using client certificate authentication and Kerberos Constrained Delegation (KCD).

If you have followed with us during the last few articles you would have already met the following prerequisites. If you have not, make sure these are done before you get started as these are outside the scope of this article.

  • Local Traffic Manager licensed and provisioned
  • Access Policy Manager licensed and provisioned
  • CA certificate or a bundle of CA certs
  • OCSP IP address for certificate revocation checking
  • Functional DNS infrastructure with DNS servers defined on the BIG-IP
  • Accessible NTP source and configured on the BIG-IP

Now let's get started with configuring our Exchange 2016 instance for certificate authentication for users outside of the network but are members of the demo.lab domain. We will be using F5 documentation for enabling Kerberos Constrained Delegation (KCD) found at the link below.

Configuring Kerberos Constrained Delegation

Before we get started with our Kerberos Constrained Delegation configuration, I wanted to identify the most common issues I have experienced in the field.

  1. Missing or incorrect reverse (ptr) records.
  2. Missing or incorrect settings for the delegation account within Active Directory.
  3. Time skew

To create the APM delegation account from the UI follow the following steps provided directly from F5's Kerberos Constrained Delegation deployment guide.

  • From the Windows Domain controller, from the Administrative Tools menu or the Run prompt, open Active Directory Users and Computers.

To create a new user, use the steps below.

  • In the left navigation pane, right-click Users, and then from the New menu, click User.

In the First and Last name boxes, type the appropriate names.

  • In the User logon name field, type host/ and then a unique name. The user logon name must begin with host/. In this case, host is a literal string that later matches the Type of Service in Service Principal Name (SPN). The name is any name that needs to be matched while configuring APM SSO object, and the domain is the DNS FQDN for the realm containing your web resources to be accessed. The domain for the Sever can be found either from System Properties, or by running the set command from the command prompt.

  • Click Next.
  • Type and confirm the password, and then uncheck User must change password at next logon. Check the boxes for User cannot change password and password never expires.

  • Review the information and then click Finish.
  • In either the left pane or the main pane, right-click the user you just created (or the existing user) and then click Properties.
  • Ensure the User logon name is correct, including the host/ prefix.
  • In the Account options area, ensure the boxes for User cannot change password and Password never expires are checked.
  • In the Account expires area, make sure Never is selected.
  • Click OK.

Modifying the account to be trusted for delegation

To configure the account created in previous steps to support delegation, follow these steps. I will be using the Attribute Editor within the DSA console rather than using setspn or ADSIEdit. You must enable Advanced Features to view this tab.

  • In the left navigation pane, select the Users OU, and locate the user account created in the previous steps, right-click and select Properties.
  • If the Advanced Features have been enabled, you will find a tab called Attribute Editor. Select that tab.
  • Scroll until you find servicePrincipalName and select Edit.

  • As shown below, in the Value to add field, type the user logon name of the delegation account you created and select Add.

Configuring Trust for the Active Directory user

  • From the Windows Domain controller, from the Administrative Tools menu, open Active Directory Users and Computers.
  • Right-click the user account you created.
  • Click the Delegation tab.
  • Click Trust this user for delegation to specified services only. This enables Kerberos constrained delegation.
  • Under Trust this user for delegation to specified services only, click Use any authentication protocol. This enables Kerberos protocol transition on the server-side.

  • In the Services to which this account can present delegated credentials area, click the Add button to add services to the list.
  • From the Add Services dialog box, click Users or Computers.
  • From the Select Users or Computers dialog, in the Enter the object names to select field, type the computer/server where the desired Web service is running. You can add multiple devices separated by a semi-colon. Click Check Names.

  • Click the OK button.
  • From the Available Services area, select the service(s) you want to delegate to this account.
  • Click the OK button on each of the dialog boxes to exit.

This concludes the configuration of the APM Delegation Account.

Note: For KCD to work correctly, the application such as OWA in this instance must already be configured to support Kerberos. Enabling Exchange OWA to support Kerberos is outside the scope of this article.

Configuring the BIG-IP APM for Kerberos Delegation Authentication

Now that we have configured an active directory account to support delegation we will begin the Kerberos configuration on the BIG-IP. To start we will create an SSO configuration using the configuration items below. If not defined below, leave the default setting.

  • Navigate to Access > Single Sign-On > Kerberos > Create
  • Name: KCD_SSO_Profile
  • Username Source: session.ldap.last.attr.sAMAccountName
  • Kerberos Realm: "DEMO.LAB" in all uppercase
  • KDC: demo-dc.demo.lab

Note: Defining a KDC is not a requirement as DNS will most often identify the appropriate KDC. However, I will configure it in this demo.

  • Account Name: host/kcd.demo.lab
  • Account Password: Password
  • Confirm Account Password: Repeat Password
  • Click Finish

Note: In order to support AES Kerberos Encryption, the account name must be in SPN format as shown in the screenshot above.  If it is not, you will receive the following error.

"Kerberos: can't decrypt S4U2Self ticket for user 12345679@SITEREQUEST.COM - Decrypt integrity check failed (-1765328353)."

Configuring a LDAP AAA Resource

  • Navigate to Access > Authentication > LDAP and select Create
  • Name: Demo_LDAP_AAA
  • Server Connection: Direct
  • Base Port: 389
  • Admin DN: CN=admin,CN=Users,DC=demo,DC=lab
  • Leave all other settings at their defaults and select Finished

Configuring a OCSP AAA Resource

  • Navigate to Access > Authentication > OCSP Responder > Select Create
  • Name: Demo_OCSP
  • URL: http://OCSP_IP/ocsp
  • Certificate Authority File: Select the issuing CA Certificate
  • Leave all other settings at their defaults and select Finished

Create Client Cert Access Policy

  • Navigate to Access > Profiles / Policies > Select Create
  • Name: Demo_cert_Auth
  • Profile Type: All
  • Profile Scope: Profile
  • SSO Configuration: Select the previously created KCD_SSO_Profile
  • Languages: Select your desired language and move it to Accepted Languages
  • Leave all other settings at their defaults and select Finished

Modify the Access Policy Using the Visual Policy Editor
  • From the Access > Profiles > Policies : Access Profiles (Per-Session Policies) page, select Edit from the access policy created in the previous step.

  • Between Start and Deny select the +
  • From the popup select the Authentication tab and select On_Demand Cert Auth > Add Item

  • You will be presented with an option to request or require a client present a client certificate. For this example, we will Require the client present a certificate.
  • Select Save

  • Following the successful branch of ODCA in the VPE, select +
  • From the Authentication tab, select OCSP Auth > Add Item
  • From the OCSP Responder drop down, select the OCSP AAA object created in previous steps.
  • Certificate Type: User
  • Click Save

  • Following the successful branch of OCSP Auth, select +
  • From the Assignment tab, select Variable Assign > Add Item

  • From the first empty Assignment, select Change
  • Custom Variable: session.logon.last.domain
  • Custom Expression: expr {"demo.lab"}
  • Select Finished

  • Under Variable Assign, select Add new entry > Change empty variable
  • Custom Variable: session.logon.last.upn
  • Custom Expression: set x509e_fields [split [mcget {session.ssl.cert.x509extension}] "\n"];

# For each element in the list:

foreach field $x509e_fields {

# If the element contains UPN:

if { $field contains "othername:UPN" } {

## set start of UPN variable

set start [expr {[string first "<" $field] +1}]

# UPN format is

# Return the UPN, by finding the index of opening and closing brackets, then use string range to get everything between.

return [string range $field $start [expr { [string first ">" $field $start] - 1 } ] ]; } }

# Otherwise return UPN Not Found:

return "UPN-NOT-FOUND";

  • Select Finished > Save

  • Select Save

  • Following the fallback branch of Variable Assign, select +
  • From the Authentication tab, select LDAP Query > Add Item

  • From the Server drop down, select the LDAP AAA created in previous steps
  • SearchDN: CN=Users,DC=demo,DC=lab
  • SearchFilter: UserPrincipalName=%{session.logon.last.upn}
  • Required Attributes: sAMAccountName

  • Navigate to the Branch Rules tab
  • Remove the existing Group Membership expression by selecting the X
  • Select Add Branch Rule
  • Name: LDAP Query Successful
  • Next to expression, select change
  • Agent Sel: LDAP Query
  • Condition: LDAP Query Passed
  • LDAP Query has: Passed
  • Select Add Expression > Finished

  • Click Save

  • Following the LDAP Query Successful branch, select +
  • From the Assignment tab, select SSO Credential Mapping > Add Item
  • SSO Token Username: sAMAccountName from LDAP Directory

  • Click Save
  • From the fallback branch, select Deny
  • Change ending to Allow and click Save

At this point, you have a fully deployed VPE capable of supporting smart card authentication.

  • Select Apply Policy

Note: There is so much more we can do here from pre-authentication checks for AV, firewall, redirect users versus allow and deny, etc. though these items are outside the scope of this article. I will attempt to identify these capabilities in future articles

Configure SSL Client Profile

  • To support client certificate-based authentication, we must also create a Client SSL Profile on the BIG-IP using the steps below.
  • Navigate to Local Traffic > Profiles > SSL > Client > Create
  • Name: DemoSSLProfile
  • Certificate Key Chain: Place a check mark under the custom field. Click Add to select the appropriate cert/key pair.

  • Client Certificate: Leave it set to ignore as the APM ODCA will perform this function.
  • Trusted Certificate Authorities: Select the CA or CA bundle certificate
  • Advertised Certificate Authorities: Select the CA or CA bundle certificate

  • All other settings can be left at their defaults.
  • Click Finished

Assign the Client SSL Profile and Access Policy to a Virtual Server

  • Navigate to Local Traffic > Virtual Servers
  • Select appropriate web server VS
  • Scroll until you locate SSL profile (Client) and assign the SSL profile created in the previous step.

  • Scroll until you locate Access Profile and assign the APM policy created in previous steps.

  • Click Update

Begin Testing and Validation

At this point, we have successfully configured a delegation account in Active Directory, configured APM to support smart card authentication as well as configure our OWA virtual server to support client-side certificate authentication requests with the configuration of the client-side SSL profile.

This article more than anything was meant to provide visuals of an actual client certificate authentication implementation. While there are several other methods not included in this document such as the implementation of iRules for certain functions, this is what works best for me. Future articles will include troubleshooting methods for cert based authentication and KCD. I hope this helps. Until next time!

Published Jul 10, 2018
Version 1.0

Was this article helpful?


  • Steve,


    Question on the SSO Credential Mapping. I see that you specified "sAMAccountName from LDAP Directory" as the SSO Token Username, but left the SSO Token Password as "Password from Logon Page". How does this work with a DoD Common Acces Card (CAC) smartcard?


    Without going on for too long, I need to get external users (reverse proxy) to actually authenticate against AD or LDAP and have their "lastLogonTimestamp" attribute get updated with their successful access to our SharePoint site.


    Will the SSO Credential Mapping work with LDAP or AD, and will this trigger an update to this AD attribute?


    My setup looks nearly identical to your above setup except that I have "AD Query" with the same lookup (userPrincipalName=%{session.logon.last.upn}), and no SSO Credential Mapping.


    We have found that the AD Query (or LDAP Query) alone is not updating the "lastLogonTimestamp" attribute which is a problem, as we disable accounts after a certain amount of time since the last "lastLogonTimestamp".


    Any insight that you could provide would be appreciated.


  • Hi Joe! No need to be concerned about the "Password from Logon Page" and to be honest the credentials that are going to be used are obtained from the Kerberos SSO profile. Below is a screenshot of my current vpe supporting smart card/certificate based authentication.



    From there we need to validate what we are using in our Kerberos SSO profile is actually being obtained.



    Enable Debug logging and you can see all of the session variables and if any you are expecting that maybe were not populated.



    Then after successfully authenticating using KCD they yes after validation the "lastLogonTimestamp" is updated.



    I only support the DoD and intel agencies so this is what I do on a fairly common basis. If you need any help at all please do not hesitate to reach out. Hope this helps!


  • Honestly, I don't know that it really matters. There was some password reset limitations of using the LDAP query versus AD but I don't remember off the top of my head. However, in your case, this wouldn't be an issue unless you had a branch for users that didn't have a CAC that were still using UN/PW. The thing to remember is that the variable is going to change.


    If you use LDAP you will use something like session.ldap.last.attr.sAMAccountName versus using AD will result in


  • Roger that. It appears to have worked with AD Query, but when I looked into my AD account the attribute that got updated was the "lastLogon" and not the "lastLogonTimestamp". Granted I am not sure if there is a process in the DC that updated the "lastLogonTimestamp" with the "lastLogon" info after a period of time. I'll have to check that out later.


    Thanks again for your assistance!


  • No worries Joe. I will say that is an interesting observation though. Using LDAP I see only lastLogonTimestamp being updated and not the lastlogon. If I find the time, I may try modifying my VPE to reflect AD query vs LDAP to see the results in AD as far as time stamps.


  • Steve,


    So, after some digging, I have found a few things:


    1) As you stated, using AD Query or LDAP Query should work either way, BUT since my Kerberos SSO config is set to "" I must use the "sAMAccountName form Active Directory" in the SSO Credential Mapping


    2) I still do not see an update to the AD "lastLogon" attribute though. It gets updated when I unlock my workstation with my Token card and PIN, but not when I access a VS with associated Access Policy.


    I am at a loss how to get this AD attribute to update, but I will keep trying.


    On a side note, after researching the "lastLogon" and "lastLogonTimestamp" it appears as though the former is specific to each DC. Meaning that whichever DC processed the logon the "lastLogon" attribute is then updated on that DC ONLY (not replicated). If the DC that processed the logon has a "lastLogonTimestamp" that is greater than 14 days of the newly processed "lastLogon" then the "lastLogonTimestamp" of that DC will get updated with the "lastLogon" date/time, and then that "lastLogonTimestamp" get replicated across all the DC's.


    I'm not sure where I go from here, but if you have any insight let me know. Thanks again!