Audit events interpretation

As mentioned in the prior section, the audit log in OpenIAM stores all events that occur in the system. However, simply storing events is not always enough — you also need to understand what each log entry means and how to respond to it, for example, when troubleshooting a potential issue. Below are some of the most frequent audit events in OpenIAM and guidance on how to interpret and use them.

Login and sign-in events

A login or sign-in event is recorded every time someone attempts to sign in to the system (whether successfully or unsuccessfully). What the user sees in the audit log entry and what it means are described below.

What you see in the log	What it means	Action to take
`LOGIN` — `SUCCESS`	The user signed in successfully.	No action is needed.
`LOGIN` — `FAILURE`	An incorrect username or password was entered.	Watch for repeated failures.
`LOGIN` followed immediately by `INCREMENT_FAIL_AUTH_COUNT`	A failed login attempt was recorded.	This is normal if occasional; investigate if frequent.
Multiple `LOGIN - FAILURE` in quick succession for the same user	A possible brute-force attack occurred, or the user was locked out.	Check if it is followed by `USER_ACCOUNT_LOCKED`. Contact the user to verify.
`USER_ACCOUNT_LOCKED`	The account was automatically locked after too many failed attempts.	Verify with the user whether they were genuinely trying to log in. Unlock via HelpDesk if confirmed legitimate.
`LOGIN` from an unfamiliar IP address or country	A possible unauthorized access attempt occurred.	Verify with the user.
`IMPERSONATION`	An administrator signed in as another user.	Always review and confirm that the admin had a valid reason (support ticket, investigation, etc.).
`LOGIN_VIA_SOCIAL`	The user signed in via a social/OAuth provider (e.g., Google, Facebook, etc.).	This is normal if social login is enabled.
`SAML_IDP_INITIATED_SSO`	The user was automatically signed in via a SAML SSO federation.	This is normal in federated environments.
`LOGOUT`	The user signed out.	This is normal behavior.

🚩 Red flags to watch for:

LOGIN SUCCESS from a different country or city than usual, especially at unusual hours.
LOGIN SUCCESS immediately after several failures (someone may have guessed the password).
IMPERSONATION without a corresponding support ticket.

Password change events

This event is recorded whenever a user's password is created, changed, or reset — whether by the user, an administrator, or the system. What the user sees in the audit log entry and what it means are described below.

What you see in the log	What it means	Action to take
`CHANGE_PASSWORD` — Principal = Target User	The user changed their own password (via SelfService).	This is normal behavior.
`CHANGE_PASSWORD` — Principal ≠ Target User	An administrator or process changed another user's password.	Verify that the administrator had the authority to do this.
`FORGOT_PASSWORD` > `ANSWER_CHALLENGE_RESPONSE_QUESTIONS` > `CHANGE_PASSWORD`	The user completed the SelfService forgot-password flow.	This is normal behavior; verify that the steps were completed in the expected order.
`USER_RESET_PASSWORD_ON_BEHALF`	An administrator reset the password on behalf of the user.	Check that the administrator was authorized and that the user confirmed the reset.
`BULK_ADMIN_USER_RESET_PASSWORD`	An administrator reset passwords for multiple users at once.	This is a high-impact action; confirm that it was planned and authorized.
`CHECK_IF_PASSWORD_WAS_COMPROMISED`	The system checked whether the chosen password appears in a breach database.	This is informational; `FAILURE` here means the chosen password was rejected as compromised.
`PROVISIONING_RESET_PASSWORD`	The password was reset on a connected system (e.g., Active Directory) as part of provisioning.	This is normal during onboarding or offboarding workflows.
`USE_RESET_PASSWORD_TOKEN`	A one-time password reset link was used.	Verify that the token was sent to the correct user's email address.

🚩 Red flags to watch for:

CHANGE_PASSWORD where the Principal is a service account or system user at an unexpected time.
BULK_ADMIN_USER_RESET_PASSWORD outside of a planned maintenance window.
USE_RESET_PASSWORD_TOKEN appearing without a prior FORGOT_PASSWORD event.
Multiple CHANGE_PASSWORD events for the same user within a short period.

Provisioning — account creation and access events

