Lidar com falha LDAP ao usá-lo para PAM / NSS?

Question

Eu uso um par redundante de servidores OpenLDAP para serviços de autenticação e diretório do PAM via NSS. Tem sido 100% confiável até agora, mas nada funciona sem falhas para sempre.

Quais são as etapas que devo seguir agora para que eu tenha uma chance de recuperar a falha do (s) servidor (es) LDAP? Em meus testes informais, parece que mesmo os shells já autenticados são inúteis, já que todas as buscas username / uid ficam suspensas até que o servidor de diretórios volte.

Até agora eu criei apenas duas coisas:

1. Não use NSS-LDAP e PAM-LDAP nos próprios servidores LDAP.
2. Crie uma conta de nível raiz em todas as caixas que aceitam apenas autenticação de chave pública da nossa sub-rede local e protejam bem essa chave. Não sei ao certo o quanto isso me faria de bom, uma vez que estou logado, suspeito que não conseguiria realizar nada, já que todas as pesquisas de userid ficariam pendentes.

Alguma outra sugestão?

    

Answer 1

Regra nº 1 da autenticação baseada em rede: tenha sempre uma conta local disponível.

Além da regra 1 (e para torná-lo útil sem ficar bloqueado atrás do nss_ldap tentando falar com um servidor inativo):

Usando pam_ldap / nss_ldap você pode definir o bind_policy para "soft" (retornar imediatamente na falha do servidor), o que elimina o problema de bloqueio. Você também pode definir o timelimit vallues para fazer o retorno do nss_ldap se ele não puder contatar o servidor LDAP. Observe que isso tem outras implicações (como uma falha temporária durante o SSHing fará com que sua conta LDAP fique inacessível e falhas esporádicas resultarão em nomes de usuários desconhecidos para alguns UIDs LDAP.

Também existem algumas opções nss_ldap não documentadas: nss_reconnect_tries , nss_reconnect_sleeptime , nss_reconnect_maxsleeptime , & nss_reconnect_maxconntries , que faz o que seus nomes significam e irá ajudá-lo a contornar falhas do seu servidor LDAP sem definindo sua bind_policy para soft (isto é o que eu estou fazendo - 3 reconectar tentativas com 10 segundos max sleep = atraso máximo de 30sec esperando pelo servidor LDAP).