Users and security

People sign in with a username and password. Manage them on the Users page or from the command line. There are two roles:

• Admin: everything, including the Users, Sources, Parsers and System pages.
• Standard: the Dashboard and Database. A standard user can be limited to the events from chosen sources; they then see only those sources' events, in search and on the dashboard.

There must always be at least one admin, and admins can't delete themselves.

./siemlite users create -username alice -role standard  # prompts for a password (min 12 characters)
./siemlite users list
./siemlite users passwd -username alice                 # also signs alice out everywhere
./siemlite users delete -username alice

Accounts that sign in with Microsoft (see Sign in with Microsoft) are marked Microsoft on the Users page. They have no password, so Change password isn't offered for them. An admin can still change their role and which sources they see.

Anyone with a local account can change their own password on the Account page (it asks for the current one, and signs them out on every other browser). Wrong guesses there are limited separately from signing in, so someone using an unlocked session can't lock the owner out of signing in. Admins can set anyone's password on the Users page.

Passwords are stored as bcrypt hashes. Sessions last 12 hours, use an HttpOnly, Secure, SameSite=Strict cookie, and end on sign-out. After 10 failed sign-ins in 15 minutes a client address is locked out for the rest of the window.

Sign-in restrictions

Two switches tighten who can sign in with a password. Both take effect at once, for new sign-ins and for sessions already open.

• Keep the admin account to this server (Users page): the built-in local account named admin (the one made on first start) can then sign in, and work, only on SIEMLite's local port: https://localhost:8444 on the server itself. Elsewhere its sign-in is refused, whatever the password, and its sessions stop working. From another computer, reach the local port through an SSH tunnel (ssh -L 8444:localhost:8444 you@server, then open https://localhost:8444). Other admins aren't affected.
• Only allow sign-in with Microsoft (the Microsoft Entra ID card on the Integrations page): every account that signs in with a password is signed out and refused, so only Microsoft accounts can sign in. The built-in admin account is the exception, but only on the local port, so you can still get in if Microsoft sign-in breaks. It needs sign-in with Microsoft turned on and a local Admin account named admin. It applies only while sign-in with Microsoft is on: turning that off brings passwords back.

"On the server itself" means the request came in on the local port, not that it came from a particular address: behind Docker or a proxy on the same machine, visitors from anywhere can arrive from a local-looking address. The local port is set with -local-addr (default localhost:8444; outside a container, keep it on localhost). The Docker setup publishes it on the server's 127.0.0.1 only (SIEMLITE_LOCAL_PORT in .env). The port also checks who is connecting: it answers loopback and, in a container, only the container's gateway, which is where the server's own connections come from. Other containers on the network, and other machines that route to the container's address, are refused.

If no one can sign in to lift the restrictions, run this on the server (a running SIEMLite applies it within a minute):

./siemlite signin show
./siemlite signin reset            # Docker: docker compose exec siemlite siemlite signin reset

Changes are in the audit log (system.signin), and so are refused sign-ins (signin.refused).

Transport and tokens

• HTTPS only for the web UI: a self-signed certificate is generated on first start, SIEMLite can get one from Let's Encrypt for your domain (see Run on the internet), or bring your own with -tls-cert / -tls-key.
• Behind your own reverse proxy, SIEMLite believes visitors' addresses only from the proxies you name (-trusted-proxies), so sign-in lockouts and the audit log apply to the real visitor and can't be fooled by a forged X-Forwarded-For.
• Changing your own password (on the Account page) needs the current one, and wrong guesses count toward the same lockout as signing in.
• Access tokens can only send logs. Only a SHA-256 hash is stored.
• Syslog has no authentication, so only allowed senders are accepted.
• Secrets SIEMLite keeps (the email password, the Entra client secret) are encrypted with siemlite-secret.key, which isn't in backups.
• Client-certificate (mTLS) verification and per-key rate limiting are not implemented yet.
• Sign-ins, changes and backups are recorded in the audit log.