Partilhar via

Configurar o suporte do AD FS para autenticação de certificado do usuário

Este artigo descreve como habilitar a autenticação de certificado de usuário nos AD FS (Serviços de Federação do Active Directory). Também apresenta informações para solução de problemas comuns com esse tipo de autenticação.

Há dois casos de uso principais para autenticação de certificado de usuário:

  • Os usuários estão usando cartões inteligentes para entrar no sistema do AD FS.
  • Os usuários estão usando certificados provisionados para dispositivos móveis.

Pré-requisitos

  • Utilizando um dos modos descritos em Suporte ao AD FS para associação alternativa de nome do host para autenticação de certificado, determine o modo de autenticação de certificado de usuário do AD FS que você quer habilitar.
  • Confira se a cadeia confiável do certificado de usuário está instalada e foi validada por todos os servidores AD FS e WAP (Proxy de aplicativo Web), incluindo todas as autoridades intermediárias de certificação. Isso geralmente é feito por meio do GPO (Objeto de Política de Grupo) em servidores AD FS e WAP.
  • Verifique se o certificado raiz da cadeia de confiança dos certificados de usuário está no repositório NTAuth do Active Directory.
  • Se você estiver usando o AD FS no modo de autenticação alternativa de certificado, verifique se os servidores AD FS e WAP têm certificados SSL (Secure Sockets Layer) que contêm o nome do host do AD FS prefixado com "certauth", como por exemplo, certauth.fs.contoso.com. Verifique também se o firewall permite o tráfego para esse nome do host.
  • Se você estiver usando a autenticação de certificado da extranet, verifique se pelo menos um AIA (Acesso às Informações da Autoridade) e pelo menos um local de CDP (ponto de distribuição de lista de revogação de certificados) ou OCSP (protocolo OCSP) da lista especificada nos certificados estão acessíveis pela Internet.
  • Se você estiver configurando o AD FS para autenticação de certificado do Microsoft Entra (Azure Active Directory ), confira se você definiu as configurações do Microsoft Entra e as regras de declaração do AD FS, necessárias para o emissor do certificado e o número de série.
  • Se você estiver usando a autenticação de certificado do Microsoft Entra para clientes do Exchange ActiveSync, o certificado do cliente deve ter no Exchange Online, um email de usuário que possa ser roteado, seja em Nome principal ou em Nome do RFC822 do campo Nome Alternativo da Entidade. O Microsoft Entra ID mapeia o valor de RFC822 para o atributo de endereço de proxy no diretório.

Observação

O AD FS não suporta dicas de nome de usuário com cartão inteligente ou autenticação baseada em certificado.

Habilitar autenticação de certificado de usuário

Para habilitar a autenticação de certificado de usuário como um método de autenticação de intranet ou extranet no AD FS, use o console de Gerenciamento do AD FS ou o cmdlet Set-AdfsGlobalAuthenticationPolicydo PowerShell.

As considerações opcionais incluem:

  • Se você quiser usar declarações com base em campos de certificado e extensões, além do tipo de declaração de EKU https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku, configure mais regras para passar declarações na relação de confiança do provedor de declarações do Active Directory. Veja a lista completa de declarações de certificado mais adiante neste artigo.

  • Se precisar restringir o acesso com base no tipo de certificado, use as propriedades adicionais do certificado nas regras de autorização de emissão do AD FS para o aplicativo. Exemplos de cenários comuns são permitir apenas certificados provisionados por um provedor de MDM (gerenciamento de dispositivo móvel) ou permitir apenas certificados de cartão inteligente.

    Importante

    Os clientes que usam o fluxo de código do dispositivo para autenticação e executam a autenticação de dispositivo usando um provedor de identidade diferente do Microsoft Entra ID (por exemplo, AD FS), não podem aplicar acesso baseado em dispositivo para recursos do Microsoft Entra ID. Por exemplo, eles não podem usar um serviço MDM de terceiros para permitir somente dispositivos gerenciados.

    Para ajudar a proteger o acesso a recursos corporativos no Microsoft Entra ID e evitar perda de dados, configure o Acesso Condicional baseado em dispositivo do Microsoft Entra. Por exemplo, use Exigir que o dispositivo seja marcado como em conformidade para conceder o controle no Acesso Condicional do Microsoft Entra.

    Configure as autoridades de certificação de emissão permitidas para os certificados de cliente usando as orientações em "Gerenciamento de emissores confiáveis para autenticação de cliente" na Visão geral técnica do SSP Schannel.

  • Considere modificar as páginas de entrada para atender às necessidades dos usuários na autenticação de certificados. Um exemplo comum é alterar Entre com seu certificado X509 para tornar mais cordial e fácil de entender.

