In my previous post I explained how you could, in just a few steps, join an Ubuntu machine into an Azure Active directory domain. After a lot of online and offline feedback (Thanks everyone!) I thought it would be time for a follow-up post. This time I’m addressing centralized management of sudo users. Meaning who can execute commands as sudo on defined linux desktops (in my case Ubuntu) , although it’s exactly the same on a server class installation.
My setup is very straightforward and is basically a copy of my previous post. I’ve installed one Windows Server 2016 domain controller in the domain “corp.bitsofwater.com” and joined a Ubuntu 18.04 LTS to that domain. Users from that domain can happily login to the Ubuntu workstation using their domain credentials. In this post we’ll have to deal with two users:
- Domain Administrator: Administrator
- Local Root user: Superuser
So our mission will be to configure the domain and Ubuntu desktop in such a way that members of a domain security group will be able to use sudo once logged in on the Ubuntu desktop.
The first task at hand is to make Active Directory capable for supporting centralized sudo management. Out of the box AD can’t be used for this because of the simple fact that it’s missing the attributes in the AD schema. The cool part is that the people that created and maintain sudo made it very easy for us to extend active directory with the appropriate attributes. First we need to download the latest sudo package from https://www.sudo.ws/. Click on “download” and get the latest package. In my case I’ve created this blog based on the 1.8.23 release. Once the package is extracted (7Zip is an excellent client on Windows for that) you end up with a folder that contains the file that we need. Browse to the doc folder.
There should be a file named “schema.ActiveDirectory“. This file is used to extent the Active Directory Schema to include the sudo attributes that we will be using. In your Active Directory environment, login to the domain controller that has the schema master role with an account that has the privileges to extent the schema. In my case I’ll just use the all-powerful Administrator account. At a minimum copy the “schema.ActiveDirectory” file to that server and open up an elevated command prompt. In the command-prompt browse to the location where you stored the schema extension file. Execute the following “ldifde.exe” command, leave the command-line exactly as is, only replace the latter part of the line to reflect your domain structure.
ldifde -i -f schema.ActiveDirectory -c dc=X dc=corp,dc=bitsofwater,dc=com
Open “adsiedit.msc” and connect to the “Default naming context“. In the root create a new organization unit and give it a name “sudoers“. This is the default location sudo will look for user defined rules in AD, don’t worry, I’ll show you later on in this post how you can change that.
What we need to do next is create a new object that will contain our attributes. On the organizational unit that you just created, right click and select “new-object“. In the next window select “sudoRule”.
If you don’t see the object class immediately that probably means that the class hasn’t been replicated to your DC yet, just give it some time. In the next screen use the name “default”. In my experience it really doesn’t matter what name you give the object. I tend to use a more descriptive name like, desktops or servers. That makes it a bit more clear on what purpose the object serves. At the last screen click finish to create the “sudoRole” object.
Now we need to edit the attributes of the default object we just created. This way we can configure the behavior of the sudo commands into what can (or cannot) be executed on the Linux host. Select properties on the “cn=default,ou=sudoers” object. Just for testing purposes, we’re going to enable all sudo privileges on all machines. Edit these attributes:
- sudoCommand: ALL
- sudoHost: ALL
- sudoUser: ALL
Next, login at the ubuntu machine as a root user, in my case “SuperUser”, start a terminal, open the bash shell as sudo and restart the sssd service with “systemctl restart sssd”
to test the configuration, use “su administrator”, enter the password. Now do “sudo bash“, “sudo -l“, or whatever sudo command you would like to use. After entering your password you should be having the ability to execute as sudo.
Easy right! Now we have the basics covered, here are some hints on tuning it a bit here and there.
Domain Security Groups
In any infrastructure of some size it’s highly unlikely that you will have many individual users that will be listed on the “sudoUser” attribute. Instead having a group listed there makes more sense. Instead of a user that can be set by just using the “sAMAccountName” a group will need to contain a % sign at the beginning. So suppose we want to copy the behavior of Windows and add the “Domain Admins” to every machine (Which is a terrible idea btw!) the sudoUser attribute would look like this:
- sudoUser: %Domain Admins
Note! Although you would expect there to be an escape character (\) after “%Domain” to cope with the space, this seems to be completely handled by the sssd service. Very cool if you ask me!
Note! As you can see there’s also a possibility to use wildcard characters for the attributes, (See sudoHost). There are more options available listed here:
By default sudo will look for an organizational container with the name “sudoers” in the root of the directory. There is however a way to tell sudo to look elsewhere. For example if you have two OU’s assigned to different groups, you could use that setup to apply different sudo configurations. So let’s assume we have the “OUa” and “OUb”. The Ubuntu machine in our example belongs to OUb and we want to point it to a OU named Linux that resides within “OUb”.
Actually it’s not hard to do. Create the organizational structure I described and create a new “sudoRole” object in there. On the Ubuntu host, open the file “etc/sssd/sssd.conf” as sudo. Add the following line under the [domain/YourDomain]:
ldap_sudo_search_base = ou=linux,ou=OUb,dc=corp,dc=bitsofwater,dc=com
restart the sssd service and you are ready to go.
Sometimes the caching mechanism from the sssd service is so persistent that the entries for sudo users remain, even after several reboot. One command in particular has helped me to clear the cache is:
If that doesn’t work, stop the sssd service and delete the database files in “/var/lib/sss/db“.
Just remember that the cache receives a full update every six hours and an incremental one every 15 minutes. But that really doesn’t help when the cache is broken. Those values can be altered by setting:
Sometimes, specially between sssd versions or linux distributions, not all the files are appropriately configured. For example I noticed significant differences between Ubuntu and Redhat. Make sure that these two files are configured as shown here:
sudoers: files sss
services = nss, pam, sudo
I hope that this was useful to you! As always, you can leave comments, remarks or questions below or send me a direct message.