Solução de problemas sudoers via ldap

Question

A boa notícia é que eu tenho sudoers via ldap funcionando no Red Hat Directory Server. O pacote é sudo-1.7.2p1. Eu tenho alguns usuários LDAP / Kerberos em um grupo LDAP chamado wheel, e eu tenho essa entrada no 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

Assim, os membros do grupo wheel têm privilégios administrativos via sudo. Isso foi testado e funciona bem. Agora, eu tenho esse outro privilégio sudo configurado para permitir que membros de um grupo chamado Administradores executem dois comandos como o proprietário não-raiz desses comandos.

# %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

Infelizmente, os membros dos Administradores ainda têm permissão para executar appStart ou 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 mostra-me estes dois conjuntos de mensagens para as duas tentativas:

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

As perguntas:

• O sudo tem algum tipo de modo verboso ou de depuração onde eu posso realmente assisti-lo capturar a lista de privilégios sudoers e determinar se Aaron deve ou não ter o privilégio de executar este comando? (Esta questão é provavelmente independente de onde o banco de dados sudoers é mantido.)
• O sudo funciona com algum mecanismo em segundo plano que pode ter um nível de registro que eu possa encontrar?

Neste momento, não posso resolver um problema que não consigo identificar. Esta é uma falha de pesquisa LDAP? Esta é uma falha de correspondência do membro do grupo? Identificar por que o comando falha me ajudará a identificar a correção ...

Próxima etapa: Recrie o privilégio em / etc / sudoers e veja se ele funciona localmente ...

Felicidades!

    

Answer 1

Você pode depurar o sudo / LDAP configurando SUDOERS_DEBUG debug_level na configuração do sudo LDAP (provavelmente /etc/sudo-ldap.conf ). O valor de debug_level pode ser 1 ou 2. Consulte o link para obter detalhes.

    

Answer 2

Primeiro, a resposta não-resposta: Eu deixei de colocar qualquer atributo sudoHost na minha entrada %Administrators para a ramificação sudoers do LDAP. Eu peguei isso em um lampejo de intuição.

Em segundo lugar, a resposta quase uma resposta: Se eu tivesse feito um trabalho melhor no RTFM na página de manual do sudo, eu teria visto sudo -l , o que teria me dito se o sudo estava ou não vendo os privilégios. Quando soube que a lista de privilégios estava sendo devolvida corretamente, eu poderia ter verificado isso da lista de possibilidades.

Tendo dito essas coisas, eu ainda gostaria de saber se a verificação de privilégios do sudo tem algum ponto de entrada de depuração. Então resolvi meu problema, mas não respondi a minha pergunta ...