Eu criei um filtro ISAPI para o IIS 6.0 que tenta autenticar no diretório ativo usando o LDAP. O filtro funciona bem ao autenticar regularmente pela porta 389, mas quando tento usar SSL, sempre recebo o erro 0x51 Server Down na chamada ldap_connect() . Mesmo pulando a chamada de conexão e usando ldap_simple_bind_s() resulta no mesmo erro.
O mais estranho é que, se eu alterar a identidade do pool de aplicativos para a conta de administrador local, o filtro funcionará bem e o LDAP sobre SSL será bem-sucedido. Eu criei um exe com o mesmo código abaixo e o executei no servidor como admin e ele funciona. Usar a identidade padrão do serviço de rede para o pool de aplicativos do site é o que parece ser o problema. Qualquer pensamento sobre o que está acontecendo? Quero usar a identidade padrão, pois não quero que o site tenha privilégios de administrador elevados.
O servidor está em um DMZ fora da rede e do domínio em que os nossos DCs executam o AD. Temos um certificado válido em nossos DCs para AD também.
Código:
// Initialize LDAP connection
LDAP * ldap = ldap_sslinit(servers, LDAP_SSL_PORT, 1);
ULONG version = LDAP_VERSION3;
if (ldap == NULL)
{
strcpy(error_msg, ldap_err2string(LdapGetLastError()));
valid_user = false;
}
else
{
// Set LDAP options
ldap_set_option(ldap, LDAP_OPT_PROTOCOL_VERSION, (void *) &version);
ldap_set_option(ldap, LDAP_OPT_SSL, LDAP_OPT_ON);
// Make the connection
ldap_response = ldap_connect(ldap, NULL); // <-- Error occurs here!
// Bind and continue...
}
UPDATE: criei um novo usuário sem privilégios de administrador e executei o teste exe como novo usuário e recebi o mesmo erro Server Down . Eu adicionei o usuário ao grupo Administradores e recebi o mesmo erro também. O único usuário que parece trabalhar com autenticação LDAP sobre SSL neste servidor específico é o administrador.
O servidor web com o filtro ISAPI (e onde eu tenho executado o exe de teste) está executando o Windows Server 2003. Os DCs com o AD neles estão executando o 2008 R2.
Também vale a pena mencionar que temos um site WordPress no mesmo servidor que autentica o LDAP sobre SSL usando PHP (OpenLDAP) e não há nenhum problema lá. Eu tenho um arquivo ldap.conf que especifica TLS_REQCERT never e o usuário que está executando o código PHP é IUSR.
Certifique-se de que o usuário que está falhando confie na autoridade de certificação do seu servidor ldap.
Para fazer isso, efetue login como o usuário que está falhando (você pode ter que conceder privilégios temporários para isso, talvez colocá-lo no grupo "Área de Trabalho Remota"). Inicie certmgr.msc e procure a autoridade de certificação que você está usando em "Autoridades de certificação raiz confiáveis".
Compare o que você vê com o que está na conta de administrador.
Acredito que você está tendo um problema de truststore.
Consulte link
Uma forma de exemplo de testar isso pode ser para diferenciar a saída baseada em texto da impressão do conteúdo do armazenamento de certificados.
Tags ssl active-directory isapi