Configurar autenticação de certificado simples no navegador Chrome em áreas de trabalho do Windows

Quando um computador tem vários certificados de usuário (como certificados Wi-Fi) que atendem às finalidades de autenticação do cliente, o navegador Chrome nas áreas de trabalho do Windows solicitará que os usuários selecionem o certificado correto. Essa solicitação pode ser confusa para os usuários. Para aprimorar essa experiência, você pode definir uma política para o Chrome selecionar automaticamente o certificado correto.

Você pode definir essa política manualmente fazendo uma alteração no Registro ou configurá-la automaticamente por meio do GPO (para definir as chaves do Registro). Isso exige que os certificados de cliente de usuário para autenticação no AD FS tenham emissores distintos de outros casos de uso.

Para obter mais informações sobre como configurar a autenticação de certificado no Chrome, veja Lista de políticas do Chrome Enterprise.

Solucionar problemas de autenticação de certificado

Use as informações a seguir para solucionar problemas comuns de configuração do AD FS para autenticação de certificado de usuário.

Verifique se os emissores de confiança do certificado estão configurados corretamente em todos os servidores AD FS e WAP

Se os emissores de confiança do certificado não estiverem configurados corretamente, um problema comum que ocorre é um erro HTTP 204: "Nenhum conteúdo de https://certauth.adfs.contoso.com."

O AD FS usa o sistema operacional Windows subjacente para comprovar a posse do certificado de usuário e conferir se ele corresponde a um emissor confiável validando a cadeia confiável do certificado. Para fazer a correspondência do emissor confiável, você precisa garantir que todas as autoridades raiz e intermediárias estejam configuradas como emissores confiáveis no repositório local para as autoridades de certificação do computador.

Para validar isso automaticamente, use a ferramenta Analisador de Diagnóstico do AD FS. A ferramenta consulta todos os servidores e garante que os certificados corretos sejam provisionados corretamente.

  1. Baixe e execute a ferramenta.
  2. Carregue os resultados e examine se há falhas.

Verificar se a autenticação de certificado está habilitada na política de autenticação do AD FS

Por padrão, o AD FS executa a autenticação de certificado de usuário na porta 49443 com o mesmo nome do host do AD FS (exemplo: adfs.contoso.com). Você também pode configurar o AD FS para usar a porta 443 (porta HTTPS padrão) usando a associação SSL alternativa. No entanto, a URL usada nessa configuração é certauth.<adfs-farm-name> (exemplo: certauth.contoso.com). Para obter mais informações, veja Suporte do AD FS para associação alternativa de nome do host para autenticação de certificado.

Observação

Agora, o AD FS no Windows Server 2016 suporta dois modos. O primeiro modo usa o host adfs.contoso.com com as portas 443 e 49443. O segundo modo usa os hosts adfs.contoso.com e certauth.adfs.contoso.com com a porta 443. Você precisa de um certificado SSL para suportar certauth.\<adfs-service-name> como um nome alternativo de entidade. Você pode fazer isso no momento da criação do farm ou posteriormente por meio do PowerShell.

O caso mais comum de problema de conectividade de rede é um firewall configurado incorretamente que bloqueia o tráfego para autenticação de certificado de usuário. Quando esse problema ocorre, geralmente aparece uma tela em branco ou um erro 500 de servidor. Para corrigir isso:

  1. Observe o nome do host e a porta que você configurou no AD FS.
  2. Verifique se algum firewall na frente do AD FS ou do WAP está configurado para permitir a combinação hostname:port para o farm do AD FS. O engenheiro de rede deve executar esta etapa.

Verificar a conectividade da CRL

As CRLs (listas de certificados revogados) são pontos de extremidade codificados no certificado de usuário para executar verificações de revogação em tempo de execução. Por exemplo, se um dispositivo que contém um certificado for roubado, um administrador poderá adicionar o certificado à lista de certificados revogados. Qualquer ponto de extremidade que aceitou esse certificado anteriormente não conseguirá autenticar.

