Partilhar via

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

Este artigo descreve como habilitar a autenticação de certificado de usuário nos Serviços de Federação do Active Directory (AD FS). Ele também fornece informações de 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 em 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. Normalmente, você faz isso 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 para seus certificados de usuário está no repositório NTAuth no Active Directory.
  • Se você estiver usando o AD FS no modo de autenticação de certificado alternativo, 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". Um exemplo é certauth.fs.contoso.com. Verifique também se o tráfego para esse nome de host é permitido por meio do firewall.
  • 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, verifique 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.

Nota

O AD FS não dá suporte a sugestões de nome de usuário com smart card ou autenticação baseada em certificado.

Habilitar a autenticação de certificado do usuário

Habilite a autenticação de certificado do usuário como um método de autenticação de intranet ou extranet no AD FS usando o console de Gerenciamento do AD FS ou o cmdlet do PowerShell Set-AdfsGlobalAuthenticationPolicy.

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 você precisar restringir o acesso com base no tipo de certificado, poderá usar as propriedades adicionais no certificado nas regras de autorização de emissão do AD FS para o aplicativo. 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 da ID do Microsoft Entra (por exemplo, AD FS) não podem impor o acesso baseado em dispositivo para recursos do Microsoft Entra. Por exemplo, eles não podem permitir apenas dispositivos gerenciados usando um serviço de MDM de terceiros.

    Para ajudar a proteger o acesso aos recursos corporativos na ID do Microsoft Entra e evitar qualquer vazamento 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 páginas de entrada para atender às necessidades dos usuários quando eles estiverem fazendo a autenticação de certificado. Um exemplo comum é alterar Entre com seu certificado X509 para tornar mais cordial e fácil de entender.

Configuração de autenticação integrada de certificados para o navegador Chrome em desktops do Windows

Quando um computador tem vários certificados de usuário (como certificados Wi-Fi) que atendem às finalidades da autenticação do cliente, o navegador Chrome nas áreas de trabalho do Windows solicitará que os usuários selecionem o certificado correto. Esse prompt pode ser confuso para os usuários. Para otimizar 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 de GPO (para definir as chaves do Registro). Isso exige que os certificados de cliente do 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 para Chrome, consulte lista de políticas do Chrome Enterprise.

Solucionar problemas de autenticação de certificado

Use as informações a seguir para solucionar problemas comuns quando você configurou o AD FS para autenticação de certificado para usuários.

Verifique se os emissores confiáveis 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 provar a posse do certificado do usuário e garantir que ele corresponda a um emissor confiável validando a cadeia de confiança 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 as falhas.

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

O AD FS executa a autenticação de certificado do usuário por padrão na porta 49443 com o mesmo nome de host que o AD FS (exemplo: adfs.contoso.com). Você também pode configurar o AD FS para usar a porta 443 (a 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.

Nota

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

O caso mais comum de problemas de conectividade de rede é que um firewall foi configurado incorretamente e bloqueia o tráfego para autenticação de certificado do usuário. Normalmente, você vê uma tela em branco ou um erro de 500 servidores quando esse problema ocorre. Para corrigi-lo:

  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. Seu engenheiro de rede deve executar esta etapa.

Verificar a conectividade de 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 endpoint do CRL para validar se o certificado que foi apresentado ainda é 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 conseguirem acessar o endpoint, a autenticação falhará. Siga as seguintes etapas para resolver o problema:

  1. Consulte seu engenheiro de PKI (infraestrutura de chave pública) para determinar quais endereços de CRL são usados para revogar os certificados de usuário do sistema PKI.
  2. Em cada servidor AD FS e WAP, verifique se os endereços de CRL estão acessíveis pelo protocolo utilizado (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

Você pode direcionar um único servidor AD FS ou WAP para facilitar a solução de problemas configurando a resolução DNS (arquivo de hosts no Windows) para apontar para um servidor específico. Essa técnica permite habilitar o rastreamento direcionando um servidor.

Verificar se há problemas de SNI

O AD FS requer dispositivos cliente (ou navegadores) e os balanceadores de carga para dar suporte à SNI (Indicação de Nome do Servidor). Alguns dispositivos cliente (por exemplo, versões mais antigas do Android) podem não dar suporte ao SNI. Além disso, os balanceadores de carga podem não dar suporte ao SNI ou podem não estar configurados para SNI. Nesses casos, é provável que você enfrente falhas nas certificações de usuários.

Para corrigir esse problema, trabalhe com seu engenheiro de rede para garantir que o balanceador de carga para AD FS e WAP dê suporte ao SNI. Se não houver suporte para SNI, use a seguinte 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. Digite Netsh http show sslcert.
  3. Copie o GUID do aplicativo e o hash de certificado do serviço de federação.
  4. Digite netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicationGUID}.

Verifique se o dispositivo cliente foi provisionado com o certificado corretamente

Você pode notar que alguns dispositivos estão funcionando corretamente, mas outros dispositivos não estão. Na maioria dos casos, isso significa que o certificado do usuário não foi provisionado corretamente em alguns dispositivos cliente. Siga estas etapas:

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

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

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

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

Em casos raros, um dispositivo cliente é atualizado para dar suporte apenas a uma versão mais alta do TLS (por exemplo, 1.3). Ou você pode ter o problema inverso, em que os servidores AD FS e WAP foram atualizados para usar apenas uma versão TLS mais alta à qual o dispositivo cliente não dá suporte.

Você pode usar ferramentas SSL online para verificar seus servidores AD FS e WAP e ver se eles são compatíveis com o dispositivo. Para obter mais informações sobre como controlar as versões do TLS, consulte Gerenciamento dos protocolos SSL/TLS e dos conjuntos de cifras para o AD FS.

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

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, seus usuários verão apenas um logon de senha. Para corrigir esse problema:

  1. Obtenha as configurações de domínio federadas 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ção de problemas adicional

Em casos raros, se as listas de CRL forem muito longas, elas poderão exceder o tempo limite para fazer download. Nesse caso, você precisa atualizar MaxFieldLength e MaxRequestByte, conforme as configurações do Registro descritas em 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