Authentication log – who tried to sign in, from where and with which result¶

This chapter describes the authentication log: a record of every attempt to sign in to nexxcite, successful or not, with the user name, the result, the reason of a failure, the IP address and the browser. It explains how to switch the log on, what it records and how to read it in the Admin Studio.

It is intended for administrators of a nexxcite installation and for whoever reviews sign-ins for security reasons.

1. The authentication log at a glance¶

Question	Answer
Is it switched on?	No. It is off by default and switched on in the global settings.
What is recorded?	Every attempt to sign in – successful, failed, or waiting for the second factor.
Which ways of signing in?	User name and password, the code of an authenticator app, a recovery code, an external identity provider (single sign-on), the sign-in after a password change, and REST API clients requesting an access token.
Where can I read it?	Admin Studio → Monitoring → Authentication Log, or through the spotlight search (Ctrl+K).
Who may read it?	Users with the permission "View Authentication Log" – by default administrators and developers.
How long is it kept?	90 days by default; configurable in the global settings.

Summary¶

Switch the log on in the global settings, category "Login protection", with "Record sign in attempts". It takes effect with the next attempt; no restart is needed.
Each attempt becomes one entry. A sign-in with a second factor produces two entries: one for the password ("Second factor asked") and one for the code.
The IP address is the address of the client. Behind a reverse proxy, nexxcite only knows it if the section ForwardedHeaders of the configuration is set up (section 5).
The user name is recorded as it was typed, also when no such user exists. The log therefore contains personal data – decide on the retention accordingly.

2. Switching the log on¶

Open Admin Studio → System → Settings.
In the category "Login protection", switch on "Record sign in attempts".
Optionally change "Keep sign in attempts for (days)" (default 90).
Save.

From the next attempt on, every sign-in on every server of the installation is recorded. Switching the log off stops the recording; entries recorded earlier stay until their retention ends.

3. What is recorded¶

Field	Meaning
When	Date and time of the attempt
User	The user name as it was typed or as the identity provider or API client identified itself. If the user was renamed since, the current name is shown below it.
Result	"Succeeded", "Failed" or "Second factor asked"
Reason	Why a failed attempt failed – see the table below
Method	"Password", "Authenticator app", "Recovery code", "Identity provider", "Password change" or "REST API client"
Identity provider / API access	The name of the external identity provider or of the API access
IP address	The address of the client
Browser and system	Browser, operating system and kind of device, read from the user agent of the browser

The details of an entry additionally show the complete user agent, the language of the browser, whether the user asked to stay signed in, the page the attempt was made on, the server that handled it and – behind a proxy – the address of the proxy.

Reasons of a failed attempt¶

Reason	Meaning
"Unknown user"	No user with this name exists. For a REST API client: no API access with this client id exists.
"Wrong password"	The user exists, the password is wrong.
"Wrong code"	The code of the authenticator app or the recovery code is wrong.
"Temporarily locked"	The account is locked for a while after too many failed attempts (see Sign-in and sessions).
"Locked by an administrator"	The account is locked in the user editor.
"Password expired"	The password was right, but it has expired. The user is sent to change it; the sign-in after the change is recorded as its own entry.
"Sign in not allowed"	The account may not sign in.
"Identity provider error"	The external identity provider reported an error or returned no usable identity. The message of the provider is shown in the details.
"No linked account"	The external identity is not linked to a user of nexxcite.
"Wrong client secret"	The client secret of an API access is wrong or no longer valid.
"User not available"	The API access has no user, or its user no longer exists.
"No license available"	An API client was refused because no license was free.

Example: a user types a wrong password three times and then the right one, and the installation asks for a second factor. The log shows three entries "Failed – Wrong password", one entry "Second factor asked" and one entry "Succeeded" with the method "Authenticator app".

4. Reading the log¶

Open Admin Studio → Monitoring → Authentication Log.

The tiles at the top count the attempts of the selected period: all attempts, succeeded, failed (with their share) and "Second factor asked". The list below shows the newest attempts first, 100 at a time; "Load older attempts" loads the next 100.

Filter	Effect
"Period"	Last hour, last 24 hours, last 7 days (default), last 30 days, everything, or a custom range of days
"Result", "Reason", "Method"	Only attempts with this value
"User name contains"	Only user names that contain the text
"IP address starts with"	Only addresses that start with the text – `10.0.` finds a whole network

Selections apply immediately; the text fields apply with Enter or "Apply". "Reset" restores the defaults.

A click on a row opens the details on the right. From there, "All attempts of this user name" and "All attempts from this address" filter the list, and "Open user" opens the user editor (requires the permission to edit users).

If the log is switched off, the page says so above the list and offers the way to the global settings.

5. The IP address behind a reverse proxy¶

When nexxcite runs behind a reverse proxy, a load balancer or a Kubernetes ingress, the proxy is the sender of every request. nexxcite then only knows the address of the client if it is told which proxies it may trust. This is configured in the section ForwardedHeaders of the configuration file, see Installation and configuration.

By default, nexxcite reads the client from the header X-Forwarded-For.
If your proxy or CDN passes the client on in another header – for example X-Real-IP, CF-Connecting-IP or True-Client-IP – set ForwardedHeaders:ForwardedForHeaderName to that name.
Without this configuration, every entry shows the address of the proxy. The details then show the client header as it arrived, marked "not evaluated": it was sent by somebody nexxcite does not trust and may be forged.

6. Settings for operation¶

Setting	Default	Meaning
"Record sign in attempts"	Off	Records every attempt to sign in in the authentication log.
"Keep sign in attempts for (days)"	90	How long an entry is kept. Older entries are deleted automatically, also after the log was switched off. 0 keeps every entry.

appsettings.json¶

Setting	Default	Meaning
`ForwardedHeaders:*`	see Installation and configuration	Decides which address is recorded as the client
`ForwardedHeaders:ForwardedForHeaderName`	empty (`X-Forwarded-For`)	The header the client address is read from

7. Limitations¶

Requests that the limit per caller rejects before they reach the sign-in page (see Sign-in and sessions, section 4) are not recorded.
Signing out and sessions that end because they expired are not recorded – the log records sign-ins only. Open sessions are listed under Admin Studio → Access → Authenticated Users.
An access token that a signed-in user creates for themselves inside nexxcite is not recorded; only REST API clients that request a token with their client credentials are.
Browser, operating system and device are read from the user agent, which the browser sends and which can be changed. Windows 10 and Windows 11 cannot be told apart this way.
The log cannot be exported from the page.
If an entry cannot be written – for example because the database is unreachable – the sign-in still takes place. The missing entry is noted in the application log of the server.
The user name is recorded as typed. If a user types their password into the user name field by mistake, it ends up in the log as a failed attempt with an unknown user. Keep the retention as short as your requirements allow, and restrict the permission accordingly.

8. Frequently asked questions¶

The log is switched on, but the page stays empty. Check the period filter, then try to sign in once with a wrong password. If nothing appears, check the application log of the server for a message about the authentication log.

Every entry shows the same IP address. That is the address of your reverse proxy. Configure the section ForwardedHeaders (section 5).

Why are there two entries for one sign-in? With two-factor authentication, the password and the code are two attempts. The first entry is "Second factor asked", the second one tells whether the code was right.

Can I export the log? No. The page shows the entries; an export is currently not available.