Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

The good news is that I got sudoers via ldap working on Red Hat Directory Server. The package is sudo-1.7.2p1. I have some LDAP/Kerberos users in an LDAP group called wheel, and I have this entry in LDAP:

# %wheel, SUDOers, example.com
dn: cn=%wheel,ou=SUDOers,dc=example,dc=com
cn: %wheel
description: Members of group wheel have access to all privileges.
objectClass: sudoRole
objectClass: top
sudoCommand: ALL
sudoHost: ALL
sudoUser: %wheel

So, members of group wheel have administrative privileges via sudo. This has been tested and works fine. Now, I have this other sudo privilege set up to allow members of a group called Administrators to perform two commands as the non-root owner of those commands.

# %Administrators, SUDOers, example.com
dn: cn=%Administrators,ou=SUDOers,dc=example,dc=com
sudoRunAsGroup: appGroup
sudoRunAsUser: appOwner
cn: %Administrators
description: Allow members of the group Administrators to run various commands
 .
objectClass: sudoRole
objectClass: top
sudoCommand: appStop
sudoCommand: appStart
sudoCommand: /path/to/appStop
sudoCommand: /path/to/appStart
sudoUser: %Administrators

Unfortunately, members of Administrators are still refused permission to run appStart or appStop:

-bash-3.2$ sudo /path/to/appStop
[sudo] password for Aaron:
Sorry, user Aaron is not allowed to execute '/path/to/appStop' as root on host.example.com.

-bash-3.2$ sudo -u appOwner /path/to/appStop
[sudo] password for Aaron:
Sorry, user Aaron is not allowed to execute '/path/to/appStop' as appOwner on host.example.com.

/var/log/secure shows me these two sets of messages for the two attempts:

Oct 31 15:02:36 host sudo: pam_unix(sudo:auth): authentication failure; logname=Aaron uid=0 euid=0 tty=/dev/pts/3 ruser= rhost=  user=Aaron
Oct 31 15:02:37 host sudo: pam_krb5[1508]: TGT verified using key for 'host/host.example.com@EXAMPLE.COM'
Oct 31 15:02:37 host sudo: pam_krb5[1508]: authentication succeeds for 'Aaron' (Aaron@EXAMPLE.COM)
Oct 31 15:02:37 host sudo:    Aaron : command not allowed ; TTY=pts/3 ; PWD=/auto/home/Aaron ; USER=root ; COMMAND=/path/to/appStop

Oct 31 15:02:52 host sudo: pam_unix(sudo:auth): authentication failure; logname=Aaron uid=0 euid=0 tty=/dev/pts/3 ruser= rhost=  user=Aaron
Oct 31 15:02:52 host sudo: pam_krb5[1547]: TGT verified using key for 'host/host.example.com@EXAMPLE.COM'
Oct 31 15:02:52 host sudo: pam_krb5[1547]: authentication succeeds for 'Aaron' (Aaron@EXAMPLE.COM)
Oct 31 15:02:52 host sudo:    Aaron : command not allowed ; TTY=pts/3 ; PWD=/auto/home/Aaron ; USER=appOwner; COMMAND=/path/to/appStop

The questions:

  • Does sudo have some sort of verbose or debug mode where I can actually watch it capture the sudoers privilege list and determine whether or not Aaron should have the privilege to run this command? (This question is probably independent of where the sudoers database is kept.)
  • Does sudo work with some background mechanism that might have a log level I could turn up?

Right now, I can't fix a problem I can't identify. Is this an LDAP search failure? Is this a group member matching failure? Identifying why the command fails will help me identify the fix...

Next step: Recreate the privilege in /etc/sudoers, and see if it works locally...

Cheers!

share|improve this question

2 Answers 2

up vote 1 down vote accepted

You can debug sudo/LDAP by setting SUDOERS_DEBUG debug_level in your sudo LDAP config (probably /etc/sudo-ldap.conf). The value of debug_level can be 1 or 2. See http://www.sudo.ws/sudo/sudoers.ldap.man.html for details.

share|improve this answer
    
Gah! And I knew that! In RHEL, the setting is in /etc/ldap.conf. Thanks for the reminder! –  dafydd Nov 2 '12 at 1:03

First, the not-an-answer answer: I neglected to put any sudoHost attributes in my %Administrators entry for the LDAP sudoers branch. I caught this in a flash of intuition.

Second, the almost-an-answer answer: Had I done a better job of RTFM on the sudo man page, I would have seen sudo -l, which would have told me whether or not sudo was seeing the privileges. Once I knew the privilege list was being returned properly, I could have checked that off of the list of possibilities.

Having said those things, I would still like to know if sudo privilege checking has any debug entry points. So, I've solved my problem, but not answered my question...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.