RunBook AcademyLinux

← All checklists in Linux

Before deploymentlinux-iam

Checklist: Identity readiness pre-deploy

21 items ·14 critical ·7 warn ·0 info

Use this checklist before promoting any host to production where central identity is in use. Any Critical failure must be resolved before deploy.

How to use this checklist

Run every command on the target host itself, and run them as root. Several read /etc/sssd/sssd.conf, which is mode 600 — and a check that returns nothing because it could not open the file looks exactly like a check that returns nothing because the host is clean.

An identity failure does not announce itself at deploy time. It surfaces the first time the directory is unreachable, when every login on the host fails at once and the account that was supposed to get you back in has never been used. That is why the caching, failover and break-glass items are Critical even though the host authenticates perfectly well without them today.

Four items have no command, because the evidence does not live on the host: the break-glass password sitting in the vault, an offline login actually having been exercised, PAM and SSSD errors arriving in the SIEM, and keytab rotation being scheduled somewhere you will still be looking in a year. Attach the vault reference, a SIEM search returning this host’s own auth events, and the schedule entry to the deploy ticket.

Before signing off, do the one test the commands cannot do for you: stop SSSD, log in on the console as the break-glass account, run sudo -v, start SSSD again, and record the date. That single exercise is what break-glass-tested and offline-tested are asking about.

Sign-off

Operator: _________________ Date: ___________
Reviewer: ________________ Date: ___________

Critical14 items

PAM stack reviewed for the service (login, sshd, sudo).
```
ls /etc/pam.d/
```
NSS is configured with the right modules (files, sss, etc.) in the right order.
```
cat /etc/nsswitch.conf
```
SSSD is running and configured for the central identity provider.
```
systemctl is-active sssd; sssctl domain-status
```
sssd.conf is mode 600 owned by root.
```
ls -l /etc/sssd/sssd.conf
```
More than one identity server is reachable for the domain, so losing one does not stop every login on the host. A single ldap_uri or ad_server is a single point of failure for authentication across the whole estate. The command prints any directive that names fewer than two servers, so no output is the pass condition; a host that finds its servers through SRV records has no such directive and passes here, which is why the discovered-server list is worth capturing too.
```
sudo awk -F= '/^[[:space:]]*(ldap_uri|ad_server|ipa_server|krb5_server)/ {n = split($2, a, ","); if (n < 2) print FILENAME ": " $0}' /etc/sssd/sssd.conf /etc/sssd/conf.d/*.conf 2>/dev/null; sudo sssctl domain-status <domain>
```
cache_credentials is enabled for every domain, and the cache lifetime (offline_credentials_expiration) is a recorded decision rather than an inherited default, so a provider outage degrades to cached logins instead of locking every user out at once. The command prints the file name only when no domain enables caching, so no output is the pass condition. A lifetime of 0 means the cache never expires - defensible, but only if somebody chose it.
```
sudo grep -L 'cache_credentials[[:space:]]*=[[:space:]]*[Tt]rue' /etc/sssd/sssd.conf
```
Kerberos is configured for the AD realm.
```
cat /etc/krb5.conf
```
NTP is configured and clock is within 5 minutes of KDC.
```
chronyc tracking
```
At least one local break-glass account exists, resolves from files rather than the directory, and has working sudo. Central identity failing is exactly when the account is needed, so nothing about it may depend on SSSD, pam_sss or the network. The second command answers the sudo half: "not allowed to run sudo" is a failure.
```
getent passwd breakglass; sudo -lU breakglass
```
Break-glass password is in a secure store (vault, sealed envelope).
Fallback users (root, breakglass) have known SSH keys.
```
ls /home/*/.ssh/authorized_keys
```
The break-glass account has been logged into successfully within the last quarter, on the console, with SSSD stopped. An account that has never been used is not a recovery path, it is an assumption - and the first time anyone discovers the password was never set is during the outage it was meant to solve. The command prints the last login; "Never logged in" is a failure.
```
sudo lastlog -u breakglass 2>/dev/null || sudo lslogins breakglass
```
Host is joined to the AD domain.
```
realm list
```
Sudo allowed for the AD admin group.
```
realm permit --list
```

Warning7 items

pam-auth-update has been run for the latest profile.
```
pam-auth-update --dry-run
```
SSSD offline mode tested: cached credentials work.

SSH is configured for GSSAPI authentication.

grep -E 'GSSAPIAuthentication' /etc/ssh/sshd_config

PAM and SSSD errors are logged to the central SIEM.
Host keytab rotation is scheduled.
Password complexity policy is enforced (pam_pwquality).
```
grep pwquality /etc/pam.d/common-password
```
Account lockout policy is enforced (pam_faillock).
```
grep faillock /etc/pam.d/
```