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

**URL:** <https://community.f5.com/t/configuring-smart-card-authentication-and-kerberos-constrained-delegation-in-f5-access-policy-manager-apm/67914>\
**Category:** F5 Technical Articles\
**Tags:** big-ip-access-policy-manager-apm, security, application-delivery\
**Created:** [July 10, 2018, 11:06am UTC](https://community.f5.com/t/configuring-smart-card-authentication-and-kerberos-constrained-delegation-in-f5-access-policy-manager-apm/67914 "2018-07-10T11:06:00Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Steve\_Lyons](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/steve_lyons/32/15373_2.png) [@Steve\_Lyons](https://community.f5.com/u/Steve_Lyons)\
**Post date:** [July 10, 2018, 11:06am UTC](https://community.f5.com/t/configuring-smart-card-authentication-and-kerberos-constrained-delegation-in-f5-access-policy-manager-apm/67914/1 "2018-07-10T11:06:00Z")

</div>

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](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 [Top Content on LinkedIn](https://www.linkedin.com/pulse/configuring-endpoint-security-client-side-stephen-lyons/?lipi=urn%3Ali%3Apage%3Ad%5C_flagship3%5C_profile%5C_view%5C_base%5C_post%5C_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).

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/4/4b6bd3ed3b16a3a02b2fa8f5f24a164e9db5ec4d.jpeg)

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/1/12b9b47df065f79185f311786162b98a26681d9d.jpeg)

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.

> **[d97043d090eb3d58c30637e3165527c9127b4829.pdf](https://cdn.studio.f5.com/files/k6fem79d/production/d97043d090eb3d58c30637e3165527c9127b4829.pdf)**
>
> 2.04 MB

## 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**.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/9/9ff3dfd427a37ea25a3a142f2700dd25eddff59e.jpeg)

## 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**.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/5/3/537c3f1c9233f29ab2a9c4457489844a300a07ed.jpeg)

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.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/0/09100b0f5bad62e1406f0bade44379fdf904f787.jpeg)

- 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.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/e/1/e188f844d1c049a16bf233f51f04e5cb702e2a29.jpeg)

- 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**.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/a/a7341b6c7f65d77607d182a0291d69689b52b4d8.jpeg)

## 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**.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/7/7426d8c634b53e0287fb7145f1b46ed522046038.jpeg)

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

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/3/d/3d52ef01a8a86830f261770fe8b9bb5877190b3c.jpeg)

## 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.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/d/d3b251cbe3a3020461cd358d08e40a78214511e2.jpeg)

- 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**.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/f/fd87eab0f28875f6b47570b2c7627a5be862efd4.jpeg)

- 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.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/1X/20e35416c65b206995b8dca7dbe4d335224f4141.jpeg)

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**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/c/c69214532833497b726c82c444b3191feb588688.jpeg)

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

_**“Kerberos: can’t decrypt S4U2Self ticket for user [12345679@SITEREQUEST.COM](mailto: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**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/e/e/eefb39cb6ccc0a92460e1beba74464682e877fa0.jpeg)

## Configuring a OCSP AAA Resource

- Navigate to **Access \> Authentication \> OCSP Responder** \> Select **Create**
- Name: **Demo\_OCSP**
- URL: **[http://OCSP](http://OCSP)\_IP/ocsp**
- Certificate Authority File: **Select the issuing CA Certificate**
- Leave all other settings at their defaults and select **Finished**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/b/b84debf52db519945d9824b83a953f67b50513e8.jpeg)

## 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**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/7/760388b3023326135bc5790185feae713cd842e6.jpeg)

##### **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.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/8/82b2433870d5d41539d451cc662fc25379efa0a8.jpeg)

- Between **Start** and **Deny** select the **+**
- From the popup select the **Authentication** tab and select **On\_Demand Cert Auth \> Add Item**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/1/c/1c8de57746fa965710331211497523cb6db5fc82.jpeg)

- 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**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/a/aab1d625a1ec4ac0f4b8989bf91865510a92ef5b.jpeg)

- 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**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/b/bd9169574d805e54d3c89b12fe287a6fbd0cb920.jpeg)

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

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/4/4cf998748169552ad1ba857c2afd3f885fd4b8ea.jpeg)

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

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/2/0/209d993b120efe4e6ba50b84a7d0596018e404c7.jpeg)

- 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**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/a/9/a95eca3f9691dd8a3d136fc875e723a8def96237.jpeg)

- Select **Save**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/c/cbd23784de0dae02fbaec00624a63c919b04afc2.jpeg)

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

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/8/f/8f648650a01d67a9af2d1bf40f8e32260fcf4aa9.jpeg)

- 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**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/5/0/501761a6d6125a62c03d235a75f8f7445bf686d6.jpeg)

- 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**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/e/9/e90dee7b60b617e18f5097d5ae21bc5923a4ced9.jpeg)

