Troubleshooting sudoers via ldap
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/[email protected]'
Oct 31 15:02:37 host sudo: pam_krb5[1508]: authentication succeeds for 'Aaron' ([email protected])
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/[email protected]'
Oct 31 15:02:52 host sudo: pam_krb5[1547]: authentication succeeds for 'Aaron' ([email protected])
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!
Solution 1:
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.
Solution 2:
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...