Reading Authentication & Login Logs

"A user can't log in" has been this course's own running example since Chapter 1. This chapter finally works through it properly — not as one problem, but as four genuinely different layers a request passes through, each with its own log source, each capable of being the actual point of failure.

The Diagnostic Order: Outside In

Working outside-in matters: checking layer 3 first, when the real problem is layer 2, means reading application logs that were never going to show anything, because the request never reached the application to log anything at all.

Layer 1: Never Reaching the Server

If a user reports being unable to log in and nothing in any log on this server — not the access log, not the error log, not the application's own log — shows any trace of a request from them at all, the request most likely never arrived. A DNS problem, a network routing issue, or a client-side connectivity problem on the user's own end can all produce exactly this symptom. This server's own logs, by definition, cannot record a request that never reached it.

Layer 2: Blocked Before the Application

A very common real-world tool here is fail2ban, which watches logs (often auth.log itself) for repeated failed attempts and automatically firewalls off the offending IP for a period of time. Its own actions are logged separately:

Once banned, that IP's later requests are rejected at the firewall — before Apache or Nginx ever sees them, meaning they won't appear in the access log either. A legitimate user who mistyped their password a few times too many can end up banned by exactly the same mechanism meant to stop an attacker; fail2ban-client status <jail> (or the ban log itself) is how you tell the two apart.

A softer version of the same layer: HTTP basic authentication configured directly on the web server (via .htaccess or an equivalent) rejects a request with a 401 before the application underneath ever runs — this does appear in the access log, just without any corresponding application-level log entry.

Layer 3: Authentication Failing in the Application

This is the layer most people assume is the whole problem, and it does cover the most common real causes:

• Wrong credentials — routine, per Chapter 2's own example; logged at INFO, not ERROR, in a well-configured application
• Account locked or disabled — a deliberate security feature after too many failed attempts on one specific account, distinct from fail2ban's IP-level ban
• Account doesn't exist — a typo'd username, or a genuinely deleted/never-created account
• Session or token expired — the user was previously logged in, but their session has since lapsed

Layer 4: Authenticated Successfully, Then Something Breaks

The rarest but most confusing case: the application's own log shows a genuinely successful authentication, but the user still ends up unable to log in — because something after that succeeded step fails. A session store that's unreachable (Redis down, disk full for file-based sessions) or a broken post-login redirect are both real examples. The tell is a successful auth log line immediately followed by an apparently unrelated error somewhere else in the same request's timeframe — exactly the kind of cross-log correlation Chapter 4 introduced.

Hands-On Exercises