Allow AD Groups to SUDO in Fedora

active-directorydomainfedorasssdsudo

I'm adding some Fedora 20 workstations to our Windows 2003 domain. I've successfully joined the domain with the boxes, and can login with domain accounts.

Now I'm trying to allow the default AD group Enterprise Admins to use SUDO, however whatever I do, it seems that the group cannot be found (or at least it tells me my user account is not in the sudoers file)

Structure of the OU (default really):

mydomain.local
- Builtin
- Computers
- DCOM-Users
- DOmain Controllers
- ForeignSecurityPrincipals
- CompanyName
  - Management
  - Accounting
  - Admins
  - SysAccounts
  - CustomerService
  - Warehouse
- Users

I used realmd and sssd to join the domain, and am trying to allow sudo to groups located under the Users OU, but would also like to add some from the CompanyName --> Admins OU/Sub-group as well.

I'm currently trying this with no luck (in /etc/sudoers)

%MYDOMAIN\\Enterprise^Admins ALL=(ALL) ALL

I've also tried variations as well, such as:

%MYDOMAIN\\Users\Enterprise^Admins ALL=(ALL) ALL
%Enterprise^Admins@mydomain.local ALL=(ALL) ALL

etc… nothing seems to be working. Even after reboots, and/or systemctrl restart sssd.

If i explicitly add my domain account to the /etc/sudoers file, it works no problem.

myuser@mydomain.local ALL=(ALL) ALL

There are a few resources that seem to indicate it should be possible to add AD groups to sudoers, however so far none of them have worked for me:

http://funwithlinux.net/2013/09/join-fedora-19-to-active-directory-domain-realmd/

https://serverfault.com/questions/387950/how-to-map-ad-domain-admins-group-to-ubuntu-admins

https://help.ubuntu.com/community/LikewiseOpen

Best Answer

Several months after you asked but the correct answer is that you remove all domain information from the group. All the information is set and extracted by SSSD automatically.

The only flaw I see in some of your examples is that you escaped the space with a ^.

An AD group of Enterprise Admins would have a sudoers line that starts with

%Enterprise\ Admins

For example, if your domain is example.com, then the sudoers line looks like

%Enterprise\ Admins@example.com ALL=(ALL) ALL

You can verify this by looking calling getent on the group.

getent group Enterprise\ Admins

Related Solutions

Sudo permissions by ldap groups via nslcd

Sorry about the long post, but it seems to work. I just had a typo in sudoers file. Took me a bit long to find it though, since the syntax was still correct but I couldn't execute any commands.

However, it's working now.

 // Problem was that one ALL was missing, allowing me to execute no root cmds.
 %group1 ALL=(root) !/bin/su

 // Fixed it
 %group1 ALL=(root) ALL, !/bin/su

Update: I realized a bit late but I also changed the following in /etc/nsswitch.conf

sudoers:        ldap files

I just didn't think it was the fix because I still had the above mentioned sudoers typo.

Problem solved :)

Ubuntu – Configure SSSD with Realmd for Sudo and dyndns_update

If you want Active Directory to manage sudoers, you have to load a specialized schema into AD and then create your rules using a tool like ADSI Edit. This walkthrough worked for me on Ubuntu 14.04. The highlights are:

Import schema.ActiveDirectory
Create rules following the sudoers-ldap manpage
Update etc/nsswitch.conf to include sss among the entries on the sudoers = line
Update etc/sssd/sssd.conf to include:
- sudo among the entries on the services = line
- an empty [sudo] section (no configs are required, but Redhat asserts that this triggers the proper configuration of sudo support)
- a line like sudo_provider = ad (sssd docs on pagure.org claim sudo provider is enabled by default for ldap, ad and ipa so this may be optional)

When I repeat this process for 16.04 (i.e. same AD rules as 14.04), I'm actually having other issues. Apparently, this is not uncommon. It's possible that there's a bug in the version of sudo included in 16.04.

In principle, manually upgrading to the latest should resolve this issue.
The regular sudo package (not sudo-ldap) is the right package if you want SSSD (and not sudo) to manage the ldap connection. Specifically, installing sudo-ldap produced no logs in sssd_sudo.log while the regular sudo package did.
While sssd_sudo is now showing Returning 2 rules for [<user>@<domain>], sudo -l is still responding with Sorry, user <user>@<domain> may not run sudo on <host> so there may be other issues needing resolved.

My situation may not be typical, however, as I'm having additional issues that don't appear to be common. For example, I had issues running realm join that were resolved using workarounds from this Server Fault question.

If you found your way here due to realmd/sssd/sudo issues in 16.04, here are some other reported problems that may be helpful (not necessarily directly related to the OP's issue):

IPA host netgroup issue (more info on the free-ipa users list)
There's a known issue with realmd dependency resolution. As mentioned in the discussion, installing packagekit resolves for many (including us). There may be a separate issue with the version in 16.04.

We're evaluating 16.04 for upgrade so we may put this on the back burner, but hopefully our legwork helps others.

Best Answer

Related Solutions

Sudo permissions by ldap groups via nslcd

Ubuntu – Configure SSSD with Realmd for Sudo and dyndns_update

Related Question