🚨 Security Error Guide: 'user is not in the sudoers file' Privilege Escalation Failure

Exact Error Message

When a hardened host strips a user’s privilege escalation, sudo refuses to run the command and logs the attempt:

deploy is not in the sudoers file.  This incident will be reported.

A closely related variant appears when the account is allowed but the policy now demands re-authentication:

sudo: a password is required

Both come from the sudo security policy plugin (sudoers) and surface the moment privilege escalation is attempted, not when the user logs in.

What the Error Means

sudo consults /etc/sudoers and any drop-in files under /etc/sudoers.d/ to decide whether the invoking user may run a command as another user (usually root). “is not in the sudoers file” means no rule matched the user, the host, or the command. “a password is required” means a rule matched, but the policy requires a password and none could be supplied (for example a non-interactive context with no NOPASSWD rule).

These are operational failures engineers hit after tightening a host: removing a user from the sudo/wheel group, replacing a broad rule with a scoped one, or shipping a syntactically broken drop-in that sudo silently ignores. The “incident will be reported” line is just the default sudo lecture being logged to the auth journal; it is not evidence of an attack.

Common Causes

• Removed from the privilege group. The user was dropped from sudo (Debian/Ubuntu) or wheel (RHEL/Fedora) during a cleanup, so the group-based rule no longer applies.
• Broken sudoers.d drop-in. A new file under /etc/sudoers.d/ has a syntax error or wrong mode/ownership; sudo refuses to load it, discarding the rule it contained.
• Scoped rule no longer covers the command. Hardening replaced (ALL) ALL with a tight NOPASSWD: /usr/bin/systemctl rule, so any other command now demands a password or is denied.
• Lost NOPASSWD in automation. An Ansible/CI run that relied on passwordless sudo now hits a password is required because the NOPASSWD rule was tightened away.
• #includedir removed. Someone edited /etc/sudoers with vi instead of visudo and dropped the @includedir /etc/sudoers.d line, so all drop-ins are ignored.

How to Reproduce the Error

On a non-production test host, remove a user from the privilege group and attempt escalation:

sudo gpasswd -d deploy sudo      # Debian/Ubuntu; use 'wheel' on RHEL
su - deploy -c 'sudo -n id'

The escalation now fails:

deploy is not in the sudoers file.  This incident will be reported.

To reproduce the password variant, ship a rule without NOPASSWD and run non-interactively:

echo 'deploy ALL=(ALL) /usr/bin/systemctl' | sudo tee /etc/sudoers.d/deploy
su - deploy -c 'sudo -n systemctl status sshd'

sudo: a password is required

Diagnostic Commands

These read-only checks confirm what sudo thinks the user is allowed to do, without changing policy.

# What rules apply to this user, if any?
sudo -l -U deploy

# Confirm group membership (sudo / wheel)
id deploy
getent group sudo wheel

# Validate every sudoers file loads cleanly (read-only check)
sudo visudo -c

# Inspect drop-in files and their modes (must be 0440, root:root)
ls -l /etc/sudoers.d/

# Confirm the includedir directive is present
sudo grep -E 'includedir|@include' /etc/sudoers

# Read the auth journal for the denied attempts
sudo journalctl -t sudo --since '15 min ago'

sudo -l -U deploy is the single most useful command: it prints exactly which rules match (or “not allowed to run sudo”).

Step-by-Step Resolution

1. Confirm the user’s effective rules with sudo -l -U deploy. If it reports “not allowed to run sudo,” the user matches no rule; if it lists a command but you needed another, the rule is too narrow.

2. Check group membership. If the user should have broad sudo via the group, re-add them and have them re-login (group changes apply to new sessions):

   sudo usermod -aG sudo deploy    # or 'wheel' on RHEL/Fedora

3. Validate the sudoers tree with sudo visudo -c. A drop-in that fails to parse is skipped entirely. Fix any file it names — always edit drop-ins with sudo visudo -f /etc/sudoers.d/<file> so a syntax error cannot lock you out.

4. Fix drop-in permissions. sudo ignores files that are group/world-writable or not owned by root:

   sudo chmod 0440 /etc/sudoers.d/deploy
   sudo chown root:root /etc/sudoers.d/deploy

5. Restore NOPASSWD for automation only where genuinely needed, scoped as tightly as the workload allows:

   echo 'deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl' | sudo visudo -cf - && \
     echo 'deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl' | sudo tee /etc/sudoers.d/deploy

6. Re-test with sudo -l -U deploy and a real command. Keep a second root session open while editing sudoers so a mistake never locks you out.

Prevention and Best Practices

• Always edit sudoers with visudo (or visudo -f for drop-ins); it refuses to save a file that fails the syntax check.
• Keep one privileged root shell open in a separate session while changing privilege policy.
• Manage sudoers.d drop-ins as code (Ansible, etc.) with enforced mode 0440 and root:root ownership, and run visudo -c in CI before applying.
• Scope rules to specific commands and prefer group membership for human admins over per-user rules so audits stay simple.
• Reserve NOPASSWD for automation accounts and the narrowest command set possible.

Related Errors

• sudo: unable to open /etc/sudoers: Permission denied — wrong mode/owner on the main file.
• Missing sudo password / Incorrect sudo password — the Ansible-layer equivalents of the same escalation failure.
• pam_faillock: Authentication failure — account locked after failed attempts, covered in the security hardening guides.
• sudo: PAM account management error — a PAM module is denying the account even though sudoers allows it.

Frequently Asked Questions

Why does it say “This incident will be reported”? That is the default sudo lecture written to the auth journal whenever a non-permitted command is attempted. It is informational, not a sign of compromise.

I added the user to the sudo group but it still fails. Group membership only applies to new login sessions. Have the user log out and back in, or check with id in a fresh shell.

My drop-in file looks correct but is ignored. Run sudo visudo -c. A single syntax error or a mode other than 0440/owner other than root:root causes sudo to skip the file silently.

How do I keep a password is required out of automation safely? Add a scoped NOPASSWD rule for only the exact commands the automation runs, validated with visudo -cf -, rather than granting blanket passwordless sudo.

Can I just edit /etc/sudoers directly? Only via visudo. Direct edits risk dropping the @includedir line or saving invalid syntax, which can disable sudo for everyone.