A autenticação LDAP do FreeBSD, pam_ldap, não pode ligar

Question

Consegui alguns dos meus servidores linux autenticando usuários em relação ao meu servidor de diretórios LDAP, mas tenho tido problemas para fazer isso com nss_ldap e pam_ldap no FreeBSD.

A partir de documentos oficiais do FreeBSD aqui: link

Eu instalo os 2 pacotes, e crio um arquivo de configuração /usr/local/etc/ldap.conf, e também um link simbólico para este arquivo no mesmo diretório, nss_ldap.conf. De acordo com os documentos, ambos podem usar o mesmo arquivo de configuração. Estou mantendo tudo muito simples até conseguir que funcione:

ldap.conf / nss_ldap.conf:

base    dc=corp,dc=example,dc=org
host    192.168.0.100
ldap_version 3
binddn cn=admin,dc=corp,dc=example,dc=org
bindpw secret

O NSS funciona até onde eu sei. Um "getent passwd" mostra informações do diretório LDAP, assim como informações locais.

Agora quero autenticar, então adiciono uma linha ao /etc/pam.d/sshd:

# auth
auth        sufficient  pam_opie.so     no_warn no_fake_prompts
auth        requisite   pam_opieaccess.so   no_warn allow_local
#auth       sufficient  pam_krb5.so     no_warn try_first_pass
#auth       sufficient  pam_ssh.so      no_warn try_first_pass
auth        sufficient  /usr/local/lib/pam_ldap.so no_warn try_first_pass debug
auth        required    pam_unix.so     no_warn try_first_pass

Eu reinicio o ssh (não tenho certeza se isso é necessário) e, em seguida, tento fazer logon com um usuário LDAP que não existe localmente (coryj). Ele falha silenciosamente e os logs mostram:

Sep  9 13:13:54 freebsd-testbox sshd[12684]: pam_ldap: error trying to bind as user "uid=coryj,ou=Users,dc=corp,dc=example,dc=org" (Invalid credentials)

Por que ele está tentando ligar com o usuário que estou tentando autenticar quando eu especifiquei um binddn / bindpw? Eu também tentei rootbinddn com um arquivo .secret com o mesmo resultado. No linux binddn parece funcionar, onde aqui parece ser ignorado.

Eu sei que meus arquivos ldap.conf e pam precisarão de mais algum trabalho, apenas tentando convencer a coisa a se ligar como admin ao autenticar neste ponto.

    

Answer 1

Veja como funciona a autenticação LDAP, em poucas palavras:

1. Você SSH como joeblow . Seu cliente dá esse nome ao servidor, juntamente com sua senha (que você digita).
2. O servidor começa a caminhar na lista do PAM dizendo "alguém atesta esse cara?", procurando um OK ou um NO. (Módulos PAM podem negar, bem como permitir). No seu caso:
   1. Verifica pam_opie.so . Você disse que isso é suficiente, então apenas seguirá em frente se não for encontrado. Eu imagino que não é neste caso.
   2. Verifica pam_opieaccess.so . Nesse caso, é necessário, então pam_opieaccess.so tem que dizer "sim, ele está bem". Eu imagino que este módulo é apenas verificar uma lista de contas que estão marcadas "tem que auth via OPIE", que joeblow não está. Está tudo bem.
   3. /usr/local/lib/pam_ldap.so recebe um turno. Esta é a parte que você gosta.
      1. Primeiro, liga-se ao servidor com seu binddn e bindpw , para perguntar "ei, eu tenho esse joeblow aqui, qual é o nome real dele?" O servidor responde a uid=joeblow,ou=Users,dc=corp,dc=example,dc=org .
      2. pam_ldap.so desconecta e tenta ligar como uid=joeblow,ou=Users,dc=corp,dc=example,dc=org com a senha que você forneceu. Se ele pode ligar, você está dentro Se não, não.

Portanto, o erro que você está recebendo significa que a etapa 2.3.2 está falhando, provavelmente porque a senha está incorreta. É possível que haja algum outro problema com a ligação joeblow ao servidor, verifique os logs do servidor LDAP para obter mais detalhes.

    

Answer 2

As opções binddn e bindpw controlam a pesquisa inicial que converte um nome de usuário em um nome distinto LDAP - as verificações de senha LDAP são executadas vinculando-se ao diretório LDAP enquanto o usuário tenta autenticar (Se você conseguiu bind então a verificação foi bem sucedida).
Veja man pam_ldap para maiores informações.

No seu caso, suspeito que a senha que você está digitando para coryj está errada (talvez a senha do LDAP esteja corrompida?) ou o coryj não pode ser vinculado ao diretório por outros motivos. Tente ligar com ldapwhoami ou ldapsearch e veja se você recebe uma mensagem de erro útil.