- Click **Save**

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/5/531b33335e4b07312994c566b2e75b07994928e2.jpeg)

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

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/d/0/d09ffce4a05773c33c8626387b0c810fcdab6c99.jpeg)

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

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/e/efb84ffb656da5b7048bf2027f53292b3caee490.jpeg)

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

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/e/c/ecfbb744a74498c913f080925652226686609c34.jpeg)

- 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.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/8/815aecca01eff541580163a83cfc08bb4ff860d2.jpeg)

- 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

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/2/222998c6d610b23231d11a44ae43c33ac4697d30.jpeg)

- 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.

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/e/d/ed28e2b49c9e4561dd53669dbfef0901f29dd106.jpeg)

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

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/b/c/bc6f4647c4ec80e272c2114242bd7c85579b3cf4.jpeg)

- Click **Update**

## Begin Testing and Validation

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/3X/9/7/97ea5a254b9b4157aff4ced5b1bc2331015f57cc.jpeg)

 ![image_286436.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/f/fe39597acb901c0c1b3cc48f7aefde3cc9f5b4c0.jpeg)

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!

---

<div class="post-metadata">

**Author:** ![Joe\_Lupo\_283884](https://avatars.discourse-cdn.com/v4/letter/j/f4b2a3/32.png) [@Joe\_Lupo\_283884](https://community.f5.com/u/Joe_Lupo_283884)\
**Post date:** [February 26, 2019, 7:38pm UTC](https://community.f5.com/t/configuring-smart-card-authentication-and-kerberos-constrained-delegation-in-f5-access-policy-manager-apm/67914/2 "2019-02-26T19:38:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Steve\_Lyons](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/steve_lyons/32/15373_2.png) [@Steve\_Lyons](https://community.f5.com/u/Steve_Lyons)\
**Post date:** [February 26, 2019, 8:20pm UTC](https://community.f5.com/t/configuring-smart-card-authentication-and-kerberos-constrained-delegation-in-f5-access-policy-manager-apm/67914/3 "2019-02-26T20:20:17Z")

</div>

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.

 ![image_286438.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/a/a3aefb5de66732545e2d63d1cd75b37f3f5954b5.jpeg)

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

 ![image_286438.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/d/dca0dd02fa42be7dfbe577c7f04c6ee3c173f59e.jpeg)

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

 ![image_286438.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/8/832b516de09985344b3d1f220d0d28df69b31f59.jpeg)

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

 ![image_286438.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/b/b811d7d8fc68c1aafea5fe293bfef9366da8923f.jpeg)

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!

---

<div class="post-metadata">

**Author:** ![Joe\_Lupo\_283884](https://avatars.discourse-cdn.com/v4/letter/j/f4b2a3/32.png) [@Joe\_Lupo\_283884](https://community.f5.com/u/Joe_Lupo_283884)\
**Post date:** [February 26, 2019, 9:04pm UTC](https://community.f5.com/t/configuring-smart-card-authentication-and-kerberos-constrained-delegation-in-f5-access-policy-manager-apm/67914/4 "2019-02-26T21:04:29Z")

</div>

SO with that, would it matter if I used AD Query vs LDAP Query?

---

<div class="post-metadata">

**Author:** ![Steve\_Lyons](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/steve_lyons/32/15373_2.png) [@Steve\_Lyons](https://community.f5.com/u/Steve_Lyons)\
**Post date:** [February 26, 2019, 9:14pm UTC](https://community.f5.com/t/configuring-smart-card-authentication-and-kerberos-constrained-delegation-in-f5-access-policy-manager-apm/67914/5 "2019-02-26T21:14:49Z")

</div>

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 session.ad.last.attr.sAMAccountName.

---

<div class="post-metadata">

**Author:** ![Joe\_Lupo\_283884](https://avatars.discourse-cdn.com/v4/letter/j/f4b2a3/32.png) [@Joe\_Lupo\_283884](https://community.f5.com/u/Joe_Lupo_283884)\
**Post date:** [February 26, 2019, 9:38pm UTC](https://community.f5.com/t/configuring-smart-card-authentication-and-kerberos-constrained-delegation-in-f5-access-policy-manager-apm/67914/6 "2019-02-26T21:38:09Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![Steve\_Lyons](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/steve_lyons/32/15373_2.png) [@Steve\_Lyons](https://community.f5.com/u/Steve_Lyons)\
**Post date:** [February 27, 2019, 2:36pm UTC](https://community.f5.com/t/configuring-smart-card-authentication-and-kerberos-constrained-delegation-in-f5-access-policy-manager-apm/67914/7 "2019-02-27T14:36:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Joe\_Lupo\_283884](https://avatars.discourse-cdn.com/v4/letter/j/f4b2a3/32.png) [@Joe\_Lupo\_283884](https://community.f5.com/u/Joe_Lupo_283884)\
**Post date:** [February 27, 2019, 4:14pm UTC](https://community.f5.com/t/configuring-smart-card-authentication-and-kerberos-constrained-delegation-in-f5-access-policy-manager-apm/67914/8 "2019-02-27T16:14:14Z")

</div>

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 _“session.ad.last.attr.sAMAccountName”_ 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!