Eu instalei 389-ds e criei um usuário e alguns grupos. Em seguida, configurei authconfig em um cliente para usar a instância LDAP para autenticar o usuário. Eu entrei com sucesso como esse usuário. Tudo bem até agora.
Agora, desejo desativar o acesso anônimo:
dn: cn=config
replace: nsslapd-allow-anonymous-access
nsslapd-allow-anonymous-access: off
Como PAM usa vinculação anônima por padrão, preciso colocar um binddn e bindpw em /etc/pam_ldap.conf e criar esse usuário na instância LDAP . Não há problemas aí.
O que eu não consigo encontrar documentado em qualquer lugar é se preciso ou não dar a esse usuário binddn "algum" tipo de Lista de Controle de Acesso para permitir que ele veja as senhas de qualquer usuário.
Pergunta o primeiro: Preciso configurar uma ACL para o meu usuário binddn ?
Eu vi uma nota passar para o efeito que PAM apenas liga o tempo suficiente para verificar se o usuário existe e a tentativa de autenticação real é vinculativa como o User Requesting Access (URA). Isso foi algumas frases em um link que eu já perdi. Então, não posso voltar atrás e tentar encontrar uma expansão nesse cenário. Se PAM funcionar dessa maneira, não precisaria de uma ACL específica, certo?
Questione o segundo: O PAM binddn precisa apenas pesquisar a URA ou precisa de privilégios adicionais?
2014-09-21 22:38
Eu desliguei o acesso anônimo, como acima, e obtive algumas coisas interessantes no log de acesso para a minha instância do dirsrv.
[21/Sep/2014:22:33:45 -0700] conn=111 op=0 UNPROCESSED OPERATION - Anonymous access not allowed
[21/Sep/2014:22:33:45 -0700] conn=111 op=0 RESULT err=48 tag=101 nentries=0 etime=0
[21/Sep/2014:22:33:45 -0700] conn=111 op=1 UNPROCESSED OPERATION - Anonymous access not allowed
[21/Sep/2014:22:33:45 -0700] conn=111 op=1 RESULT err=48 tag=101 nentries=0 etime=0
[21/Sep/2014:22:33:45 -0700] conn=111 op=2 UNBIND
[21/Sep/2014:22:33:45 -0700] conn=111 op=2 fd=65 closed - U1
[21/Sep/2014:22:33:45 -0700] conn=112 fd=64 slot=64 SSL connection from 127.0.0.1 to 127.0.0.1
[21/Sep/2014:22:33:45 -0700] conn=112 SSL 128-bit AES
[21/Sep/2014:22:33:45 -0700] conn=112 op=0 BIND dn="cn=dafydd2277,ou=users,dc=localdomain" method=128 version=3
[21/Sep/2014:22:33:45 -0700] conn=112 op=1 UNBIND
[21/Sep/2014:22:33:45 -0700] conn=112 op=1 fd=64 closed - U1
[21/Sep/2014:22:33:45 -0700] conn=112 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=dafydd2277,ou=users,dc=localdomain"
Eu comparei isso com tentativas de login, permitindo vinculação anônima. Todas eram SRCH pesquisas, sem tentativas reais de vinculação. O que faz sentido.
O próximo experimento será tentar alterar minha senha com o desligamento anônimo da ligação. Vou ligar como eu, ou o PAM tentará uma ligação anônima? (Eu tenho um palpite ...)
Estou chegando à conclusão de que o acesso do PAM é apenas para pesquisas. Quaisquer modificações em um determinado usuário são tratadas pelas próprias credenciais desse usuário. Isso significa que posso criar um usuário para o PAM se conectar, sem se preocupar com o acesso do usuário.
2014-09-22 21:31
Então, adicionamos uma conta para o PAM usar nas pesquisas e defina binddn e bindpw em /etc/pam_ldap.conf . A má notícia é que ainda estou recebendo as UNPROCESSED OPERATION tentativas e não posso provar que o PAM agora está usando o DN que eu forneci. (Além disso, o comportamento não muda com --enablesssd ou --disablessd em authconfig . Onde está o limite entre o PAM e o SSS?) Mais pesquisas a seguir ...