Um problema comum com a Diretiva de Grupo e os servidores IIS é quando um GPO substitui os direitos do usuário atribuídos pela diretiva de segurança local e as contas de serviço do IIS não podem fazer logon. O log de segurança do Windows deve ter eventos de falha de logon EventId 4625 para suas contas de serviço do servidor IIS se isso estiver acontecendo.

Você pode validar rapidamente qualquer interferência de GPO executando RSOP.MSC do seu servidor IIS e navegando até Configuração do computador > Políticas > Configurações do Windows > Configurações de segurança > Políticas locais > Atribuição de direitos do usuário

Observe a coluna Source GPO para identificar qual GPO está aplicando uma configuração. Use gpedit.msc para visualizar/editar as configurações aplicadas pela política de grupo local.

Você pode usar este artigo para validar suas permissões de servidor IIS. Comece com a tabela 'Direitos de usuário do Windows que são atribuídos pela política de segurança local' na parte inferior da página.

Lembre-se: GPOs não são o inimigo, desde que sejam testados e aplicados de maneira controlada.

Resposta curta

Verifique se há certificados não autorizados . No meu caso, havia um certificado não autoassinado no repositório de certificados das Autoridades de Certificação Raiz Confiáveis. Nossos administradores adicionaram esse certificado emitido pelo governo a toda a floresta (por meio da Política de Grupo) sem os devidos testes prévios.

Detalhes

Coloquei aqui algumas diretrizes gerais de solução de problemas para ajudar as pessoas a resolver esses problemas em menos de 3 semanas, como no meu caso.

Políticas de Grupo AD

Se você não estiver familiarizado com as Políticas de Grupo, use o comando abaixo para obter um relatório legível (melhor visualizado pelo IE):

 GPRESULT /H C:\GPReport.html

Para ver mais detalhes, use RSOP.MSCconforme recomendação @twconnell . O RSOP.MSC mostra um instantâneo efetivo das políticas locais e de grupo aplicadas. Verifique a segurança em Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. No meu caso, li cuidadosamente esta excelente resposta do SO e segui todos os links. Em seguida, verifiquei os direitos de acesso em cada arquivo, pasta e pool de aplicativos. Não havia nada de errado ali.

Registros do IIS

Observe os logs do IIS. Deve haver mais detalhes do que apenas 403código fornecido ao cliente. No meu caso, havia 403 16código lá.

Consulte este guia de solução de problemas . No meu caso foi tão curto:Client certificate is untrusted or invalid

Lista de revogação de certificados (CRL)

Minha CA de certificado era uma CA de empresa fornecida pelo AD, portanto, inicialmente pensei que poderia haver algum problema com a lista de revogação de certificados (CRL). O melhor guia prático é este . Para entender mais detalhes leia este , este e finalmente este monstro . No meu caso, não houve problemas com a CRL, pois segui este , este e este guias de antemão. Resultado:

    netsh http show sslcert ipport=0.0.0.0:443
    ...
    Verificar revogação do certificado do cliente: Desativado
    Verificar revogação usando apenas certificado de cliente em cache: Desativado
    Verificação de uso: Desativado
    Tempo de Frescura de Revogação: 0
    Tempo limite de recuperação de URL: 0
    Identificador Ctl: (null)
    Ctl Store Name: (null)
    Uso do DS Mapper: Desativado
    Negociar certificado do cliente: Ativado
    ...

Depuração SSL

Para depurar a ferramenta SSL, use openssla ferramenta do lado do cliente (dado que o myserver usa a porta 443 comum para https):

 openssl s_client -connect myserver:443

No meu caso, acceptable CAs for client certificatesestava inicialmente vazio, então configurei HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendTrustedIssuerList o valor DWORD para 1 e reiniciei o servidor de acordo com este guia (próximo à parte inferior) . Observe que a lista vazia de CAs aceitáveis ​​para certificados de cliente O problema do IIS também pode ocorrer devido à enorme lista de CAs conforme esta pergunta do SF .

Quando você tiver uma lista de acceptable CAs for client certificatesna opensslsaída, poderá compará-la com o conteúdo dos repositórios de certificados configurados em seu servidor. No meu caso, havia apenas um certificado pertencente ao Trusted Root Certification Authorities. Então, depois de alguns dias de investigação que me levaram a este artigo de suporte ms #2802568 . Efetivamente, um certificado não autoassinado colocado incorretamente condenou toda a cadeia de autenticação.

Epílogo

Citando @tylerl

A autenticação do cliente SSL é uma bagunça. É bom porque é absolutamente seguro, mas é ruim porque é difícil de configurar e manter. A menos que você tenha um bom motivo, use a autenticação de chave compartilhada (ou seja, "senha"). Você economizará tempo e dinheiro. A autenticação SSL é boa para quando a segurança supera o custo por uma margem bastante ampla.