Microsoft Active Directory can be used to manage users on Linux hosts on the network by having the hosts join the domain with the help of SSSD.

Many system administrators do not know that it's actually possible to manage SUDO permissions on Linux hosts from the Active Directory Domain Controller (AD DC).

In this article, I will provide a step-by-step guide on how to create and implement SUDO rules that are centrally managed on an on-prem Windows Server 2022 and applied to a Ubuntu server.

LDAP (Lightweight Directory Access Protocol) stores Informational objects in a hieratical system similar to a file system. All these objects are based on classes, similar to classes in object-oriented programming. To verify that e new object or modification to an existing object adheres to the class specification, a schema is used.

This schema has fields that are required and fields that are optional.

The SUDO project has ready-made LDAP schemas that can be used to create SUDO role objects that can be stored on LDAP servers. They even got a schema specifically tailored for Active Directory. This is located at the official SUDO GitHub repository.

This can be directly downloaded to the Domain Controller with PowerShell, using wget:

To add the SUDO schema defined in the file to the domain controller, run this command:

Because the schema was successfully added to the domain controller, we can proceed to add SUDO role objects to Active Directory.

To make it as easy to manage the SUDO roles as possible I decided to create a new OU (Organizational Unit) at the root of the domain directory. This was done by launching the ADSI Editor (Active Directory Interface Editor) from Server Manager.

The ADSI editor is a more fully-featured LDAP object editor that makes it possible to manage LDAP objects that are not managed as frequently as User, security group, and Group Policy Objects.

Connected to the Domain Controller and create a new OU by right-clicking on the top OU and selecting New > Object... from the contextual menu.

From the list of classes, choose the organizationalUnit class, and give it an appropriate name.

I gave my OU the name haxorSudo to adhere to my own naming convention on the Domain.

Next, a SUDO role object could be added to the OU. This is done by right-clicking on the haxorSudu OU that was just created and selecting New > Object... from the contextual menu.

Now, select the sudoRole class from the list, and give it a name that makes it easy to distinguish from other SUDO roles.

In this example I gave it the name "webDeveloper - restart Nginx" to reflect that this SUDO role gives members of the webDeveloper security group permissions to restart Nginx.

To define the rules, right-click on the SUDO role object, and select Properties from the contextual menu.

Scroll down to the attributes that start with "sudo" to set the needed values.

If you are familiar with the visudo command or more specifically the syntax in the /etc/sudoers file on Linux hosts, these parameters should be somewhat intuitive. Each SUDO role object corresponds to a line in the sudoers file. So you want to add several rules, you must add several SUDO role objects to AD.

In the example SUDO role above, I limited the rule to only apply to the host www.haxor.local, which is the webserver on my lab domain. I also limited the role to only allow the members of webDevelopers security group to be able to run "systemctl restart nginx" command as the root user. By doing this the SUDO role makes use of the rule of least privilege

The LDAP object is similar to this line in a sudoers file:

Note: SSSD will translate the webDevelopers security group in AD to webdevelopers@haxor.local on the Linux hosts.

To create an all-powerful god-like SUDO role on the domain that can run ALL commands as ALL users on ALL hosts in the domain similar to this standard line for members of the "sudo" user group in Debian based distributions like Ubuntu, or the "wheel" user group in RedHat based distributions add a SUDO role object like this:

The SUDO role object above is similar to this line in the sudoers file:

Now that AD has LDAP entries for SUDO roles, the only thing left to do is to configure the Linux hosts on the domain to query the domain controller for SUDO role information.

A prerequisite for this to function is that the Linux host has to be joined to the Domain. The rest of this guide assumes that the host has joined the Domain by using SSSD (System Security Services Daemon).

When the host has joined the Domain, only two configurations need to be checked. First, the "Network Service Switch" has to be configured. Make sure that the line with sudoers include the string "sss" like below:

This should have been added by default when SSSD was installed. But I still recommend verifying the configuration.

Next, the SSSD config file needs to be configured to include the SUDO service:

This last config file needs to be configured because it was not configured to include the SUDO service when SSSD was installed on the system.

To apply the changes restart SSSD:

Now you can sign in with a domain account that is a part of a SUDO-enabled user group in AD, and verify the configuration.

The output above confirms that the user eve@haxor.local, which is a part of the user group webdevelopers@haxor.local is able to access the SUDO role defined on the AD DC.

Congratulations! You now have a fully integrated Linux host, that has SUDO roles and permissions managed by your Active Directory Domain 🎉

Since users, user groups, and other data from the domain controllers are cached by SSSD you will probably need to clear the cache to quickly see the changes that affect users on your Linux hosts.

To clear the cache simply stop SSSD, delete the cached files, and start SSSD.

If you now authenticate as a domain user on the Linux host, the changes will be synced.