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.
Making it possible to create SUDO role objects
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:
wget https://raw.githubusercontent.com/sudo-project/sudo/main/docs/schema.ActiveDirectory -O schema.ActiveDirectory
To add the SUDO schema defined in the file to the domain controller, run this command:
ldifde -i -f schema.ActiveDirectory -c dc=HAXOR,dc=LOCAL Connecting to "DC1.haxor.local" Logging in as current user using SSPI Importing directory from file "schema.ActiveDirectory" Loading entries............. 12 entries modified successfully. The command has completed successfully
Because the schema was successfully added to the domain controller, we can proceed to add SUDO role objects to Active Directory.
Create LDAP entries for SUDO permissions
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.
Opening the ASDI 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.
Create a new object in the root of the Domain.
From the list of classes, choose the organizationalUnit class, and give it an appropriate name.
Create new OU, by selecting the correct class.
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.
Create a new object in the haxorSudo OU.
Now, select the sudoRole class from the list, and give it a name that makes it easy to distinguish from other SUDO roles.
Create a new SUDO role object, by selecting the sudoRole class
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.
Add SUDO role parameters to the SUDO role object.
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:
... %email@example.com www.haxor.local=(root) /bin/systemctl restart nginx ...
Note: SSSD will translate the webDevelopers security group in AD to firstname.lastname@example.org 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:
SUDO role that can do anything on any host as any user.
The SUDO role object above is similar to this line in the sudoers file:
... %email@example.com ALL=(ALL:ALL) ALL ...
Configure Linux host get SUDO roles from Active Directory
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:
sudo vim /etc/nsswitch.conf
... sudoers files sss ...
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:
sudo vim /etc/sssd/sssd.conf
... services = nss, pam, sudo ...
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:
sudo systemctl 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.
sudo -l ... User firstname.lastname@example.org may run the following commands on www: (root) /bin/systemctl restart nginx
The output above confirms that the user email@example.com, which is a part of the user group firstname.lastname@example.org 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 🎉
Clear SSSD cache
Clear cache to be able to get recent changes to SUDO roles
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.
sudo systemctl stop sssd sudo rm -rf /var/lib/sss/db/* sudo systemctl start sssd
If you now authenticate as a domain user on the Linux host, the changes will be synced.