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 https://devcentral.f5.com/s/articles/creating-a-ssl-vpn-using-f5-full-webtop-30146 describes the configuration of a full Webtop to establish full network access and then added https://www.linkedin.com/pulse/configuring-endpoint-security-client-side-stephen-lyons/?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_post_details%3BAQH0s5%2BNRiqaYPuF5aR70g%3D%3D 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.
https://www.f5.com/pdf/deployment-guides/kerberos-constrained-delegation-dg.pdf
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.
- Missing or incorrect reverse (ptr) records.
- Missing or incorrect settings for the delegation account within Active Directory.
- 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!
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!