[Samba] [Solved] Samba 4 sudoers

John Gardeniers jgardeniers at objectmastery.com
Fri Apr 22 00:37:00 UTC 2016


Attached are my notes. I believe I have all the steps in there and 
correct but if someone (Sketch?) cares to test them and let me/us know 
the results it would be appreciated. Good luck.

As Sketch suggests, it would be good to get this added to the Samba wiki 
but only *after* someone independently verifies it as correct. We don't 
need yet another faulty set of instructions published.

regards,
John


On 21/04/16 23:23, Sketch wrote:
> On Thu, 21 Apr 2016, John Gardeniers wrote:
>
>> Good news, I now have this working. Once I finish writing my notes 
>> I'll make them available to whoever might want them.
>
> Good to hear.  I tried to get his working by following some of the 
> online docs and the sudoers docs, and never did get it to work. It'd 
> be great if someone could put this up on the Samba wiki when it's 
> published too.
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

-------------- next part --------------
Sudoers LDAP
============

Every tutorial I found on this topic is either incomplete, inaccurate or even both!
These notes describe what worked for me. No guarantees can be given that it will work for you.

Objective
=========
Use Samba 4 Active Directory to centrally manage sudo rights, in addition to users and groups. On the client end this will be handled by sssd, which makes the system more resilient by virtue of cacheing.

Prerequisites
=============
* A fully functional Samba 4 AD domain
* At least one Windows domain member from which to administer the domain
* Functioning sssd on the Linux clients, which are not required to be joined to the domain

Not required on the Linux clients:
* Samba
* Openldap

Although Samba may be installed and working, these notes assumes user authentication is handled by sssd, rather than winbind.

Note: On the test system I did install the openldap-clients while trying to get this working but I don't believe it's a requirement.

On the Samba side
=================
We need to import the sudoers schema extension into AD. By default the import facility is disable. Turn it on by adding "dsdb:schema update allowed = Yes" to the global section of smb.conf and reload Samba. This may or may not be needed on all domain controllers. I don't know because my test environment only had one DC.
* Obtain the file "schema.ActiveDirectory" from the doc directory of the sudo source and copy it to the Windows domain member
* On the Windows domain member, run "ldifde -i -f schema.ActiveDirectory -c dc=X dc=your_domain,dc=net", adjusting "dc=your_domain,dc=net" as appropriate but leave the "dc=X" part as it is

If you receive any errors about permissions try restarting, rather than just reloading, Samba.

* Using ADUC or ADSI Edit, create a new OU named "sudoers" in the domain root (if you create the sudoers OU at a different point in the tree adjust the DN as necessary in the sssd config below)
* Using ADSI Edit, create a new sudoRole object in the sudoers OU and name it "default"
** Give the "sudoOption" property a value of "!authenticate;env_keep+=SSH_AUTH_SOCK"

Without the "!authenticate" part I found I would sometimes, such as after a reboot, be prompted for a password when running a sudo command. The way I see it, the user has already been authenticated, so there should be no need for further authentication when running a sudo command.

IMPORTANT (This is one of the bits missing from the various tutorials)
=========
It's important that the ldap bind user (here I'll use the account "ldapauth", which is a normal user account) has read permission on the sudoers OU and all child members. To set this:
* Grant ldapauth read permission on the sudoers OU and click Apply
* Now go into the advanced security options and change ldapauth's "Apply to" from "Ths object only" to "This object and all descendent objects"

Creating sudo rules
===================
Sudo rules are objects of the type "sudoRole" within the sudoers OU. As there is no obvious way to create a rule from ADUC I use ADSI Edit to initially create them and then edit them using ADUC. The properties are set in the Attribute Editor tab.
So far the only fields I needed to edit are, other fields may be required for other environments:
* description (optional but desirable)
* sudoCommand (may list more than one command)
* sudoHost (one or more hosts or "ALL")
* sudoUser (can be any combination of users or groups, with group names prefixed by "%")

On the Linux client side
========================
Edit /etc/sssd/sssd.conf and
* Add sudo to the services in the "[sssd]" section (e.g. services = nss,pam,sudo)
* Add an empty "[sudo]" section
* Add "ldap_sudo_search_base = OU=sudoers,dc=your_domain,dc=net" to the "[domain/...]" section, adjusting to suit your domain name
* Restart sssd

Edit /etc/nsswitch.conf and
* Add/edit "sudoers: files sss"

Testing
=======
Log on as as a user who you have specified in one or more of the sudo rules and run "sudo -l". This should produce a list of sudo commands that may be run. If not, review the steps above.


More information about the samba mailing list