This event is recorded when the system creates, updates, disables, or removes a user's account on a connected system (Active Directory, SAP, Exchange, etc.). Provisioning pushes access to external platforms. What the user sees in the audit log entry and what it means are described below.

What you see in the log	What it means	Action to take
`PROVISIONING_ADD` — `SUCCESS`	A new account was created for the user on a managed system.	Verify that this was expected behavior (new hire, role change).
`PROVISIONING_ADD` — `FAILURE`	Account creation failed on the managed system.	Investigate the connector or managed system. The user may not have access.
`PROVISIONING_MODIFY`	The user's account was updated on a managed system (e.g., name, department, group membership).	This is normal during profile or role changes.
`PROVISIONING_DISABLE`	The account was disabled on a managed system.	This is typical during suspension or leave of absence.
`PROVISIONING_ENABLE`	The account was re-enabled on a managed system.	This is typical when a user returns from leave.
`PROVISIONING_DELETE`	The account was permanently deleted from a managed system.	This is expected during offboarding; flag it if unexpected.
`DE_PROVISIONING`	All access across all managed systems was removed.	This indicates full offboarding. Verify that it corresponds to a termination event.
`PROVISIONING_SUSPEND`	The account was suspended (softer than deletion).	This is normal for temporary deactivation.
`PROVISIONING_RESUME`	A suspended account was restored.	Check the reason and who triggered it.
`PROVISIONING_DEPROVISION_ON_DATE`	Access was automatically removed because an end date was reached.	This is normal for contractors or time-limited roles.
`RETRY_PROVISIONING`	A previous provisioning attempt failed and is being retried.	Review the original failure to understand the root cause.
`SIMULATE_PROVISIONING`	A test run was performed and no real changes were made.	This is informational; an administrator was previewing what would happen.

🚩 Red flags to watch for:

PROVISIONING_ADD for a user who is not expected to have access to that system.
DE_PROVISIONING without a corresponding termination workflow.
PROVISIONING_ENABLE for a user who is on leave or already terminated.
Multiple RETRY_PROVISIONING events, which indicate a persistent connectivity or configuration issue.

Synchronization — identity import events

This event is recorded when the system reads data from a source system (HR system, LDAP, CSV file) and imports it into OpenIAM. Unlike provisioning (which pushes access out), synchronization pulls data in. What the user sees in the audit log entry and what it means are described below.

What you see in the log	What it means	Action to take
`SYNCHRONIZATION` — `SUCCESS`	A synchronization job ran and completed successfully.	This is a normal scheduled operation.
`SYNCHRONIZATION` — `FAILURE`	The synchronization job failed to complete.	Investigate; users may have stale data if the HR feed is broken.
`SYNCHRONIZATION_RECORD`	A single user record was processed during synchronization.	Review these entries to see what changed for a specific user.
`SYNCHRONIZATION_ORPHAN`	A record was found in the source system but no matching user exists in OpenIAM.	Review this; it may indicate a new hire not yet onboarded or a stale/ghost account.
`LINK_ORPHAN`	An orphan record was matched and linked to an existing OpenIAM user.	Verify that the match is correct, as incorrect linking can grant unintended access.
`CREATE_NEW_USER_FROM_ORPHAN`	A new OpenIAM user was automatically created from an orphan record.	Verify that the new user record is correct and complete.
`REMOVE_ORPHAN`	An orphan record was discarded.	Confirm that no valid user was accidentally removed.
`RECONCILIATION`	A reconciliation job ran to compare OpenIAM data against a target system.	This is a normal maintenance operation.
`RECONCILIATION_RECORD_FALSE`	A record did not match between OpenIAM and the target system.	This requires review; it indicates data drift and the systems are out of sync for that user.
`RECONCILE_TARGET_WITH_IDM`	The target system's data was compared against OpenIAM as the source of truth.	This is normal during a reconciliation run.

🚩 Red flags to watch for:

SYNCHRONIZATION FAILURE occurring several days in a row.
A high volume of SYNCHRONIZATION_ORPHAN events after a synchronization.
RECONCILIATION_RECORD_FALSE for many users.
LINK_ORPHAN performed by a system account without review of the matching rules.

Audit

Password reset for administrator's account