não consigo descobrir por que a autenticação LDAP do apache falha

De repente, ontem, um dos meus servidores apache tornou-se incapaz de se conectar ao meu servidor LDAP (AD). Eu tenho dois sites em execução nesse servidor, ambos os quais usam LDAP para autenticação no meu servidor AD quando um usuário faz logon em qualquer site. Funcionara bem há dois dias. Por razões desconhecidas, a partir de ontem, ele parou de funcionar. O log de erros diz apenas isso:

auth_ldap authenticate: user foo authentication failed; URI /FrontPage [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server], referer: http://mysite.com/

Pensei que talvez meu certificado SSL autoassinado tivesse expirado, então criei um novo para mysite.com, mas não para o nome do host do servidor, e o problema persistiu. Ativei o log no nível de depuração. Ele mostra a transação SSL completa com o servidor LDAP e parece concluir sem erros até o final, quando recebo a mensagem "Não é possível entrar em contato com o servidor LDAP". Posso executar o ldapsearch a partir da linha de comando deste servidor e posso fazer login nele, que também usa LDAP, para que eu saiba que o servidor pode se conectar e consultar o servidor LDAP / AD. É apenas o apache que não pode se conectar.

Pesquisando por uma resposta não apareceu nada, então estou perguntando aqui. Alguém pode fornecer informações sobre esse problema?

Aqui está a seção LDAP da configuração do apache:

<Directory "/web/wiki/">
    Order allow,deny
    Allow from all
    AuthType Basic
    AuthName "Login"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    #AuthBasicAuthoritative off
    AuthLDAPUrl ldaps://domain.server.ip/dc=full,dc=context,dc=server,dc=name?sAMAccountName?sub
    AuthLDAPBindDN cn=ldapbinduser,cn=Users,dc=full,dc=context,dc=server,dc=name
    AuthLDAPBindPassword password
    require valid-user
</Directory>

Um rastreamento de pacote do servidor httpd / cliente LDAP revelou uma mensagem sobre a CA desconhecida.

Alerta TLSv1 (Nível: Fatal, Descrição: CA Desconhecida)

Encontrei e adicionei a seguinte opção ao meu httpd.conf:

  LDAPVerifyServerCert          off

Isso corrigiu meu problema no CentOS 6. Os servidores httpd do CentOS 5 não exigiam nenhuma modificação e funcionaram o tempo todo sem a opção.

Eu tive um problema semelhante a esse antes com o AD no Windows 2003: a solução que encontrei foi não ligar usando o DN completo, mas usando a sintaxe user @ domain:

AuthLDAPBindDN user@domain.com

Você tem acesso aos logs do seu servidor LDAP? Eles podem ser úteis para solucionar esse problema.

Eu vi isso quando uma atualização de pacote causa alterações no cliente ldap.conf (geralmente /etc/ldap.conf ou /etc/openldap/ldap.conf) e redefine a opção TLS_REQCERT para uma configuração mais rigorosa. Ele pode negociar o SSL corretamente, mas ainda falhará no final, pois não pode validar a cadeia de certificados de uma raiz confiável.

Você pode querer verificar o relógio dos servidores. Se a diferença horária for de mais de alguns minutos, o tíquete de autenticação será inválido.

Embora essa não seja exatamente a mensagem de erro, a parte "o outro servidor repentinamente recebe o mesmo problema" pode indicar esse problema.

Você precisa impor o certificado CA LDAP para trabalhar com LDAPS

Eu tenho um problema semelhante, que eu identifiquei executando este comando:

openssl s_client -connect $ldap_host:636 -state -nbio 2>&1. Eu acho que o mod_ldap usa o openssl abaixo, então isso deve ser bastante consistente para a depuração.

Comparei-o com outro servidor criptografado SSL que eu sabia que estava funcionando. Uma conexão SSL verificada corretamente mostrará uma cadeia acessando uma CA raiz e retornará 0. Uma falha na verificação SSL fornecerá um número e um motivo. Você pode usar a saída para determinar o que está errado.

No meu caso, os certificados do servidor LDAP são assinados pela Verisign, que usa certificados de CA intermediários . O OpenSSL não pode verificar o certificado e a conexão é recusada ("a conexão recusada pelo servidor" é inútil).

Eu tive um problema parecido. Eu poderia obter o certificado com openssl, poderia consultar o Active Directory sobre SSL com ldapsearch nas mesmas portas. Finalmente, mudei para as portas 3268 ou 3269 do Microsoft Global Catalog e ambas funcionaram. Os servidores do Microsoft Windows 2003 foram corrigidos, mas isso aconteceu dias antes dos problemas começarem a ocorrer.

Eu estava implementando o LDAPS em todos os nossos servidores e também tive esse problema. Ele desaparece se você reverter para o LDAP em texto sem formatação (não é o ideal, mas é útil saber a origem do problema). Nesse caso, ainda não encontrei uma solução, mas talvez juntos possamos isolar um bug no authnz_ldap.

Estou assumindo que seus experimentos de linha de comando usavam o mesmo "usuário de ligação" das configurações do seu apache. Caso contrário, verifique se você possui a senha atual correta.

No passado, eu tive que usar a porta de catálogo global em vez da porta LDAP padrão para o domínio do AD. Não me lembro o motivo. Para ldaps como no seu URL acima, essa seria a porta 3269.

A maneira como isso funciona é que seu site precisa se conectar ao AD usando as credenciais do seu usuário de ligação primeiro e, depois que essa conexão é estabelecida, ele usa esse acesso para validar as credenciais do usuário que está tentando acessar seu site.

De acordo com a sua mensagem de erro, parece que o processo não pode se conectar ao AD como seu usuário de ligação (AuthLDAPBindDN).

Verifique se a conta do usuário de ligação não está desabilitada no Active Directory e se a senha especificada como (AuthLDAPBindPassword) está correta . Além disso, verifique se o usuário de ligação tem as permissões necessárias para procurar outros usuários (no nosso caso, deve ser um membro de Usuários do Domínio)

Acabei de ter esse problema ("não consigo entrar em contato com o servidor ldap") no RHEL6 e foi o resultado de alterações no openldap. O yum atualizou o arquivo de configuração /etc/openldap/ldap.conf, mas, em vez de substituí-lo (no caso de ter sido personalizado; no meu caso, não), ele criou um arquivo ldap.conf.rpmnew.

A cópia da versão .rpmnew sobre o ldap.conf corrigiu o problema.

(Não posso concordar que desativar a verificação de certificado é uma resposta para isso. Evita o problema de uma maneira potencialmente perigosa.)

Eu consegui corrigir esse problema instalando os pacotes berkelydbe openldapencontrados aqui .

A diferença é que o RedHat começou a vincular as coisas em nssvez do opensslsuporte ao SSL. Nesse caso, isso quebra todas as coisas. A instalação desses pacotes (que estão vinculados ao openssl) corrige o problema. Basta pegar os pacotes e executar:

yum install berkeleydb-ltb* openldap-ltb*

Em seguida, reinicie o apache e você deverá estar no negócio.

Eu tive um problema idêntico após atualizar do rhel6.6 para o rhel7.5. Quando eu estava sem ideias, concluí que o mod_ssl no apache 2.2.32 pode não ser 100% compatível no rhel7.4. Atualizei do Apache 2.2.32 para o Apache2.4, ative o SSL e o sldap funcionou.