pam_ldap.so antes pam_unix.so? Isso é possível?

Question

temos alguns servidores com o PAM + LDAP.

A configuração é padrão (veja link ou link ). Por exemplo, /etc/pam.d/common-auth contém:

auth sufficient pam_unix.so nullok_secure
auth requisite pam_succeed_if.so uid >= 1000 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

E, claro, funciona tanto para usuários ldap quanto locais. Mas todo login vai primeiro para o pam_unix.so, falha, e só então tenta pam_ldap.so com sucesso. Como resultado, temos uma mensagem de falha bem conhecida para cada login de usuário do ldap:

pam_unix(<some_service>:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<some_host>  user=<some_user>

Eu tenho até 60000 de tais mensagens de log por dia e eu quero mudar a configuração para que o PAM tente a autenticação do ldap primeiro, e somente se ele falhar - tente pam_unix.so (acho que pode melhorar o i / o desempenho do servidor). Mas se eu mudar common-auth para o seguinte:

auth sufficient pam_ldap.so use_first_pass
auth sufficient pam_unix.so nullok_secure
auth required pam_deny.so

Então, simplesmente não consigo mais fazer login com usuários locais (não ldap) (por exemplo, via ssh).

Alguém conhece a configuração correta? Por que o Debian e o nss-pam-ldapd tem o pam_unix.so a princípio por padrão? Não há realmente como mudar isso?

Obrigado antecipadamente.

P.S. Eu não quero desabilitar os logs, mas quero definir a autenticação do ldap em primeiro lugar.

    

Answer 1

hayalci respondeu no comentário:

auth sufficient pam_ldap.so
auth sufficient pam_unix.so nullok_secure try_first_pass
auth required pam_deny.so

    

Answer 2

Se os usuários locais e da rede estiverem em intervalos de uid separados (o que é uma boa ideia), você poderá adicionar uma linha como esta (supondo que os usuários locais estejam no intervalo de 0 a 4999):

auth [success=1 default=ignore] pam_succeed_if.so uid >= 5000 quiet

antes da linha pam_unix.so . Passará 1 linha se uid > = 4999. Irá diretamente para pam_ldap.so.

E você precisa alterar pam_ldap.so use_first_pass para pam_ldap.so ou pam_ldap.so try_first_pass se você não tiver uma linha que solicite a senha antes de pam_ldap.so .

Eu testaria com:

auth [success=1 default=ignore] pam_succeed_if.so uid >= 4999 quiet
auth sufficient pam_unix.so nullok_secure
auth requisite pam_succeed_if.so uid >= 4999 quiet
auth sufficient pam_ldap.so
auth required pam_deny.so

    

Answer 3

Seu:

auth sufficient pam_unix.so nullok_secure  
auth requisite pam_succeed_if.so uid >= 1000 quiet  
auth sufficient pam_ldap.so use_first_pass  
auth required pam_deny.so  

Mude para: (use_first_pass significa usar a senha do módulo anterior, que é pam_ldap.so)

auth sufficient pam_ldap.so  
auth requisite pam_succeed_if.so uid >= 1000 quiet  
auth sufficient pam_unix.so use_first_pass nullok_secure  
auth required pam_deny.so  

Disavantage (para hpux): Se o servidor ldap travar (ataque de sincronização, veja link ) seu cliente também irá travar, isso acontece com os servidores HPUX (não o linux e aix; o processo hpux chamado ldapclientd). Isso significa que todo o login (mesmo como root do ILO / MP) está bloqueado. Solução é reiniciar o servidor :-(. Então eu prefiro pam_unix antes pam_ldap no hpux

    

Answer 4

Eu gostaria de dizer que esta solução funcionou para mim! Eu estava tendo o mesmo problema usando o free-ipa, e usando essa configuração no meu arquivo /etc/pam.d/system-auth evitei os erros extras de "falha de autenticação":

auth        required      pam_env.so
auth        sufficient    pam_sss.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so