Authentication, authorization and accounting

Why this matters

Three questions, always in this order: who are you (authentication), what may you do (authorization), and what did you do (accounting). Most access problems are one of the three failing, and naming which one narrows the search enormously.

On a standalone machine all three live in local files. On anything joined to a directory they involve LDAP, Kerberos and a daemon gluing them together — and knowing which component does which job is what lets you debug a login that fails for no visible reason.

The lesson

Directory and identity

LDAP — the Lightweight Directory Access Protocol — is a hierarchical database of people, groups and machines, queried over ports 389 and 636 (TLS). It answers who exists and what are their attributes: username, UID, groups, home directory, shell. Active Directory is Microsoft's LDAP directory with extensions.

Kerberos answers are you who you claim to be, and does it without ever sending a password across the network. A Key Distribution Centre issues a ticket-granting ticket after you authenticate once; services then accept tickets derived from it. That is what makes single sign-on work — and it is why Kerberos is exquisitely sensitive to clock skew. Tickets carry timestamps and a difference of more than about five minutes causes authentication to fail outright. "Logins stopped working and nothing changed" is very often NTP.

The pairing is the thing to hold: LDAP is the directory, Kerberos is the authentication. A domain-joined Linux box normally uses both — Kerberos to prove identity, LDAP to look up what that identity is entitled to.

SSSD — the System Security Services Daemon — is what connects a Linux machine to that. It handles the LDAP and Kerberos conversations, caches credentials so laptops work offline, and presents everything through the normal NSS and PAM interfaces so ordinary tools just work. Winbind is the older Samba component doing a similar job for Active Directory; SSSD is preferred now.

realm discover example.com          # what domain is out there?
realm join example.com -U admin     # join it — configures SSSD and Kerberos
realm list                          # what we are joined to
id alice@example.com                # does the directory user resolve?
klist                               # current Kerberos tickets
kinit alice@EXAMPLE.COM             # get a ticket manually

realm join does a great deal in one step: installs configuration, joins the domain, sets up SSSD, and edits /etc/nsswitch.conf so directory users resolve.

Samba provides SMB/CIFS file sharing and can also act as a domain member or domain controller — so it appears in both the storage and the identity halves of this exam.

Polkit (formerly PolicyKit) is authorization for desktop and system services rather than commands. It decides whether an unprivileged process may ask a privileged one to do something — mount a disk, change the timezone, install an update — with rules that can depend on the user, the action and whether the session is local.

pkaction                        # every registered action
pkexec command                  # run as another user, via polkit

Where sudo governs you running a program, polkit governs a program asking a service to act on your behalf. That is why changing the time in a desktop settings panel prompts for a password without sudo being involved.

PAM

Pluggable Authentication Modules is the framework nearly every authentication path goes through. Rather than each program implementing its own login logic, they call PAM, and PAM consults a stack of modules configured per service.

Configuration lives in /etc/pam.d/, one file per service (sshd, login, sudo, su), with lines of the form:

type    control    module    arguments

auth       required     pam_unix.so
auth       sufficient   pam_sss.so
account    required     pam_unix.so
password   requisite    pam_pwquality.so retry=3 minlen=12
session    optional     pam_motd.so

The four types:

• auth — prove identity
• account — is this account permitted right now (not expired, allowed at this hour, on this terminal)
• password — rules for changing the password
• session — set-up and tear-down around the session: mount a home directory, print the message of the day, apply limits

The controls decide how a module's result affects the stack:

• required — must pass; on failure the stack continues, then fails
• requisite — must pass; fails immediately
• sufficient — success ends the stack successfully, provided nothing required has already failed
• optional — the result rarely matters
• include — pull in another file's stack

Two practical points. pam_pwquality.so (or pam_cracklib) is where password complexity rules actually live — minimum length, character classes, dictionary checks — so "enforce a 12-character password" is a PAM change, not a chage one. And pam_faillock.so implements lockout after repeated failures.

Editing PAM badly can lock every account out of the system, including root. Keep a second root session open while you edit, and test in that second session before closing the first. A broken /etc/pam.d/system-auth is recoverable only from rescue media otherwise.

Accounting: logging

/var/log holds the system's record of itself:

The split is by distribution family: RHEL uses messages and secure, Debian uses syslog and auth.log.

rsyslog is the traditional daemon. It receives messages, sorts them by facility (auth, cron, mail, kern, local0–7) and severity (emerg through debug), and writes them to files — or forwards them to a central server, which is the point of it in any real estate:

# /etc/rsyslog.conf
authpriv.*      /var/log/secure
*.info;mail.none;authpriv.none  /var/log/messages
*.*             @@logserver.example.com:514      # @@ = TCP, @ = UDP

Forwarding logs off the host is a security control, not just convenience. An attacker who gains root can edit local logs; they cannot retract what has already been sent elsewhere.

journalctl reads systemd's journal — structured, indexed, and queryable in ways a text file is not:

journalctl -u sshd                    # one unit
journalctl -f                         # follow
journalctl --since "2026-09-09 08:00" --until "09:00"
journalctl -p err -b                  # errors this boot
journalctl _UID=1001                  # one user
journalctl --disk-usage
journalctl --vacuum-time=30d          # trim to 30 days

The journal is often volatile by default. Storage=persistent in /etc/systemd/journald.conf plus a /var/log/journal directory keeps it across reboots — necessary if you ever want to investigate a crash.

logrotate stops logs consuming the disk. It runs from cron or a timer and rotates, compresses and deletes according to policy:

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp myapp
    postrotate
        systemctl reload myapp
    endscript
}

logrotate -d /etc/logrotate.conf     # DEBUG: show what would happen
logrotate -f /etc/logrotate.d/myapp  # force a rotation now

The postrotate step matters more than it looks. A daemon holds its log file open by descriptor, not by name. Rename the file and the daemon keeps writing to the renamed one — so the "new" log stays empty and disk space is never reclaimed. Reloading, or copytruncate, is what makes rotation actually work. This is the same deleted-but-open-file problem that makes df and du disagree.

Auditing

auditd records security-relevant events at the kernel level — file access, system calls, authentication — independently of application logging, and is what compliance regimes require.

# /etc/audit/rules.d/audit.rules
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-a always,exit -F arch=b64 -S execve -F euid=0 -k rootcmd

-w watches a path, -p wa for writes and attribute changes, -k tags events with a searchable key.

auditctl -l                       # active rules
auditctl -R /etc/audit/rules.d/audit.rules
ausearch -k identity              # find events by key
ausearch -m USER_LOGIN --start today
aureport --summary
aureport -au                      # authentication attempts

auditd's advantage over ordinary logs is that it records at the kernel boundary, so it captures what happened even when the application did not report it — including who read a file, which nothing else tells you.

Note it can generate enormous volume. Watch specific sensitive paths rather than everything, and size /var/log/audit accordingly; a full audit partition can, depending on configuration, halt the system by design.

On the exam

• LDAP is the directory; Kerberos is the authentication. SSSD connects a Linux host to both, and Winbind is the older equivalent.
• Kerberos fails on clock skew beyond about five minutes — check NTP first.
• PAM types are auth, account, password, session; controls are required, requisite, sufficient, optional.
• Password complexity is a PAM concern (pam_pwquality), not chage.
• Authentication events are in /var/log/secure (RHEL) or /var/log/auth.log (Debian).
• Forwarding logs to a remote host protects them from an attacker with root.
• logrotate needs postrotate reload or copytruncate, or the daemon keeps writing to the rotated file.
• auditd records at the kernel level; ausearch -k finds events by key.
• Polkit authorizes privileged actions requested by services, where sudo authorizes commands you run.