When administrators enable Delegated Authentication (DelAuth), Okta sends authentication requests to an Active Directory (AD) Domain Controller (DC), which updates the lastLogon attribute locally. Because this attribute does not replicate across other DCs and passwordless flows bypass DelAuth entirely, mapping the lastLogon value to an Okta profile attribute yields inconsistent results.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Directories
• Active Directory (AD)
• Delegated Authentication (DelAuth)
• lastLogon

How does the Active Directory lastLogon attribute interact with Okta Delegated Authentication?

Review the following details regarding the interaction between the AD lastLogon attribute and Okta DelAuth.

• When administrators enable DelAuth on an AD directory, Okta sends all authentication requests for Okta users linked to that domain using a username and a password to an AD DC via the Okta AD Agent.
• Upon receiving this request, the DC updates the lastLogon attribute for the user only on that specific DC. This attribute does not replicate to other DCs.
• When a user authenticates into Okta using a passwordless flow, Okta does not initiate DelAuth. Consequently, theLastLogonDate does not reflect the Okta authentication.
• Because the lastLogon attribute does not replicate to other DCs and Okta may scan different DCs during each import, administrators should avoid mapping this value to an Okta profile attribute.

Related References

• Understanding the AD Account attributes - LastLogon, LastLogonTimeStamp and LastLogonDate