Fresh install - Kratos login flow expired immediately, unable to login after clean install

[mrkrose843]

Version

2.4.211

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Standalone

Location

on-prem with Internet access

Hardware Specs

Meets minimum requirements

CPU

4

RAM

15

Storage for /

1.6T

Storage for /nsm

1.5T

Network Traffic Collection

span port

Network Traffic Speeds

1Gbps to 10Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

After a fresh installation of Security Onion with no configuration changes, the web interface login page immediately displays a "flow expired" error, making it impossible to log in. This occurred on two separate fresh installations on the same hardware.

Symptoms:

Login page loads but immediately shows "flow expired" error
Error persists in incognito/private browser windows
Error persists after clearing all cookies
Error occurs on multiple client machines

Troubleshooting Performed:

Verified all containers running healthy via sudo so-status
Confirmed host and Kratos container times match: date && sudo docker exec so-kratos date
Verified chrony NTP service active (but unsynchronized due to district firewall blocking ICMP - UDP 123 confirmed reachable)
Confirmed Kratos database exists and has data: /kratos-data/db.sqlite (700KB)
Successfully ran database migrations: sudo docker exec so-kratos kratos migrate sql -e --yes returned "Successfully applied SQL migrations"
Ran sudo so-checkin successfully with no errors
Verified kratos.yaml configuration shows correct management IP throughout
Checked nginx config - error.log is 0 bytes, no nginx errors

Key Log Findings:
From /opt/so/log/kratos/kratos.log:

"reason":"No active session was found in this request"
"msg":"request does not have a valid authentication session"
"status":"Unauthorized"
"path":"/sessions/whoami"

From Kratos startup:
"reason":"No active session was found in this request"
"msg":"The config has no version specified"
"service_name":"Dry Kratos"
"service_version":"v1.3.1"

Observed Behavior:

Every browser login attempt hits /self-service/login/browser
Kratos creates a flow and redirects to /login?flow=
Browser immediately receives "flow expired" error without any user interaction
/sessions/whoami returns 401 Unauthorized immediately
Nginx @error403 handler in nginx.conf sets ory_kratos_session cookie to expired (1970) which may be contributing

Questions:

Is "service_name":"Dry Kratos" expected behavior or indicative of a misconfiguration?
Is the missing version: field in kratos.yaml expected for SO 2.4?
Is there a known issue with Kratos session handling on fresh installs?
Is the nginx @error403 cookie-clearing behavior intentional?

Additional Notes:

Management IP confirmed correct in kratos.yaml throughout
Issue reproduces identically on second fresh install
so-checkin completed successfully with no errors
Kratos version: v1.3.1 (Build: 2026-03-11)

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[jertel]

Historically, every time someone has reported this "login form expired" issue, it's consistently been because the manager node's time is out of sync with the analyst workstation (the one trying to login). I see that your NTP port is blocked, so you will need to manually verify that the times on all machines involved are correct, and using correct time zones and daylight savings time. Servers typically remain in UTC time.

[mrkrose843]

RESOLVED - Root Cause: System Clock 16 Hours Out of Sync
After extensive troubleshooting, the root cause of the "login form expired" error was that the Security Onion server's system clock was 16 hours behind actual UTC time.
What Was Happening
SO Server showed: 04:25 UTC
Actual UTC time: 20:25 UTC
Difference: 16 hours
Kratos was issuing login flow tokens timestamped 16 hours in the past. When the browser attempted to use them, Kratos immediately rejected them as expired — causing the "login form expired" error before any user interaction was possible.
Why It Was Hard To Diagnose

The SO server and Kratos container times matched each other — so the internal time comparison looked correct
NTP was configured but not synchronizing due to district firewall policies blocking outbound NTP
chrony showed System clock synchronized: no but the clock appeared stable
The error message "login form expired" pointed toward Kratos configuration rather than system time
The issue persisted across three separate fresh installations on the same hardware

Resolution
Manually corrected the system clock to actual UTC time:
bashsudo timedatectl set-ntp false
sudo timedatectl set-time "2026-05-15 20:25:00"
sudo timedatectl set-ntp true
sudo docker restart so-kratos
Login immediately succeeded after correcting the time.

Permanent Fix Needed
Because our network blocks outbound NTP (UDP 123), we need a local NTP source. Our solution:
Option 1 — Use internal NTP server:

sudo vi /etc/chrony.conf

Add local NTP server

server iburst prefer
sudo systemctl restart chronyd
sudo chronyc makestep

Recommendations for Security Onion Team

Consider adding a clock sync check during installation that warns if system time appears incorrect
Consider adding a pre-flight check before Kratos starts that validates system time is within acceptable range
The error message "login form expired" could be improved to include a time sync warning when flow tokens are extremely old

Thank You
Thank you to the community for pointing toward time sync as the root cause. Special note: our NTP troubleshooting was complicated by the fact that ping and ICMP are blocked by our district firewall, making it appear that NTP servers were unreachable when UDP 123 was actually working fine.