18.4 Configure Privileged Access

18.4 Configure Privileged Access

Quick Answer: Grant admin-style rights with sudo. On RHEL, add trusted users to the wheel group (often already allowed in the default sudoers policy). For custom rules, create drop-in files under /etc/sudoers.d/ and edit only with visudo (for example visudo -f /etc/sudoers.d/ops). Never hand-edit sudoers unsafely. Verify with id, groups, and sudo -l -U user.

What EX200 means by privileged access

The objective configure privileged access centers on sudo: controlled, audited elevation rather than sharing the root password. Typical tasks:

• “Allow alice to run any command as root via sudo.”
• “Add bob to the wheel group.”
• “Create a sudoers rule so deploy can run /usr/bin/systemctl restart httpd without a password.”
• “Ensure operators use sudo rather than direct root login.”

You must leave persistent policy in group membership and/or sudoers files that survive reboot.

How sudo works (practical model)

1. User runs sudo command.
2. sudo consults policy (/etc/sudoers and /etc/sudoers.d/*).
3. May prompt for the invoking user’s password (not root’s), depending on policy.
4. Runs the command with elevated privileges if allowed.
5. Logs the attempt (journal//var/log/secure depending on configuration).

sudo id
sudo -l                 # list your privileges
sudo -l -U alice        # list privileges for alice (as root)

The wheel group on RHEL

RHEL’s default /etc/sudoers typically contains a rule similar to:

%wheel  ALL=(ALL)       ALL

Meaning: members of group wheel may run all commands as any user (commonly used as all-root admin rights) on all hosts, usually with password.

Sometimes a NOPASSWD variant is present but commented:

# %wheel  ALL=(ALL)       NOPASSWD: ALL

Exam pattern A (most common): add the user to wheel.

sudo usermod -aG wheel alice
id alice
getent group wheel
# re-login as alice, then:
sudo -l
sudo whoami    # expect root

Because supplementary groups require a new session, test with a fresh login or:

sudo -u alice -i
# then sudo -l

Or from root:

sudo -l -U alice

Do not use usermod -G wheel alice without -a unless you intend to wipe other supplementary groups.

visudo: the only comfortable editor path

visudo locks the file, opens an editor, and syntax-checks before installing the change. A broken sudoers can lock out elevation—disastrous on a remote exam host.

sudo visudo                         # edit main /etc/sudoers
sudo visudo -f /etc/sudoers.d/ops   # edit/create a drop-in safely

# Validate a file without full interactive intent when supported
sudo visudo -cf /etc/sudoers
sudo visudo -cf /etc/sudoers.d/ops

If visudo reports syntax errors, fix them before saving/quitting. Do not force a broken file into place.

Editor selection

visudo uses EDITOR/VISUAL or a compiled default (often vi). Under time pressure:

sudo EDITOR=vim visudo -f /etc/sudoers.d/ops
# or
sudo EDITOR=nano visudo -f /etc/sudoers.d/ops

/etc/sudoers.d drop-ins (preferred for custom rules)

Best practice on RHEL: leave the distribution /etc/sudoers mostly alone; add drop-in files:

ls -l /etc/sudoers.d
sudo visudo -f /etc/sudoers.d/rhcsa-ops

Main sudoers includes the directory (typically):

#includedir /etc/sudoers.d

File naming and permissions

• Prefer simple names without dots and tildes that sudo might ignore (avoid names containing . in some policies—RHEL documents ignoring files with ~ or . in certain cases; use names like ops, deploy, 10-alice).
• Permissions should be 0440 (visudo usually sets safe modes).
• Owner root:root.

sudo ls -l /etc/sudoers.d
# -r--r-----. 1 root root ... ops

If you create a file with tee instead of visudo, fix mode and always validate:

echo 'alice ALL=(ALL) ALL' | sudo tee /etc/sudoers.d/alice
sudo chmod 440 /etc/sudoers.d/alice
sudo visudo -cf /etc/sudoers.d/alice

Prefer visudo -f so syntax check is automatic.

Sudoers rule syntax (enough for EX200)

Generic form:

who  where  =  (as_whom)  commands

Common practical lines:

# User alice may run anything as root (password required)
alice   ALL=(ALL)       ALL

# Group operators (% means group)
%operators  ALL=(ALL)   ALL

# NOPASSWD for all commands (powerful—only if task requires)
alice   ALL=(ALL)       NOPASSWD: ALL

# Narrow command list
deploy  ALL=(root)      /usr/bin/systemctl restart httpd, /usr/bin/systemctl status httpd

# NOPASSWD for specific commands only
deploy  ALL=(root)      NOPASSWD: /usr/bin/systemctl restart httpd

Use absolute paths for command restrictions (/usr/bin/systemctl, not bare systemctl). Find paths with command -v systemctl.

command -v systemctl
command -v dnf

Cmnd_Alias / User_Alias (awareness)

Cmnd_Alias SERVICES = /usr/bin/systemctl restart httpd, /usr/bin/systemctl reload httpd
deploy ALL=(root) SERVICES

Aliases help larger policies; for one-line exam tasks, a direct rule is enough.

wheel vs explicit user rule

If the default %wheel line is commented out (unusual but possible on customized images), adding to wheel silently does nothing until the rule exists—check:

sudo grep -E '^[^#].*wheel' /etc/sudoers /etc/sudoers.d/* 2>/dev/null
sudo visudo -c

Then either uncomment via visudo (carefully) or add an explicit drop-in rule.

Verifying privileged access

id alice
groups alice
getent group wheel
sudo -l -U alice

As the user (new session):

sudo -l
sudo id
sudo cat /etc/shadow | head -n 1    # only if policy allows ALL; proves elevation

Negative test for restricted rules: ensure disallowed commands fail.

Root account vs sudo

• Direct root login may be restricted over SSH (PermitRootLogin)—a security topic.
• su - switches to root if you know root’s password.
• sudo -i or sudo -s gives a root shell if policy allows.

EX200 “privileged access” configuration almost always means sudo policy / wheel, not re-enabling insecure root SSH.

sudo -i          # root login shell if permitted
sudo -s          # elevated shell
su -             # needs root password

Logging and troubleshooting

sudo journalctl -b | grep -i sudo | tail
sudo grep sudo /var/log/secure | tail

Common failures:

• User not in allowed group / no matching rule.
• Password wrong (user password).
• Command path not matching restricted rule.
• Typo in sudoers—visudo should have caught it.
• Testing from a session that has not refreshed group membership.

Exam workflows

Workflow A — Full admin via wheel

sudo usermod -aG wheel alice
id alice
sudo -l -U alice
# require alice to re-login for interactive group membership

Workflow B — Explicit ALL rule in sudoers.d

sudo visudo -f /etc/sudoers.d/alice
# add:
# alice ALL=(ALL) ALL
sudo visudo -cf /etc/sudoers.d/alice
sudo -l -U alice

Workflow C — Passwordless full sudo (only if required)

sudo visudo -f /etc/sudoers.d/alice-nopasswd
# alice ALL=(ALL) NOPASSWD: ALL
sudo -l -U alice

Workflow D — Limited command

command -v systemctl
sudo visudo -f /etc/sudoers.d/deploy
# deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart httpd
sudo -l -U deploy

Workflow E — Group-based operators group

sudo groupadd -f operators
sudo usermod -aG operators bob
sudo visudo -f /etc/sudoers.d/operators
# %operators ALL=(ALL) ALL
sudo -l -U bob

Workflow F — Repair broken sudoers (prevention)

Always edit with visudo. If you are still root in a session and validation fails, fix the drop-in with visudo -f immediately—do not log out while sudo is broken if you lack another root path.

Security hygiene on the exam

• Prefer least privilege when the task specifies exact commands.
• Do not set chmod 777 on sudoers files.
• Do not leave world-writable /etc/sudoers.d entries.
• Avoid NOPASSWD: ALL unless asked—it is easy to over-grant.
• Keep a root shell only as needed; finish configuration and verify as the named user.

Common traps

1. usermod -G wheel without -a removing other groups.
2. Editing /etc/sudoers with plain vim and introducing a syntax error.
3. Creating /etc/sudoers.d/alice.conf style names that may be ignored due to dots—prefer alice or 10-alice.
4. Forgetting absolute paths in command-limited rules.
5. Testing sudo in a session that lacks new wheel membership until re-login.
6. Assuming wheel works when the %wheel line is commented out.
7. Wrong permissions on drop-in files (must not be writable by non-root).
8. Writing rules for the wrong username (typo).
9. Using root’s password mental model—sudo wants user password by default.
10. Skipping sudo -l -U user verification.

Relationship to other sections

• 18.1 / 18.3: users and wheel/custom groups must exist first.
• 18.2: sudo password prompts follow user password state (locked users cannot sudo interactively).
• SSH objectives: remote admin often uses key login plus sudo.
• Service management: limited sudo rules often wrap systemctl for app operators.
• Security chapters: firewall and SELinux still apply to actions taken via sudo.

Section checkpoint

You should elevate with sudo, grant broad rights via the wheel group when appropriate, author custom policy under /etc/sudoers.d/ using visudo, write correct user/group and NOPASSWD/command rules with absolute paths, avoid destructive group replacements, and verify with id, getent group wheel, and sudo -l -U user. That fulfills EX200 privileged access configuration on RHEL 10.