Skip to main content

Turning AD admins as sudoers

Managing local user accounts across a fleet of Linux servers is a headache nobody needs. If you’ve already joined your Ubuntu machines to an Active Directory (AD) domain using SSSD, you can save yourself a lot of manual work by mapping AD groups directly to sudo privileges.

Setup

Avoid editing /etc/sudoers directly. If you mess up the syntax there, you could lock yourself out of sudo entirely. Instead, use a drop-in file in the sudoers.d directory.

Run this command to create the file safely:

sudo visudo -f /etc/sudoers.d/ad-admins

Add the following line:

%domain\ admins ALL=(ALL) ALL

What’s actually happening?

If you’re new to Linux/AD integration, the syntax might look a bit strange:

  • The % Symbol: This tells Linux to look for a group name. Without it, the system assumes “domain admins” is a single user.
  • The Backslash (\): Active Directory loves spaces; Linux terminals hate them. Since “Domain Admins” has a space, you have to “escape” it with a backslash so the system reads it as one string.
  • The ALL=(ALL) ALL Part: * The first ALL means this rule applies to any host.
    • The (ALL) means the user can run commands as any other user or group.
    • The final ALL means they can run any command.

SSSD Handshake

When an AD user types sudo, Ubuntu doesn’t find them in the local /etc/passwd file. Behind the scenes, a quick “handshake” happens:

  1. Sudo sees the % and asks the system: “Is this guy in the Domain Admins group?”
  2. NSS (Name Service Switch) knows to check SSSD because of your AD join configuration
  3. SSSD pings your Windows Server 2022 Domain Controller
  4. The DC confirms the membership
  5. Ubuntu grants access and asks for the AD password

Checking FQDN

If your configuration isn’t working, check your /etc/sssd/sssd.conf file for the use_fully_qualified_names setting.

  • If it’s set to True: You need to include your domain in the sudoers file, like this:
    %domain\ [email protected] ALL=(ALL) ALL
  • If it’s set to False: The short version (%domain\ admins) will work perfectly.

Why do this?

Setting this up takes two minutes, but the long-term benefits are huge:

  • Centralized Kill-Switch: When an admin leaves the team, you disable their account in AD. They instantly lose sudo access on every Linux box in your environment. No local accounts to delete.

  • Better Auditing: Instead of seeing “root” in the logs, /var/log/auth.log will show exactly which AD user ran a command. If someone accidentally deletes a config file, you’ll know exactly who was logged in at the time.

Royce Chua
Author
Royce Chua
Career changer with a background in physics and medicine, now working toward systems administration and network engineering. ISC2 Certified in Cybersecurity (CC), with Cisco CCNA studies in progress.

Related