Depurando um tempo limite com a autenticação ldap no apache

2

Eu estou tentando depurar um problema de tempo limite que tenho com o Apache, por alguns meses agora.

O padrão é assim:

A cada primeira solicitação de uma nova sessão (ou após algum tempo após a última solicitação), o navegador solicita instantaneamente credenciais e envia a solicitação com a autenticação básica. Então o servidor aguarda exatamente 1 minuto antes de enviar o resultado.

Ospedidossubsequentessãorespondidosinstantaneamente,oqueaconteceapenascompedidosapósalgumtempo(nãofoipossívelidentificarexatamenteainda,entre5e15minutos).

Ofatodequeotempodeesperaéreproduzívelexatamente60segundoscheiraaumtempolimiteparamim.SeeucancelarasolicitaçãoeclicaremAtualizar,recebooURLsolicitadoinstantaneamente.

Comoopromptdesenhaapareceinstantaneamente,tambémpossodescartarumproblemacomohandshakeSSLentreclienteeservidorouproblemasdeDNSnessaetapa.NãoimportaseeusolicitoumscriptPHPouumarquivodetextoembranco,oquetambémresolveumproblemacomscriptsnoservidor.Euachoqueoresultadodoprocessodeautenticaçãoéentãoarmazenadoemcacheporumtempo,entãonãoénecessárioparasolicitaçõessubsequentes.

Nãoqueaautenticaçãosempresejabem-sucedida,paraqueeupossaexcluirumproblemade"o controlador de domínio também não respondeu".

O Apache 2.4 está sendo executado no Windows Server 2012 R2. Está configurado para autenticação LDAP:

<Location />
    AuthType Basic
    AuthName "AD Login"
    AuthBasicProvider ldap
    LDAPReferrals Off
    #AuthLDAPUrl ldap://dc01.domain.de:3268/dc=ad,dc=domain,dc=de?sAMAccountName?sub?(objectClass=*)
    #AuthLDAPUrl ldap://ad.domain.de:389/dc=ad,dc=domain,dc=de?sAMAccountName?sub?(objectClass=*) STARTTLS
    AuthLDAPUrl ldap://ad.domain.de:389/dc=ad,dc=domain,dc=de?sAMAccountName?sub?(objectClass=*) TLS
    AuthLDAPBindDN "[email protected]"
    AuthLDAPBindPassword "secret"
    Require valid-user
    Require all denied
</Location>

Como você pode ver, eu tentei diferentes tipos de conexão para os controladores de domínio, não parece realmente importar qual método de criptografia eu uso, ou se eu passo a criptografia.

ad.domain.de resolve vários controladores de domínio, mas o comportamento é o mesmo se eu me conectar a um DC específico.

Não há entradas no log de erros em LogLevel info , mas hesito em aumentá-lo para debug , pois sei, por experiência própria, que tenho dificuldade em examinar as informações de depuração geradas.

Existe alguma coisa que eu perdi ainda que eu possa usar para depurar o problema, ou eu tenho que passar pelo log de nível de depuração?

    
por Gerald Schneider 11.01.2017 / 11:05

1 resposta

3

Depois de aumentar o nível de log dos módulos authnz_ldap e ldap , a seguinte mensagem de erro apareceu no log de erros:

ldap_simple_bind() timed out on reused connection, dropped by firewall?

Isso me levou ao relatório de bugs do mod_ldap , que, embora tenha sido um erro de configuração, apontou-me para o problema real:

As reported elsewhere, windows closes an LDAP connection after 900 seconds, but the default Apache behavior appears to try to re-use the connection indefinitely. If Apache tries to re-use after windows has closed the connection, there's a 60 second delay waiting for the connection to timeout [...]

Fazendo algumas verificações rápidas para confirmar isso:

O valor padrão de MaxConnIdleTime nas Políticas LDAP da Microsoft é de 900 segundos, o que coincide com minha observação de que o problema aparece novamente após 15 minutos. O atraso de 60 segundos também corresponde exatamente ao meu problema.

De acordo com esse relatório de erros, o problema deve ser resolvido definindo LDAPConnectionPoolTTL para um valor menor que MaxConnIdleTime e diferente do valor padrão -1, mas isso não funcionou para mim. Eu tive que definir o valor para 0 , desabilitando a reutilização de conexões existentes.

LDAPConnectionPoolTTL 0

Eu não espero nenhum problema de desempenho com isso, já que os resultados do ldap são armazenados em cache de qualquer maneira.

A única coisa que permanece um mistério é por que esse problema ocorre apenas em nossa instância do Apache em execução no Windows, mas não com as instâncias do Apache em execução no Linux.

    
por 12.01.2017 / 15:06