Cada servidor AD FS e WAP precisa acessar o ponto de extremidade da CRL para fazer a validação se o certificado que foi apresentado a ele ainda for válido e não foi revogado. A validação de CRL pode ocorrer por HTTPS, HTTP, LDAP ou OCSP. Se os servidores AD FS e WAP não puderem acessar o ponto de extremidade, a autenticação falhará. Execute as etapas a seguir para solucionar o problema:

  1. Consulte o engenheiro de PKI (infraestrutura de chave pública) para identificar quais pontos de extremidade de CRL estão sendo usados para revogar certificados de usuário no sistema de PKI.
  2. Em cada servidor AD FS e WAP, verifique se os pontos de extremidade de CRL estão acessíveis por meio do protocolo usado (normalmente HTTPS ou HTTP).
  3. Para uma validação avançada, habilite o log de eventos do CAPI2 em cada servidor AD FS e WAP.
  4. Verifique se há ID de Evento 41 (Verificar Revogação) nos logs operacionais do CAPI2.
  5. Verifique se há <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Dica

Para verificar um único servidor AD FS ou WAP para facilitar a solução de problemas, configure a resolução DNS (arquivo de hosts no Windows) para apontar para o servidor específico. Essa técnica permite habilitar o rastreamento ao escolher um único servidor.

Verificar se há problemas de SNI

O AD FS requer dispositivos cliente (ou navegadores) e os balanceadores de carga para suportar SNI (Indicação de Nome de Servidor). Alguns dispositivos cliente (por exemplo, versões mais antigas do Android) podem não suportar SNI. Além disso, os balanceadores de carga podem não suportar SNI ou não estar configurados para SNI. Nesses casos, provavelmente ocorrerão falhas na certificação de usuário.

Para corrigir esse problema, trabalhe com o engenheiro de rede para fazer com que o balanceador de carga para AD FS e WAP suporte SNI. Se a SNI não puder ser usada, utilize esta solução alternativa no AD FS:

  1. Abra uma janela do Prompt de Comandos com privilégios elevados no servidor primário do AD FS.
  2. Insira Netsh http show sslcert.
  3. Copie o GUID (identificador global exclusivo) do aplicativo e o hash de certificado do serviço de federação.
  4. Insira netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicaitonGUID}.

Verificar se o dispositivo cliente foi provisionado corretamente com o certificado

Talvez alguns dispositivos estejam funcionando corretamente, mas outros dispositivos não estejam. Na maioria dos casos, isso significa que o certificado de usuário não foi provisionado corretamente em alguns dispositivos cliente. Siga estas etapas:

  1. Se o problema for específico de um dispositivo Android, a causa mais comum é que a cadeia de certificado no dispositivo não é totalmente confiável. Consulte o fornecedor de MDM para conferir se o certificado foi provisionado corretamente e se toda a cadeia no dispositivo Android é totalmente confiável.

    Se o problema for específico de um dispositivo Windows, confira se o certificado foi provisionado corretamente verificando o repositório de certificados do Windows do usuário conectado (não do sistema ou do computador).

  2. Exporte o certificado de usuário cliente para um arquivo .cer e execute o comando certutil -f -urlfetch -verify certificatefilename.cer.

Verificar se a versão do TLS é compatível entre os servidores AD FS/WAP e o dispositivo cliente

Em casos raros, um dispositivo cliente é atualizado para suportar somente uma versão mais alta do TLS (por exemplo, 1.3). Talvez o problema seja inverso, em que os servidores AD FS e WAP foram atualizados para usar somente uma versão mais alta do TLS à qual o dispositivo cliente não suporta.

Você pode usar ferramentas SSL online para verificar se os servidores AD FS e WAP são compatíveis com o dispositivo. Para obter mais informações sobre como controlar as versões do TLS, veja Gerenciamento de protocolos SSL/TLS e pacotes de criptografia para AD FS.

Verificar se o PromptLoginBehavior do Microsoft Entra está configurado corretamente nas configurações de domínio federado

Muitos aplicativos do Office 365 enviam o prompt=login para o Microsoft Entra ID. Por padrão, o Microsoft Entra ID o converte em uma nova senha de logon para o AD FS. Como resultado, mesmo que você tenha configurado a autenticação de certificado no AD FS, os usuários verão apenas uma senha de logon. Para corrigir esse problema:

  1. Obtenha as configurações de domínio federado usando o cmdlet Get-MgDomainFederationConfiguration.
  2. Verifique se o parâmetro PromptLoginBehavior está definido como Disabled ou NativeSupport.

Para obter mais informações, veja Prompt do AD FS=suporte a parâmetro de logon.

Soluções de problemas adicionais

Em casos raros, se as listas de CRL forem muito longas, elas poderão exceder o tempo limite para fazer download. Nesses casos, você precisa atualizar MaxFieldLength e MaxRequestByte conforme descrito em Configurações do registro Http.sys para Windows.

Referência: lista completa de tipos de declaração de certificado de usuário e valores de exemplo

Tipo de declaração Valor de exemplo
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4