I'm setting up an Ubuntu 11.04 server VM for use as a database server. It would make everyone's lives easier if we could have folks login using windows credentials and perhaps even make the machine work with the current AD-driven security we've got elsewhere.

The first leg of this was really easy to accomplish -- apt-get install likewise-open and I was pretty much in business. The problem I'm having is getting our admins into the sudoers groups -- I can't seem to get anything to take. I've tried:

a) usermod -aG sudoers [username]
b) adding the user names in several formats (DOMAIN\user, user@domain) to the sudoers file.

None of which seemed to take, I still get told "DOMAIN\user is not in the sudoers file. This incident will be reported."

So, how do I add non-local users to the sudoers?

9 Answers 9


I encounter this problem and here's my solution:

Edit /etc/sudoers: with the following entries

First check aduser using command id

#id <AD user>( #id domain\\aduser01 )

Results on mine:

SMB\aduser01@linux01:~/Desktop$ id smb\\aduser02
uid=914883676(SMB\aduser02) gid=914883073(SMB\domain^users) groups=914883073(SMB\domain^users),1544(BUILTIN\Administrators),1545(BUILTIN\Users),914883072(SMB\domain^admins)

getent passwd and gid NUMBERS doesn't work for me. DOMAIN\\domain^users works for me

%SMB\\domain^users ALL=(ALL) ALL

as we all know individual AD user works also

SMB\\<aduser01> ALL=(ALL) ALL
  • 1
    The %<domain>\\<group> method didn't work for me. I had to use %<group_with_underscores>, probably because I have my samba/winbind set with winbind use default domain and winbind normalize names set to yes.
    – mrtumnus
    Commented Sep 25, 2020 at 18:38

we have a long domain name with .local sufix,

neighter the

%domainname\\group ALL=(ALL) ALL

nor the

%domainname.local\\group ALL=(ALL) ALL


but if I only use the groupname like this:

%Domain^Admins ALL=(ALL) ALL

it works.

  • 1
    This was the solution that worked in the end. %Domain^Admins ALL=(ALL) ALL
    – mjp
    Commented Mar 29, 2017 at 14:51

I use the common command

sudo usermod -a -G sudo DOMAIN\username 

and replace DOMAIN\user with DOMAIN\\\username.


The problem with the other suggestions is that

  • they only work when you have access to the corporate LAN (or VPN)
  • you have to maintain the sudoers file on each and every computer all the time
  • as a bonus, they didn't work for me - at all

Instead, I wanted something that

  • caches both the credentials and the sudo access
  • is centrally managed

The actual solution is using SSSD and extending the AD schema. This way SSSD fetches sudo settings and user credentials periodically from AD and maintains a local cache of them. The sudo rules are then stored in AD objects, where you can restrict rules to computers, users and commands, even - all that without ever touching a sudoers file on the workstations.

The exact tutorial is way too long to explain here, but you can find the step-by-step guide and some scripts to help with automation here:



Grab the latest release of sudo, get the doc/schema.ActiveDirectory file, then import it (make sure to modify the domain path according to your domain name):

ldifde -i -f schema.ActiveDirectory -c "CN=Schema,CN=Configuration,DC=X" "CN=Schema,CN=Configuration,DC=ad,DC=foobar,DC=com" -j .

Verify it with ADSI Edit: open the Schema naming context and look for the sudoRole class.

Now create the sudoers OU on your domain root, this OU will hold all the sudo settings for all your Linux workstations. Under this OU, create a sudoRole object. To create the sudoRole object you have to use ADSI Edit, but once created, you can use Active Directory Users and Computers to modify it.

Let's assume I have a computer named foo32linux, a user called stewie.griffin and I want to let him run all commands with sudo on that comp. In this case, I create a sudoRole object under the sudoers OU. For the sudoRole you can use any name you want - I stick with the computer name since I use per-computer rules. Now set its attributes as follows:

  • sudoHost: foo32linux
  • sudoCommand: ALL
  • sudoUser: stewie.griffin

For commands you can use specific entries as well, like /bin/less or whatever.


Add to your /etc/sssd/sssd.conf, at least:

services = nss, pam, sudo

cache_credentials = True

SSSD refreshes its local cache with the updated rules every few hours, but the simplest way to test it is to just reboot the computer. Then log in with the AD user and check:

sudo -l

It should list all the related entires you added to that user and computer. Easy-peasy!

  • 1
    It may be long but, since links become invalid, it is a rule that the essential parts be included here, with the link for reference. Commented Nov 3, 2015 at 2:56
  • Actually, I added the essential parts, i.e. the concept. I could cherry-pick some other parts but they're useless without the rest and without understanding the big picture, so I fail to see the point. It'd do more harm than good.
    – bviktor
    Commented Nov 3, 2015 at 19:58
  • is a rule of AskUbuntu that someone who comes along needs to be able to look at your answer and solve their issue without going to an external site. Commented Nov 3, 2015 at 20:00
  • 1
    Added more relevant info.
    – bviktor
    Commented Nov 3, 2015 at 22:45

The best information I could find on the subject is here:

http://www.mail-archive.com/[email protected]/msg00572.html

It basically asks you to modify your /etc/sudoers file with the correct configuration to allow the people in your administrator's group on AD to have access to all privileges.

If you need to be selective and restrict by user, you can do that too. But it warns that you must make sure to find out what the user's name on the linux system is by using getend passwd command as shown.

  • Thanks really could not figure out where to look. For the record, DOMIAN\\username works for individuals. Commented Sep 30, 2011 at 18:38

Using Centify direct I have added domain user into /etc/sudoers file.

(Domain User) ALL=(ALL) ALL

  • This is the only method that worked for me.
    – JustAGuy
    Commented Oct 20, 2022 at 8:56

My preferred answer would be @bviktor's, but I am not yet an advanced enough domain administrator. None of the other answers above worked for me. I always got the same error message reported by OP. The format of the error message suggests to me that the entries in sudoers are case-sensitive, but I have never seen any discussion of this in the numerous posts I have read on this subject. For example, some posts suggest the group name "Domain^Admins", whereas others suggest "domain^admins". Neither worked in my case. On the DC (a Synology DS), the group is displayed as "Domain Admins", but on the client PC (running Ubuntu Studio 18.04), the command "id" returns the group as "domain admins".

What did work for me was to use:

sudo visudo

as described above to add a single user instead of a group:

[email protected] ALL=(ALL) ALL

to the end of sudoers.


sudo visudo then insert:

"%domain users" ALL=(ALL) ALL

worked for me on Ubuntu 20.04.2 LTS. It also worked with other arbitrary AD groups.


OK, none of these answers actually worked for me. The answer stating to modify the AD schema might be a nice thing if you have a large fleet of Linux machines in your estate but for a small number that's not practical.

What worked for me was this:

Create a sudo group in AD, add users to it. on your Linux machines (with an account that can sudo): create a file in /etc/sudoers.d

sudo touch /etc/sudoers.d/{yourdomain}

Now edit the sudoers file with visudo. Don't make any changes and exist the editor, it should prompt you to edit the new file in sudoers.d.

add this to that file:

%[email protected] ALL=(ALL:ALL) ALL

Save that file.

You should be good now. The members of the sudo group in your AD can use sudo on any machine with this new file.

After the user logs in while connected to the domain I have tested this with the computer (my laptop) disconnected from the domain and it still works as the group memberships are cached.

Note: Do not edit the new file directly, that will not work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .