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, sendo que ambos usam LDAP para autenticação em meu servidor AD quando um usuário efetua login em um dos sites. Ele estava funcionando bem há dois dias. Por razões desconhecidas, a partir de ontem, 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 auto-assinado tivesse expirado, então criei um novo para mysite.com, mas não para o próprio nome do host do servidor, e o problema persistiu. Ativei o log de nível de depuração. Ele mostra a transação SSL completa com o servidor LDAP e parece ser concluído sem erros até o final, quando recebo a mensagem "Não consigo contatar o servidor LDAP". Eu posso executar ldapsearch a partir da linha de comando neste servidor, e eu posso fazer o login para ele, que também usa LDAP, então eu sei 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 uma visão para este 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 o fato de a CA ser desconhecida.
Alerta TLSv1 (Nível: Fatal, Descrição: CA desconhecida)
Eu encontrei e adicionei a seguinte opção ao meu httpd.conf:
LDAPVerifyServerCert off
Isso resolveu meu problema com o CentOS 6. Os servidores httpd do CentOS 5 não precisaram de nenhuma modificação e trabalharam o tempo todo sem a opção.
Eu tive um problema semelhante a este antes com o AD no Windows 2003: a solução que encontrei foi não vincular usando o DN completo, mas em vez disso usar a sintaxe user @ domain:
AuthLDAPBindDN [email protected]
Você tem acesso aos registros 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 de tempo for superior a alguns minutos, o ticket de autenticação será inválido.
Embora esta não seja exatamente a mensagem de erro, a parte "o outro servidor repentinamente recebe o mesmo problema" pode indicar tal problema.
Você precisa impor o certificado CA da LDAP para trabalhar com LDAPS
Eu tive um problema semelhante. Eu poderia obter o certificado com openssl, eu 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 elas funcionaram. Os servidores do Microsoft Windows 2003 foram corrigidos, mas isso aconteceu dias antes de os problemas começarem a ocorrer.
Eu estava implementando LDAPS em todos os nossos servidores e também corri para esse problema. Ele desaparece se você reverter para o LDAP em texto simples (não ideal, mas útil para conhecer a origem do problema). Se assim for, ainda tenho que encontrar uma solução, mas talvez juntos possamos isolar um bug no authnz_ldap.
Estou assumindo que seus experimentos de linha de comando estavam usando o mesmo "bind user" como nas configurações do apache. Se não, você deve verificar se você tem a senha atual correta.
No passado, uma vez tive que usar a porta do catálogo global em vez da porta LDAP padrão para o domínio do AD. Não me lembro do motivo. Para ldaps como em seu URL acima, isso seria a porta 3269.
A maneira como isso funciona é que seu site precisa se conectar ao AD usando as credenciais do bind user primeiro e, depois de fazer essa conexão, ele usa esse acesso para validar as credenciais de o usuário tentando acessar seu site.
De acordo com a sua mensagem de erro, parece que o processo não consegue se conectar ao AD como seu bind user (AuthLDAPBindDN).
Certifique-se de que a conta de usuário de ligação não esteja desativada no Active Directory e que a senha que você especificou como (AuthLDAPBindPassword) esteja correta . Além disso, certifique-se de que seu usuário de ligação tenha as permissões necessárias para procurar outros usuários (deve ser um membro dos Usuários do Domínio em nosso caso)
Eu tenho um problema semelhante, que identifiquei executando este comando:
openssl s_client -connect $ldap_host:636 -state -nbio 2>&1 . Eu acho que mod_ldap usa openssl por baixo, então isso deve ser bastante consistente para depuração.
Eu o comparei com outro servidor com criptografia SSL que eu sabia que estava funcionando. Uma conexão SSL verificada corretamente mostrará uma cadeia indo para uma CA raiz e retornará 0. Uma falha na verificação de 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 CERs intermediários da CA . O OpenSSL não consegue verificar o certificado e a conexão é recusada ("conexão recusada pelo servidor" é inútil).
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. yum tinha atualizado o arquivo de configuração /etc/openldap/ldap.conf mas ao invés de sobrescrevê-lo (no caso de ser customizado; no meu caso não era) ele criou um arquivo ldap.conf.rpmnew.
Copiar a versão .rpmnew sobre o ldap.conf corrigiu o problema.
(Eu não posso concordar que desligar a verificação do certificado é uma resposta para isso. Evita o problema de uma maneira potencialmente perigosa.)
Consegui corrigir esse problema instalando os pacotes berkelydb e openldap encontrados aqui .
A diferença é que o RedHat começou a vincular as coisas com nss em vez de openssl para suporte a SSL. Neste caso, isso quebra todas as coisas. A instalação desses pacotes (que sã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ê deve estar no negócio.