Authentication Manager 8.x

In the Authentication Manager user dashboard, the Last Logon Date in the Assigned Tokens section can show a more recent value than the Last Authentication Date field in the User Profile section for the same user.

The information in these fields relates to two different objects so the two values are not expected to match in the user profile.

• Last Authentication Date displayed in the User Profile section is associated with the user. 
• Last Logon Date in the Assigned Tokens section is associated with the token. 

Why the two dates differ

Certain authentication methods update only the user's date and not the token's. For example, authenticating from the Self-Service Console with a tokencode updates both fields, while authenticating with PIN + Approve updates only the user's Last Authentication Date.

Self-Service Console logins also update this value, including when no token is involved. If the user authenticates with their token, logs out, and then authenticates again with a password, the Last Authentication Date will change even though the token was not used the second time.

Why a replica can show an older date than the token

The user's last authentication date is stored in a table that uses out-of-band replication rather than standard replication. Out-of-band replication batches updates for fields that change frequently but aren't time-critical, running every 5 minutes by default, to reduce load on the server and on replication.

For this particular table, the data is only needed on the primary instance, because that is where reports run. The sync direction is one-way:

• If a replica processes the authentication, the value is batched to the primary approximately every five minutes.
• If the primary processes the authentication, the value is not pushed out to the replicas.
• As a result, a replica can show a user last authentication date that lags behind the token's last logon date. This is expected behavior by design, and is not a defect.

This is most often noticed on an instance that used to be a replica and was promoted to primary. In a DR promotion, data from the old primary is not restored to the new primary, so some historical values will be missing on the new primary.

What to do

• Always query the primary instance for a user's last authentication date, as it is the only instance with complete data. Querying a replica will return values that lag or are missing.
• The value corrects itself going forward. The field updates the next time the user authenticates.
• After a promotion, perform a backup and restore from the old primary to the new primary so the data carries forward.
• If historical data is missing after a DR promotion and recovering it is business-critical, contact RSA Support so the case can be reviewed with Engineering.