How to remove sudo access from a user

Removing sudo access matters when an account changes roles, leaves a team, or keeps privileges that no longer match its responsibilities. A stale administrator group membership or /etc/sudoers.d rule can still allow root commands after ordinary file, application, or project access has already been removed.

Most Linux systems grant sudo through both group membership and sudoers policy. Ubuntu and Debian commonly use the sudo group, RHEL-like systems commonly use wheel, and local drop-ins under /etc/sudoers.d may grant narrower or passwordless rules to one account. Checking id and sudo -l -U first shows whether the account is privileged through a group rule, an explicit user rule, or both.

Keep another administrator session or console path available before changing policy. Removing a group membership with gpasswd changes the account database, while visudo protects sudoers edits from syntax errors; run a full visudo –check before relying on the change. Existing login sessions can retain the group list they had at login, so terminate or replace active sessions when immediate revocation is required.

1. Confirm that another administrator account still has working sudo access.

   $ sudo -l
   User admin may run the following commands on server:
       (ALL : ALL) ALL

   Do not remove the last working administrator path. Keep a root console, break-glass account, or separate administrator session available until the final check passes.

2. Check the target account and its current groups.

   $ id sgremove
   uid=1001(sgremove) gid=1001(sgremove) groups=1001(sgremove),27(sudo)

   The sudo group grants administrator access on many Ubuntu and Debian systems. Replace sudo with wheel when that is the administrator group on the target host.

3. List the target account's effective sudo rules.

   $ sudo -l -U sgremove
   User sgremove may run the following commands on server:
       (ALL : ALL) ALL
       (ALL : ALL) NOPASSWD: /usr/bin/id

   sudo -l -U lists another user's privileges when the caller is root or otherwise allowed to list that account's policy.

4. Locate explicit sudoers entries for the target account.

   $ sudo grep --recursive --line-number sgremove /etc/sudoers /etc/sudoers.d
   /etc/sudoers.d/90-sgremove-id:1:sgremove ALL=(ALL:ALL) NOPASSWD: /usr/bin/id

   Do not paste sudoers contents into tickets or chat if they reveal sensitive account names, host aliases, command paths, or delegation policy.

5. Remove a dedicated sudoers drop-in that belongs only to the target account.

   $ sudo rm /etc/sudoers.d/90-sgremove-id

   Do not delete a shared sudoers file. If the file contains other users, groups, aliases, or Defaults, open it with a command such as sudo visudo -f /etc/sudoers.d/90-admins and remove only the target account's rule.

6. Remove the target account from the administrator group.

   $ sudo gpasswd --delete sgremove sudo
   Removing user sgremove from group sudo

   Use the actual group name from the earlier id output, such as wheel on hosts where wheel grants sudo access.

7. Validate the full sudoers policy after the removal.

   $ sudo visudo --check
   /etc/sudoers: parsed OK

   A full check covers the main /etc/sudoers file and included policy files. Fix any reported syntax, ownership, or permission problem before closing the administrator session.

8. Confirm that the account no longer belongs to the administrator group.

   $ id sgremove
   uid=1001(sgremove) gid=1001(sgremove) groups=1001(sgremove)

9. Verify that sudo no longer grants privileges to the account.

   $ sudo -l -U sgremove
   User sgremove is not allowed to run sudo on server.

   This denial is the success state for the removed local policy. If a central identity provider or LDAP sudoers source also grants sudo, remove that external rule and repeat the privilege listing.

10. Terminate active sessions when the removal must take effect immediately.

    $ sudo loginctl terminate-user sgremove

    This signs the account out on systemd-based hosts and can stop user services or running jobs. Skip this step when the access change is scheduled and current sessions should not be interrupted.