When generating the Okta Password Health Report, the Last Login and Last Password Change fields may appear blank for certain users. Because this report pulls information directly from the attributes in the Okta user object, blank fields indicate that these specific attributes have not yet been populated or updated within Okta.

This behavior typically occurs for newly created accounts, Active Directory (AD)-sourced users, or users who have not performed the specific actions required to trigger an update to these fields.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Reports
• Active Directory (AD)

The Last Login and Last Password Change fields appear blank because the corresponding attributes on the Okta user object are empty.

This can happen under the following scenarios:

• The account is newly created: If a user has never logged into Okta or has not changed their password since the account was provisioned, these fields remain unpopulated.

• The user is AD-sourced: Okta does not store or track password details for users managed in Active Directory because password management occurs directly within AD. Additionally, during Active Directory Desktop Single Sign-on (ADSSO), users authenticate via a Kerberos ticket, meaning Okta does not process or record an Okta password validation event.

Understanding how these fields are updated

• • Last Login (lastLogin): This field is updated only when a user explicitly logs into the Okta End-User Dashboard (including IdP-initiated logins). It does not update if a user performs a Service Provider (SP)-initiated login directly to an external application without hitting the dashboard.

  • Last Password Change (passwordChanged): This field is updated when an explicit password lifecycle event occurs natively within Okta (such as a self-service password reset or an administrator-initiated password update). It does not track password changes made locally inside an Active Directory environment.

Note on Data Retention: While Okta's standard System Log data retention period is 3 months, the Password Health Report relies entirely on the live state of the user object attributes, not historical system logs. If a field is blank, it means the triggering action has never occurred for that user profile in Okta.

How to track password changes for Active Directory-sourced users

Because the Okta Password Health Report cannot natively read the user object attributes for passwords managed in Active Directory, administrators must query Okta's System Log to track these events.

1. Navigate to Reports > System Log in the Okta Admin Console.

2. To view records of when a password reset occurs in AD and is successfully detected/synchronized by Okta, enter the following query into the search bar: 
   eventType eq "system.agent.ad.reset_user_password"

3. Click Search to view the timestamps and details of AD-driven password changes.

NOTE: System log events are retrievable within Okta's standard 3-month data retention window.

Related References

• Okta Password Health Report