Depende de qual sabor de pam_ldap estamos falando. Você não mencionou um sistema operacional, mas a partir do libnss-ldapd eu posso ver que estamos falando de algum tipo de sabor do Debian.
libpam-ldap e libpam-ldapd são dois animais separados e ambos implementam o pam_ldap.so. O sabor do ldapd depende do nslcd (não libnss-ldapd ), que pode ser usado sem ativar o componente NSS. Não me lembro se o nslcd tem uma dependência difícil para libnss-ldapd , mas mesmo assim ele só será referenciado se você adicionar "ldap" a /etc/nsswitch.conf . Você não precisa se preocupar com isso de alguma forma fazendo algo com o NSS nas suas costas.
Neste ponto, você provavelmente está se perguntando qual é a diferença (e porque as pessoas se incomodariam com a dependência adicional), então aqui está um brinde:
- O módulo pam_ldap do PADL (
libpam-ldap) não está desenvolvido ativamente. Nada novo e interessante jamais acontecerá com ele. - A falta de daemon vem com um preço: não há como a biblioteca compartilhar conexões ou estados. A chamada de Every da biblioteca deve ativar sua própria conexão LDAP exclusiva e desativá-la. A força principal de
libpam-ldapd(e sssd para esse assunto) é que o daemon de backend pode manipular a conexão LDAP real e manter um estado de execução em relação à sua acessibilidade. -
libpam-ldapdtem pelo menos um recurso situacional que não está presente no sssd ou no outro módulo PAM.
A inclusão de um daemon é mais um ponto crítico quando você está usando o módulo NSS, porque cada programa tendo que atingir o servidor LDAP é menos que ideal e por que eu inveja cada administrador Linux mais jovem que nunca teve que aprender isso da maneira mais difícil.
Então lá vai: você pode evitar a integração com o NSS, e você pode evitar o daemon nslcd dependendo do módulo que você escolher. A estratégia de implementação é sua.