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!
