via LDAP parou de funcionar após a atualização para o SLES 11.4 via método recomendado (inicializar a partir do DVD). Infelizmente, com o SLES, não posso dar a você nenhuma saída de log significativa, uma vez que nem o PAM nem o cliente ldap fornecem nenhum e o pam_debug não está disponível no SLES.
Nós suspeitamos que isso se resume a exigir que o userfilter inetOrgPerson. Claro que nós definimos este filtro no /etc/ldap.conf. Funcionou muito bem em 10.4 mas agora tudo o que você consegue é "senha inválida".
Usando o tcpdump eu consegui determinar que, diferentemente do 10.4, o cliente ldap agora consulta primeiro o servidor com o filtro inetOrgPerson (que funciona e retorna resultados), mas subseqüentemente (!) consulta o servidor com o filtro posixAccount. Agora, este último não funciona porque este atributo não é usado pelo servidor LDAP (IBM Tivoli Directory Server). Como a consulta da senha agora é feita com o filtro de usuário incorreto - nenhuma senha é verificada em relação ao LDAP (pelo que posso tell) e assim o login falha.
Existe uma maneira de forçar o cliente LDAP a ficar com o filtro de usuário configurado (inetOrgPerson) em vez de comutar para um incorreto (codificado?) para consultas sobre senha e shell? A verdade é que não usamos senhas para entrar no sistema via ssh, então só precisamos disso PAM + LDAP para estar funcionando para que aplicativos possam checar senhas de usuários ele (o aplicativo não tem seu próprio suporte LDAP). Como tal, não precisamos de entradas no LDAP para um shell de usuário e qualquer outro que seja normalmente designado para posixAccount.
Tanto quanto eu posso dizer - modificar o servidor LDAP de produção não é uma opção.
FWIW O método de testar isso é ssh'ing na caixa (com pubkey) e, em seguida, tente su em nosso próprio usuário para um prompt de senha. / var / log / messages apenas diz "falhou su ..." sem mais detalhes