Skip to main content

Auth Log

Auth Log, in the Accounts menu, reads the whole authentication log of the server: domain users (shown as Host user), accounts and admin users in one list, newest first. Everybody else sees only their own rows; the admin user is the one person entitled to all of them.

Filters​

FilterMatches
IP AddressOne exact address, IPv4 or IPv6; not a range. A value that isn't an address lists nothing and says why.
UsernameThe username as typed on a failed sign-in, or the name of the user a row is about: a domain user's address, an account's or an admin user's username.
WhoHost users, Accounts or Admin users; Everyone by default.
EventOne event type, e.g. Sign-in failed; All by default.
From / ToA time range.

The filters combine. Clear drops them all.

A row​

ColumnHolds
WhoThe kind of user (Host user, Account, Admin user) and their name. An account links to its page; a domain user shows the account it belongs to. A failed sign-in that matched nobody shows the username as typed.
TimeWhen, and how long ago.
EventWhat happened; see The events.
ByWho caused it: the user themselves, an Account owner acting on a domain user, an Administrator, or the System. Impersonated marks a session an admin user opened in an account; see Act in an account.
ClientThe browser or program, from its user agent.
LocationThe address and its country. The filter icon beside the address lists every row from it, from every kind of user.

Locations are estimated from network addresses.

Failed sign-ins​

A failed sign-in is recorded for every kind of user, as Sign-in failed, with:

  • the username as typed;
  • the stage: the first step, or the second step after a right password;
  • the method or second factor tried: a password, a passkey or a token at the first step; the authenticator app's code, a backup code, a trusted device, a device approval or a passkey at the second;
  • for an admin user, the reason when the credential was right but the address wasn't allowed (see Allowed addresses).

A username that matched nobody is still a row, in nobody's own log, so this screen is the one place it shows. The sign-in forms are throttled, which bounds the noise an attacker can make here.

What is not recorded

A request with a bad CSRF token, a throttled attempt, a sign-in to a disabled user, a passkey the server doesn't know, and a failed "confirm your identity" check leave no row. None of them got as far as a credential being checked against a user.

The events​

The Event filter lists every type. The ones about how people sign in:

EventRecorded when
Signed in, Signed outA sign-in, with its method, and a sign-out.
Sign-in failedSee above.
Sign-in deniedA sign-in with the right password was refused on one of the user's devices.
Identity confirmedA signed-in user proved themselves again, before a sensitive change or for an application that asked for a stronger sign-in.
Password changed, Password removedA new password, or going passwordless.
Password found in a list of leaked passwordsThe password a user signed in with is on a public list of leaked passwords. One row per password.
Passkey added, Passkey removedA passkey registered or deleted.
Authenticator app set up, Authenticator app removed, Backup codes regenerated, Trusted devices revokedThe second step and what stands in for it.
Device added, Device removed, Device approvals turned on, Device approvals turned offWeb Push devices.
Setup link generated, Setup link usedA setup link, for an account or an admin user.
Sign-in resetEvery credential of an admin user removed at once, on Admin Users or with server:admin-user:reset-credentials. An account's or a domain user's reset takes the password only, and is recorded as Password removed and Setup link generated.
Session revokedOne OpenID Connect session of a domain user revoked on request. Sessions that end as the side effect of another change have no row of their own.
User created, Admin user deletedThe first row of every user's log; an admin user deleted, recorded on the admin user who deleted.
Allowed addresses changedAn admin user's allowed addresses replaced.
Sign-in token issuedA server API key minted a sign-in token for an admin user. A token minted on the host leaves no row; see Break-glass on the host.
Locked downA domain user was locked down; the row names the measures applied. Kept past the retention period.
Sign-in help requested, Sign-in help request closedAn account or a domain user asked for help; see Sign-in Help Requests.

The log also holds a few rows that are about a user but not about signing in: app passwords, OAuth application access, a webhook secret revealed, and the outgoing-mail quarantine of a mailbox.

Who sees which rows​

WhoSeesWhere
An admin userEvery row on the server.Auth Log
An admin userTheir own rows, failed sign-ins on their username included.Your Activity on Password & Security
An account holderThe account's rows.Account Activity in the account panel, and the account API
A domain userTheir own rows.The sign-in portal's activity page

Admin users' rows never leave the admin app: no API, and no account sees them.

Retention​

Rows are kept 90 days, and a daily task of the panel's worker deletes the older ones. Two things outlive that:

  • Locked down rows, which the domain user's page reads as history, are kept for the life of the user.
  • Every row is also written to syslog when it is recorded. That copy lives as long as the host's log rotation keeps it, and is the record to ship to a central log server.

Separately from the log, each passkey, each app password and each domain user's password remembers its last use, which the Last used columns show. The time stays; the address is forgotten after 180 days, by another daily task or by hand:

elpanctl housekeeping:credential-use:purge
elpanctl housekeeping:credential-use:purge --before="-30 days"

See Housekeeping for the other timers.