Solucionar problemas de SSO com Serviços de Federação do Active Directory (AD FS) (AD FS)

Este artigo ajuda você a resolver problemas de SSO (logon único) com o Serviços de Federação do Active Directory (AD FS) (AD FS).

Selecione uma das seguintes seções de acordo com o tipo de problema encontrado.

Aplica-se a: Serviços de Federação do Active Directory (AD FS) número de KB original: 4034932

Prompt de autenticação baseada em formulários ou NTLM

Durante a solução de problemas de SSO (logon único) com o Serviços de Federação do Active Directory (AD FS) (AD FS), se os usuários receberam um NTLM inesperado ou um prompt de autenticação baseado em formulários, siga as etapas neste artigo para solucionar esse problema.

Verificar as configurações de Autenticação Integrada do Windows

Para solucionar esse problema, verifique as configurações da Autenticação Integrada do Windows no navegador do cliente, as configurações do AD FS e os parâmetros de solicitação de autenticação.

Verificar o navegador do cliente do usuário

Verifique as seguintes configurações nas Opções da Internet:

  • Na guia Avançado , verifique se a configuração Habilitar Autenticação Integrada do Windows está habilitada.
  • Seguindo sites de>intranet> locaisde> segurança avançados, verifique se a URL do AD FS está na lista de sites.
  • Seguindo o nível > personalizado da intranet local de segurança, verifique se o logon automático somente na configuração zona da intranet >está selecionado.

Se você usar o Firefox, o Chrome ou o Safari, verifique se as configurações equivalentes nesses navegadores estão habilitadas.

Verificar as configurações do AD FS

Verificar a configuração WindowsIntegratedFallback
  1. Abra Windows PowerShell com a opção Executar como administrador.

  2. Obtenha a política de autenticação global executando o seguinte comando:

    Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
    
  3. Examine o valor do atributo WindowsIntegratedFallbackEnabled .

Se o valor for True, a autenticação baseada em formulários será esperada. Isso significa que a solicitação de autenticação vem de um navegador que não dá suporte à Autenticação Integrada do Windows. Confira a próxima seção sobre como obter suporte para seu navegador.

Se o valor for False, a Autenticação Integrada do Windows deverá ser esperada.

Verificar a configuração WIASupportedUsersAgents
  1. Obtenha a lista de agentes de usuário com suporte executando o seguinte comando:

    Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    
  2. Examine a lista de cadeias de caracteres do agente do usuário que o comando retorna.

Verifique se a cadeia de caracteres do agente do usuário do navegador está na lista. Caso contrário, adicione a cadeia de caracteres do agente do usuário seguindo as etapas abaixo:

  1. Vá para isso http://useragentstring.com/ que detecta e mostra a cadeia de caracteres do agente do usuário do navegador.

  2. Obtenha a lista de agentes de usuário com suporte executando o seguinte comando:

    $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    
  3. Adicione a cadeia de caracteres do agente do usuário do navegador executando o seguinte comando:

    $wiaStrings = $wiaStrings+"NewUAString"
    

    Exemplo:

    $wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"
    
  4. Atualize a configuração WIASupportedUserAgents executando o seguinte comando:

    Set-ADFSProperties -WIASupportedUserAgents $wiaStrings
    

Verificar os parâmetros de solicitação de autenticação

Verifique se a solicitação de autenticação especifica a autenticação baseada em formulários como o método de autenticação
  1. Se a solicitação de autenticação for uma WS-Federation, verifique se a solicitação inclui wauth= urn:oasis:names:tc:SAML:1.0:am:password.
  2. Se a solicitação de autenticação for uma solicitação SAML, verifique se a solicitação inclui um elemento samlp:AuthnContextClassRef com valor urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

Para obter mais informações, consulte Visão geral dos manipuladores de autenticação das páginas de entrada do AD FS.

Verifique se o aplicativo é o Microsoft Online Services para Office 365

Se o aplicativo que você deseja acessar não for o Microsoft Online Services, o que você experimentar será esperado e controlado pela solicitação de autenticação de entrada. Trabalhe com o proprietário do aplicativo para alterar o comportamento.

Se o aplicativo for o Microsoft Online Services, o que você experimentar poderá ser controlado pela configuração PromptLoginBehavior do objeto de realm confiável. Essa configuração controla se Azure AD locatários enviam prompt=login para o AD FS. Para definir a configuração PromptLoginBehavior , siga estas etapas:

  1. Abra Windows PowerShell com a opção "Executar como administrador".

  2. Obtenha a configuração de federação de domínio existente executando o seguinte comando:

    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
    
  3. Defina a configuração PromptLoginBehavior executando o seguinte comando:

    Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>
    

    Os valores para o parâmetro PromptLoginBehavior são:

    1. TranslateToFreshPasswordAuth: Azure AD envia wauth e wfresh para o AD FS em vez de prompt=login. Isso leva a uma solicitação de autenticação para usar a autenticação baseada em formulários.
    2. NativeSupport: o parâmetro prompt=login é enviado como está para o AD FS.
    3. Desabilitado: nada é enviado ao AD FS.

Para saber mais sobre o comando Set-MSOLDomainFederationSettings, consulte Serviços de Federação do Active Directory (AD FS) prompt=suporte ao parâmetro de logon.

Cenário do Azure Active Directory (Azure AD)

Se a solicitação de autenticação enviada Azure AD incluir o parâmetro prompt=login, desabilite a funcionalidade prompt=login executando o seguinte comando:

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

Depois de executar esse comando, Office 365 aplicativos não incluirão o parâmetro prompt=login em cada solicitação de autenticação.

Cenário Azure AD não personalizado

Parâmetros de solicitação como WAUTH e RequestedAuthNContext em solicitações de autenticação podem ter métodos de autenticação especificados. Verifique se outros parâmetros de solicitação impõem o prompt de autenticação inesperado. Nesse caso, modifique o parâmetro de solicitação para usar o método de autenticação esperado.

Verificar se o SSO está desabilitado

Se o SSO estiver desabilitado, habilite-o e teste se o problema foi resolvido.

Prompt de autenticação multifator

Para solucionar esse problema, verifique se as regras de declaração na terceira parte confiável estão definidas corretamente para autenticação multifator.

A autenticação multifator pode ser habilitada em um servidor do AD FS, em uma terceira parte confiável ou especificada em um parâmetro de solicitação de autenticação. Verifique as configurações para ver se elas estão definidas corretamente. Se a autenticação multifator for esperada, mas você for solicitado repetidamente, verifique as regras de emissão de terceira parte confiável para ver se as declarações de autenticação multifator são passadas para o aplicativo.

Para obter mais informações sobre a autenticação multifator no AD FS, consulte os seguintes artigos:

Verificar a configuração no servidor do AD FS e na terceira parte confiável

Para verificar a configuração no servidor do AD FS, valide as regras de autenticação adicionais globais. Para verificar a configuração na terceira parte confiável, valide as regras de autenticação adicionais para a relação de confiança da terceira parte confiável.

  1. Para verificar a configuração no servidor do AD FS, execute o comando a seguir em uma Windows PowerShell configuração.

    Get-ADFSAdditionalAuthenticationRule
    

    Para verificar a configuração na terceira parte confiável, execute o seguinte comando:

    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
    

    Observação

    Se os comandos não retornarem nada, as regras de autenticação adicionais não serão configuradas. Ignore esta seção.

  2. Observe o conjunto de regras de declaração configurado.

Verificar se a autenticação multifator está habilitada no conjunto de regras de declaração

Um conjunto de regras de declaração é composto pelas seguintes seções:

  • A instrução de condição: C:[Type=``…,Value=…]
  • A instrução de problema: => issue (Type=``…,Value=…)

Se a instrução de problema contiver a declaração a seguir, a autenticação multifator será especificada.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

Aqui estão exemplos que exigem que a autenticação multifator seja usada para dispositivos ingressados no local de trabalho e para acesso extranet, respectivamente:

  • c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")
  • c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

Verificar as regras de emissão de terceira parte confiável

Se o usuário receber repetidamente prompts de autenticação multifator depois de executar a primeira autenticação, é possível que a parte de resposta não esteja passando as declarações de autenticação multifator para o aplicativo. Para verificar se as declarações de autenticação são passadas, siga estas etapas:

  1. Execute o seguinte comando no Windows PowerShell:

    Get-ADFSRelyingPartyTrust -TargetName ClaimApp
    
  2. Observe o conjunto de regras definido nos atributos IssuanceAuthorizationRules ou IssuanceAuthorizationRulesFile.

O conjunto de regras deve incluir a seguinte regra de emissão para passar pelas declarações de autenticação multifator:
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==” http://schemas.microsoft.com/claims/multipleauthn”]=>issue(claim = c)

Verificar o parâmetro de solicitação de autenticação

Verifique se a solicitação de autenticação especifica a autenticação multifator como o método de autenticação

  • Se a solicitação de autenticação for WS-Federation, verifique se a solicitação inclui wauth= http://schemas.microsoft.com/claims/multipleauthn.
  • Se a solicitação de autenticação for uma solicitação SAML, verifique se a solicitação inclui um elemento samlp:AuthnContextClassRef com valor http://schemas.microsoft.com/claims/multipleauthn.

Para obter mais informações, consulte Visão geral dos manipuladores de autenticação das páginas de entrada do AD FS.

Verifique se o aplicativo é o Microsoft Online Services para Office 365

Se o aplicativo que você deseja acessar for o Microsoft Online Services para Office 365, verifique a configuração de federação de domínio SupportsMFA.

  1. Obtenha a configuração de federação de domínio SupportsMFA atual executando o seguinte comando:

    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
    
  2. Se a configuração SupportsMFA for FALSE, defina-a como TRUE executando o seguinte comando:

    Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
    

Verificar se o SSO está desabilitado

Se o SSO estiver desabilitado, habilite-o e teste se o problema foi resolvido.

Os usuários não podem fazer logon no site ou serviço de destino

Esse problema pode ocorrer na página de entrada do AD FS ou no lado do aplicativo.

Se o problema ocorrer na página de entrada do AD FS, você receberá um "Erro", "Serviço HTTP 503 não disponível" ou outra mensagem de erro. A URL da página de erro mostra o nome do serviço do AD FS, como fs.contoso.com.

Se o problema ocorrer no lado do aplicativo, a URL da página de erro mostrará o endereço IP ou o nome do site do serviço de destino.

Siga as etapas na seção a seguir de acordo com esse problema.

Esse problema ocorre na página de entrada do AD FS

Para solucionar esse problema, verifique se todos os usuários foram afetados pelo problema e se os usuários podem acessar todas as terceiras partes confiáveis.

Todos os usuários são afetados pelo problema e o usuário não pode acessar nenhuma das terceiras partes confiáveis

Vamos verificar a funcionalidade de entrada interna usando IdpInitiatedSignOn. Para fazer isso, use a página IdpInititatedSignOn para verificar se o serviço do AD FS está em execução e se a funcionalidade de autenticação está funcionando corretamente. Para abrir a página IdpInitiatedSignOn, siga estas etapas:

  1. Habilite a página IdpInitiatedSignOn executando o seguinte comando no servidor do AD FS:

    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
    
  2. Em um computador que está dentro de sua rede, visite a seguinte página:
    https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

  3. Insira as credenciais corretas de um usuário válido na página de entrada.

A entrada foi bem-sucedida

Se a entrada for bem-sucedida, verifique se o estado do serviço do AD FS está em execução.

  1. No servidor do AD FS, abra Gerenciador do Servidor.
  2. Na página Gerenciador do Servidor, clique em Serviços de>Ferramentas.
  3. Verifique se o status doServiços de Federação do Active Directory (AD FS) está em execução.

Em seguida, verifique a funcionalidade de entrada externa usando IdpInitiatedSignOn. Use a página IdpInititatedSignOn para verificar rapidamente se o serviço do AD FS está em execução e se a funcionalidade de autenticação está funcionando corretamente. Para abrir a página IdpInitiatedSignOn, siga estas etapas:

  1. Habilite a página IdpInitiatedSignOn executando o seguinte comando no servidor do AD FS:

    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
    
  2. Em um computador que está fora da sua rede, visite a seguinte página:
    https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

  3. Insira as credenciais corretas de um usuário válido na página de entrada.

Se a entrada não for bem-sucedida, consulte Verificar os componentes e serviços relacionados ao AD FS e verificar a relação de confiança do proxy.

Se a entrada for bem-sucedida, continue a solução de problemas com as etapas em Todos os usuários são afetados pelo problema e o usuário pode acessar algumas das terceiras partes confiáveis.

A entrada não foi bem-sucedida

Se a entrada não for bem-sucedida, verifique os componentes e serviços relacionados ao AD FS.

Verifique se o estado do serviço do AD FS está em execução.

  1. No servidor do AD FS, abra Gerenciador do Servidor.
  2. Na página Gerenciador do Servidor, clique em Serviços de>Ferramentas.
  3. Verifique se o status doServiços de Federação do Active Directory (AD FS) está em execução.

Verifique se os pontos de extremidade estão habilitados. O AD FS fornece vários pontos de extremidade para diferentes funcionalidades e cenários. Nem todos os pontos de extremidade estão habilitados por padrão. Para verificar o status dos pontos de extremidade, siga estas etapas:

  1. No servidor do AD FS, abra o Console de Gerenciamento do AD FS.

  2. Expanda pontos>de extremidade de serviço.

  3. Localize os pontos de extremidade e verifique se os status estão habilitados na coluna Habilitado .

    Verifique novamente o status de todos os pontos de extremidade do AD F S habilitados.

Em seguida, verifique se Azure AD Connect está instalado. Recomendamos que você use o Azure AD Connect, o que facilita o gerenciamento de certificados SSL.

Se Azure AD Connect estiver instalado, certifique-se de usá-lo para gerenciar e atualizar certificados SSL.

Se Azure AD Connect não estiver instalado, verifique se o certificado SSL atende aos seguintes requisitos do AD FS:

  • O certificado é de uma autoridade de certificação raiz confiável.

    O AD FS exige que os certificados SSL sejam de uma autoridade de certificação raiz confiável. Se o AD FS for acessado de computadores não ingressados no domínio, recomendamos que você use um certificado SSL de uma autoridade de certificação raiz confiável de terceiros, como DigiCert, VeriSign etc. Se o certificado SSL não for de uma autoridade de certificação raiz confiável, a comunicação SSL poderá ser interrompida.

  • O nome da entidade do certificado é válido.

    O nome da entidade deve corresponder ao nome do serviço de federação, não ao nome do servidor do AD FS ou a algum outro nome. Para obter o nome do serviço de federação, execute o seguinte comando no servidor primário do AD FS:
    Get-AdfsProperties | select hostname

  • O certificado não é revogado.

    Verifique se há revogação de certificado. Se o certificado for revogado, a conexão SSL não poderá ser confiável e será bloqueada pelos clientes.

Se o certificado SSL não atender a esses requisitos, tente obter um certificado qualificado para comunicação SSL. Recomendamos que você use o Azure AD Connect, o que facilita o gerenciamento de certificados SSL. Consulte Atualizar o certificado TLS/SSL para um farm Serviços de Federação do Active Directory (AD FS) (AD FS).

Se o certificado SSL atender a esses requisitos, verifique as seguintes configurações do certificado SSL.

Verifique se o certificado SSL está instalado corretamente

O certificado SSL deve ser instalado no repositório Pessoal do computador local em cada servidor de federação em seu farm. Para instalar o certificado, clique duas vezes em . Arquivo PFX do certificado e siga o assistente.

Para verificar se o certificado está instalado no local correto, siga estas etapas:

  1. Liste os certificados que estão no repositório Pessoal do computador local executando o seguinte comando:
    dir Cert:\LocalMachine\My
  2. Verifique se o certificado está na lista.
Verifique se o certificado SSL correto está em uso

Obtenha a impressão digital do certificado que está em uso para comunicação SSL e verifique se a impressão digital corresponde à impressão digital do certificado esperada.

Para obter a impressão digital do certificado que está em uso, execute o seguinte comando em Windows PowerShell:

Get-AdfsSslCertificate

Se o certificado incorreto for usado, defina o certificado correto executando o seguinte comando:

Set-AdfsSslCertificate –Thumbprint CorrectThumprint
Verifique se o certificado SSL está definido como o certificado de comunicação do serviço

O certificado SSL precisa ser definido como o certificado de comunicação de serviço em seu farm do AD FS. Isso não acontece automaticamente. Para verificar se o certificado correto está definido, siga estas etapas:

  1. No Console de Gerenciamento do AD FS, expanda Certificados>de Serviço.
  2. Verifique se o certificado listado em Comunicações de serviço é o certificado esperado.

Se o certificado errado estiver listado, defina o certificado correto e conceda ao serviço do AD FS a permissão De leitura para o certificado. Para fazer isso, siga estas etapas:

  1. Defina o certificado correto:

    1. Clique com o botão direito do mouse em Certificados e clique em Definir Certificado de Comunicação de Serviço.
    2. Selecione o certificado correto.
  2. Verifique se o serviço do AD FS tem a permissão De leitura para o certificado:

    1. Adicione o snap-in Certificados para a conta de computador local ao MMC (Console de Gerenciamento Microsoft).
    2. Expanda Certificados (Computador Local)>Pessoal>Certificados.
    3. Clique com o botão direito do mouse no certificado SSL e clique em Todas as Tarefas Gerenciar>Chaves Privadas.
    4. Verifique se adfssrv está listado em Nomes de grupo e de usuário com a permissão De leitura.
  3. Se adfssrv não estiver listado, conceda ao serviço do AD FS a permissão de leitura para o certificado:

    1. Clique em Adicionar, clique em Locais, clique no servidor e em OK.
    2. Em Inserir os nomes de objeto a serem selecionados, insira nt service\adfssrv, clique em Verificar Nomes e clique em OK.
      Se você estiver usando o AD FS com o DRS (Serviço de Registro de Dispositivo), insira nt service\drs .
    3. Conceda a permissão De leitura e clique em OK.
Verificar se o DRS (Serviço de Registro de Dispositivo) está configurado no AD FS

Se você configurou o AD FS com DRS, verifique se o certificado SSL também está configurado corretamente para o RDS. Por exemplo, se houver dois sufixos contoso.comfabrikam.comUPN e , enterpriseregistration.contoso.comenterpriseregistration.fabrikma.com o certificado deverá ter e como SANs (Nomes Alternativos da Entidade).

Para verificar se o certificado SSL tem os SANs corretos, siga estas etapas:

  1. Liste todos os sufixos UPN que estão sendo usados na organização executando o seguinte comando:

    Get-AdfsDeviceRegistratrionUpnSuffix
    
  2. Verifique se o certificado SSL tem os SANs necessários configurados.

  3. Se o certificado SSL não tiver os nomes de DRS corretos como SANs, obtenha um novo certificado SSL que tenha os SANs corretos para DRS e, em seguida, use-o como o certificado SSL para o AD FS.

Em seguida, verifique a configuração do certificado em servidores WAP e as associações de fallback:

  • Verifique se o certificado SSL correto está definido em todos os servidores WAP.

    1. Verifique se o certificado SSL está instalado no repositório Pessoal do computador local em cada servidor WAP.

    2. Obtenha o certificado SSL usado pelo WAP executando o seguinte comando:

      Get-WebApplicationProxySslCertificate
      
    3. Se o certificado SSL estiver errado, defina o certificado SSL correto executando o seguinte comando:

      Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
      
  • Verifique as associações de certificado e atualize-as, se necessário.

    Para dar suporte a casos não SNI, os administradores podem especificar associações de fallback. Além da associação padrão federationservicename:443, procure associações de fallback nas seguintes IDs de aplicativo:

    • {5d89a20c-beab-4389-9447-324788eb944a}: essa é a ID do aplicativo para o AD FS.
    • {f955c070-e044-456c-ac00-e9e4275b3f04}: essa é a ID do aplicativo para web Proxy de Aplicativo.

    Por exemplo, se o certificado SSL for especificado para uma associação de fallback como 0.0.0.0:443, verifique se a associação foi atualizada adequadamente quando o certificado SSL for atualizado.

Todos os usuários são afetados pelo problema e o usuário pode acessar algumas das terceiras partes confiáveis

Primeiro, vamos obter a terceira parte confiável e as informações do cliente OAuth. Se você usar uma terceira parte confiável convencional, siga estas etapas:

  1. No servidor primário do AD FS, abra Windows PowerShell com a opção Executar como administrador.

  2. Adicione o componente do AD FS 2.0 Windows PowerShell executando o seguinte comando:

    Add-PSSnapin Microsoft.Adfs.PowerShell
    
  3. Obtenha as informações da terceira parte confiável executando o seguinte comando:

    $rp = Get-AdfsRelyingPartyTrust RPName
    
  4. Obtenha as informações do cliente OAuth executando o seguinte comando:

    $client = Get-AdfsClient ClientName
    

Se você usar o recurso Grupo de Aplicativos Windows Server 2016, siga as etapas abaixo:

  1. No servidor primário do AD FS, abra Windows PowerShell com a opção Executar como administrador.

  2. Obtenha as informações da terceira parte confiável executando o seguinte comando:
    $rp = Get-AdfsWebApiApplication ResourceID

  3. Se o cliente OAuth for público, obtenha as informações do cliente executando o seguinte comando:

    $client = Get-AdfsNativeClientApplication ClientName
    

    Se o cliente for confidencial, obtenha as informações do cliente executando o seguinte comando:

    $client = Get-AdfsServerApplication ClientName
    

Agora, continue com os seguintes métodos de solução de problemas.

Verificar as configurações da terceira parte confiável e do cliente

O identificador de terceira parte confiável, a ID do cliente e o URI de redirecionamento devem ser fornecidos pelo proprietário do aplicativo e pelo cliente. No entanto, ainda pode haver uma incompatibilidade entre o que o proprietário fornece e o que está configurado no AD FS. Por exemplo, uma incompatibilidade pode ser causada por um erro de digitação. Verifique se as configurações fornecidas pelo proprietário correspondem às configuradas no AD FS. As etapas na página anterior obtêm as configurações definidas no AD FS por meio do PowerShell.

Configurações fornecidas pelo proprietário Configurações definidas no AD FS
ID da terceira parte confiável $rp. Identificador
URI de redirecionamento de terceira parte confiável Um prefixo ou uma correspondência curinga de
  • $rp. WSFedEndpoint para uma WS-Fed terceira parte confiável
  • $rp. SamlEndpoints para uma terceira parte confiável saml
ID do cliente $client. Clientid
URI de redirecionamento do cliente Uma correspondência de prefixo de $client. RedirectUri

Se os itens na tabela corresponderem, verifique também se essas configurações correspondem entre o que aparecem na solicitação de autenticação enviada ao AD FS e o que está configurado no AD FS. Tente reproduzir o problema durante o qual você captura um rastreamento do Fiddler na solicitação de autenticação enviada pelo aplicativo para o AD FS. Examine os parâmetros de solicitação para fazer as verificações a seguir, dependendo do tipo de solicitação.

Solicitações OAuth

Uma solicitação OAuth é semelhante à seguinte:

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

Verifique se os parâmetros de solicitação correspondem às configurações definidas no AD FS.

Solicitar parâmetros Configurações definidas no AD FS
client_id $client. Clientid
redirect_uri Uma correspondência de prefixo de @client_RedirectUri

O parâmetro "resource" deve representar uma terceira parte confiável válida no AD FS. Obtenha as informações de terceira parte confiável executando um dos comandos a seguir.

  • Se você usar uma terceira parte confiável convencional, execute o seguinte comando:
    Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
  • Se você usar o recurso Grupo de Aplicativos Windows Server 2016, execute o seguinte comando:
    Get-AdfsWebApiApplication "ValueOfTheResourceParameter"
WS-Fed solicitações

Uma WS-Fed é semelhante ao seguinte:

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

Verifique se os parâmetros de solicitação correspondem às configurações definidas no AD FS:

Solicitar parâmetros Configurações definidas no AD FS
wtrealm $rp. Identificador
wreply Uma correspondência de prefixo ou uma correspondência curinga de $rp. WSFedEndpoint
Solicitações SAML

Uma solicitação SAML é semelhante à seguinte:

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

Decodificar o valor do parâmetro SAMLRequest usando a opção "From DeflatedSAML" no Assistente de Texto fiddler. O valor decodificado é semelhante ao seguinte:

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

Faça as seguintes verificações dentro do valor decodificado:

  • Verifique se o nome do host no valor de Destino corresponde ao nome do host do AD FS.
  • Verifique se o valor do Emissor corresponde $rp.Identifier.

Observações adicionais para SAML:

  • $rp. SamlEndpoints: mostra todos os tipos de pontos de extremidade SAML. A resposta do AD FS é enviada para as URLs correspondentes configuradas nos pontos de extremidade. Um ponto de extremidade SAML pode usar associações de redirecionamento, postagem ou artefato para transmissão de mensagens. Todas essas URLs podem ser configuradas no AD FS.
  • $rp. SignedSamlRequestsRequired: se o valor for definido, a solicitação SAML enviada da terceira parte confiável precisará ser assinada. Os parâmetros "SigAlg" e "Signature" precisam estar presentes na solicitação.
  • $rp. RequestSigningCertificate: esse é o certificado de assinatura usado para gerar a assinatura na solicitação SAML. Verifique se o certificado é válido e peça ao proprietário do aplicativo para corresponder ao certificado.
Verificar o certificado de criptografia

Se $rp.EncryptClaims retornar Habilitado, a criptografia de terceira parte confiável será habilitada. O AD FS usa o certificado de criptografia para criptografar as declarações. Faça as seguintes verificações:

  • $rp. EncryptionCertificate: use este comando para obter o certificado e verificar se ele é válido.
  • $rp. EncryptionCertificateRevocationCheck: use este comando para verificar se o certificado atende aos requisitos de verificação de revogação.
Os dois métodos anteriores não funcionam

Para continuar a solução de problemas, consulte Usar o aplicativo token de despejo.

Nem todos os usuários são afetados pelo problema e o usuário não pode acessar nenhuma das terceiras partes confiáveis

Nesse cenário, faça as verificações a seguir.

Verificar se o usuário está desabilitado

Verifique o status do usuário no Windows PowerShell ou na interface do usuário. Se o usuário estiver desabilitado, habilite o usuário.

Verifique o status do usuário com Windows PowerShell
  1. Faça logon em qualquer um dos controladores de domínio.

  2. Abra o PowerShell do Windows.

  3. Verifique o status do usuário executando o seguinte comando:

    Get-ADUser -Identity <samaccountname of the user> | Select Enabled
    

    Use o Get-ADUser para verificar o status habilitado pelo usuário.

Verificar o status do usuário na interface do usuário
  1. Faça logon em qualquer um dos controladores de domínio.

  2. Abra o console Usuários e Computadores do Active Directory gerenciamento.

  3. Clique no nó Usuários , clique com o botão direito do mouse no usuário no painel direito e clique em Propriedades.

  4. Clique na guia Conta.

  5. Em Opções de conta, verifique se a conta está desabilitada está marcada.

    Verifique se a opção Conta está desabilitada está marcada.

  6. Se a opção estiver marcada, desmarque-a.

Verifique se as propriedades do usuário foram atualizadas recentemente

Se qualquer propriedade do usuário for atualizada no Active Directory, isso resultará em uma alteração nos metadados do objeto de usuário. Verifique o objeto de metadados do usuário para ver quais propriedades foram atualizadas recentemente. Se forem encontradas alterações, verifique se elas foram coletadas pelos serviços relacionados. Para verificar se houve alterações de propriedade em um usuário, siga estas etapas:

  1. Faça logon em um controlador de domínio.

  2. Abra o PowerShell do Windows.

  3. Obtenha os metadados do objeto de usuário executando o seguinte comando:
    repadmin /showobjmeta <destination DC> "user DN"

    Um exemplo do comando é:
    repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

  4. Nos metadados, examine a coluna Hora/Data de cada atributo para qualquer pista de uma alteração. No exemplo a seguir, o atributo userPrincipleName usa uma data mais recente do que os outros atributos que representam uma alteração nos metadados do objeto do usuário.

    Saída do comando repadmin showobjmeta.

Verifique a relação de confiança da floresta se o usuário pertence a outra floresta

Em um ambiente do AD FS de várias florestas, uma relação de confiança de floresta bidirecional é necessária entre a floresta em que o AD FS é implantado e as outras florestas que utilizam a implantação do AD FS para autenticação. Para verificar se a relação de confiança entre as florestas está funcionando conforme o esperado, siga estas etapas:

  1. Faça logon em um controlador de domínio na floresta em que o AD FS está implantado.

  2. Abra o console de gerenciamento de Domínios e Relações de Confiança do Active Directory .

  3. No console de gerenciamento, clique com o botão direito do mouse no domínio que contém a relação de confiança que você deseja verificar e clique em Propriedades.

  4. Clique na guia Relações de Confiança.

  5. Em Domínios confiáveis por esse domínio (relações de confiança de saída) ou Domínios que confiam nesse domínio (relações de confiança de entrada), clique na relação de confiança a ser verificada e clique em Propriedades.

  6. Clique em Validar.
    Na caixa Active Directory Domain Services caixa de diálogo, selecione uma das opções.

    • Se você selecionar Não, recomendamos que você repita o mesmo procedimento para o domínio recíproco.

    • Se você selecionar Sim, forneça uma credencial de usuário administrativo para o domínio recíproco. Não é necessário executar o mesmo procedimento para o domínio recíproco.

      Valide a confiança de entrada na Active Directory Domain Services caixa de diálogo.

Se essas etapas não ajudarem você a resolver o problema, continue a solução de problemas com as etapas em Nem todos os usuários são afetados pelo problema e o usuário pode acessar algumas das partes confiáveis.

Nem todos os usuários são afetados pelo problema e o usuário pode acessar algumas das terceiras partes confiáveis

Nesse cenário, verifique se esse problema ocorre em um Azure AD cenário. Nesse caso, faça essas verificações para solucionar esse problema. Caso contrário, consulte Usar o aplicativo Token de Despejo para solucionar esse problema.

Verifique se o usuário está sincronizado com Azure AD

Se um usuário estiver tentando fazer logon no Azure AD, ele será redirecionado ao AD FS para autenticação para um domínio federado. Um dos possíveis motivos para um logon com falha é que o usuário ainda não está sincronizado com Azure AD. Você pode ver um loop de Azure AD para o AD FS após a primeira tentativa de autenticação no AD FS. Para determinar se o usuário está sincronizado com Azure AD, siga estas etapas:

  1. Baixe e instale o módulo Azure AD PowerShell para Windows PowerShell.
  2. Abra Windows PowerShell com a opção "Executar como administrador".
  3. Inicie uma conexão com Azure AD executando o seguinte comando:
    Connect-MsolService
  4. Forneça a credencial de administrador global para a conexão.
  5. Obtenha a lista de usuários no Azure AD executando o seguinte comando:
    Get-MsolUser
  6. Verifique se o usuário está na lista.

Se o usuário não estiver na lista, sincronize o usuário com Azure AD.

Verificar immutableID e UPN na regra de declaração de emissão

Azure AD requer immutableID e o UPN do usuário para autenticar o usuário.

Observação

IMmutableID também é chamado de sourceAnchor nas seguintes ferramentas:

  • Azure AD Sync
  • Sincronização do Azure Active Directory (DirSync)

Os administradores podem usar Azure AD Connect para gerenciamento automático de confiança do AD FS com Azure AD. Se você não estiver gerenciando a relação de confiança por meio do Azure AD Connect, recomendamos que faça isso baixando o Azure AD Connect Azure AD Connect habilita o gerenciamento automático de regras de declaração com base nas configurações de sincronização.

Para verificar se as regras de declaração para immutableID e UPN no AD FS correspondem Azure AD uso, siga estas etapas:

  1. Obtenha sourceAnchor e UPN no Azure AD Connect.

    1. Abra Azure AD Connect.

    2. Clique em Exibir configuração atual.

      Selecione a configuração exibir atual na página de tarefas adicionais do Azure AD Connect.

    3. Na página Examinar Sua Solução , anote os valores de SOURCE ANCHOR e USER PRINCIPAL NAME.

      Obtenha os valores de ÂNCORA DE ORIGEM e NOME UPN na página do Azure AD Connect.

  2. Verifique os valores de immutableID (sourceAnchor) e UPN na regra de declaração correspondente configurada no servidor do AD FS.

    1. No servidor do AD FS, abra o console de gerenciamento do AD FS.

    2. Clique em Relações de Confiança de Terceira Parte Confiável.

    3. Clique com o botão direito do mouse na relação de confiança da terceira parte confiável com Azure AD e clique em Editar Política de Emissão de Declaração.

    4. Abra a regra de declaração para ID imutável e UPN.

    5. Verifique se as variáveis consultadas quanto a valores de immutableID e UPN são as mesmas que aparecem no Azure AD Connect.

      Verifique os valores de immutableID e UPN na regra de declaração correspondente configurada no servidor AD FS.

  3. Se houver uma diferença, use um dos métodos abaixo:

    • Se o AD FS for gerenciado pelo Azure AD Connect, redefina a relação de confiança da terceira parte confiável usando o Azure AD Connect.
    • Se o AD FS não for gerenciado pelo Azure AD Connect, corrija as declarações com os atributos corretos.

Se essas verificações não ajudarem você a resolver o problema, consulte Usar o aplicativo token de despejo para solucionar esse problema.

Esse problema ocorre no lado do aplicativo

Se o certificado de assinatura de token foi renovado recentemente pelo AD FS, verifique se o novo certificado foi coletado pelo parceiro de federação. Caso o AD FS use um certificado de descriptografia de token que também foi renovado recentemente, faça a mesma verificação também. Para verificar se o certificado de assinatura de token do AD FS atual no AD FS corresponde ao do parceiro de federação, siga estas etapas:

  1. Obtenha o certificado de assinatura de token atual no AD FS executando o seguinte comando:

    Get-ADFSCertificate -CertificateType token-signing
    
  2. Na lista de certificados retornados, localize aquele com IsPrimary = TRUE e anote a impressão digital.

  3. Obtenha a impressão digital do certificado de autenticação de token atual no parceiro de federação. O proprietário do aplicativo precisa fornecer isso.

  4. Compare as impressões digitais dos dois certificados.

Faça a mesma verificação se o AD FS usa um certificado de descriptografia de token renovado, exceto que o comando para obter o certificado de descriptografia de token no AD FS é o seguinte:

Get-ADFSCertificate -CertificateType token-decrypting

As impressões digitais dos dois certificados correspondem

Se as impressões digitais corresponderem, verifique se os parceiros estão usando os novos certificados do AD FS.

Se houver incompatibilidades de certificado, verifique se os parceiros estão usando os novos certificados. Os certificados são incluídos nos metadados de federação publicados pelo servidor do AD FS.

Observação

Os parceiros referem-se a todos os seus parceiros de organização de recursos ou de conta, representados em seu AD FS por relações de confiança de terceira parte confiável e relações de confiança do provedor de declarações.

  • Os parceiros podem acessar os metadados de federação

    Se os parceiros puderem acessar os metadados de federação, peça aos parceiros para usarem os novos certificados.

  • Os parceiros não podem acessar os metadados de federação

    Nesse caso, você deve enviar manualmente aos parceiros as chaves públicas dos novos certificados. Para fazer isso, siga estas etapas:

    1. Exporte as chaves públicas como arquivos .cert ou como arquivos .p7b para incluir todas as cadeias de certificados.
    2. Envie as chaves públicas para os parceiros.
    3. Peça aos parceiros para usarem os novos certificados.

As impressões digitais dos dois certificados não correspondem

Em seguida, verifique se há uma incompatibilidade de algoritmo de assinatura de token. Para fazer isso, siga estas etapas:

  1. Determine o algoritmo usado pela terceira parte confiável executando o seguinte comando:

    Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm
    

    Os valores possíveis são SHA1 ou SHA256.

  2. Verifique com o proprietário do aplicativo o algoritmo usado no lado do aplicativo.

  3. Verifique se os dois algoritmos correspondem.

Se os dois algoritmos corresponderem, verifique se o formato de ID de nome corresponde ao que o aplicativo requer.

  1. No servidor do AD FS, despejar as regras de transformação de emissão executando o seguinte comando:

    (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
    
  2. Localize a regra que emite a declaração NameIdentifier. Se essa regra não existir, ignore esta etapa.

    Aqui está um exemplo da regra:

    c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

    Observe o formato NameIdentifier na seguinte sintaxe:

    Properties["Property-type-URI"] = "ValueURI"

    Os formatos possíveis estão listados abaixo. O primeiro formato é o padrão.

    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient
  3. Peça ao proprietário do aplicativo o formato NameIdentifier exigido pelo aplicativo.

  4. Verifique se os dois formatos NameIdentifier correspondem.

  5. Se os formatos não corresponderem, configure a declaração NameIdentifier para usar o formato que o aplicativo requer. Para fazer isso, siga estas etapas:

    1. Abra o de gerenciamento AD FS.
    2. Clique em Relações de Confiança de Terceira Parte Confiável, selecione o parceiro de federação apropriado e clique em Editar Política de Emissão de Declarações no painel Ações .
    3. Adicione uma nova regra se não houver nenhuma regra para emitir a declaração NameIdentifier ou atualizar uma regra existente. Selecione a ID de nomepara o tipo de declaração de entrada e especifique o formato que o aplicativo requer.

    Adicione uma regra de declaração de transformação se não houver nenhuma regra para emitir a declaração NameIdentifier ou atualizar uma regra existente.

Se os dois algoritmos não coincidem, atualize o algoritmo de assinatura usado pela relação de confiança da terceira parte confiável.

  1. Abra o de gerenciamento AD FS.

  2. Clique com o botão direito do mouse na relação de confiança da terceira parte confiável e clique em Propriedades.

  3. Na guia Avançado , selecione o algoritmo para corresponder ao que o aplicativo requer.

    Selecione o algoritmo para corresponder ao que o aplicativo requer na guia Avançado na caixa de diálogo De configuração Propriedades.

Sobre a renovação automática do certificado

Se o certificado de autenticação de token ou o certificado de descriptografia de token forem autoassinados, o AutoCertificateRollover será habilitado por padrão nesses certificados e o AD FS gerenciará a renovação automática dos certificados quando eles estiverem próximos à expiração.

Para determinar se você está usando certificados autoassinados, siga estas etapas:

  1. Execute o seguinte comando:

    Get-ADFSCerticate -CertificateType "token-signing"
    

    Execute o cmdlet Get-ADFSCerticate, assinatura de token do Tipo de Certificado.

  2. Examine os atributos de certificado.

    Se os atributos assunto e emissor começam com "CN=ADFS Signing...", o certificado é autoassinado e gerenciado pelo AutoCertRollover.

Para confirmar se os certificados são renovados automaticamente, siga estas etapas:

  1. Execute o seguinte comando:

    Get-ADFSProperties | FL AutoCertificateRollover
    

    Execute o Get-ADFSProperties cmdlet para confirmar se os certificados são renovados automaticamente.

  2. Examine o atributo AutoCertificateRollover.

    • Se AutoCertificateRollover = TRUE, o AD FS gerará automaticamente novos certificados (30 dias antes da expiração por padrão) e os definirá como certificados primários (25 dias antes da expiração).
    • Se AutoCertificateRollover = FALSE, você precisará substituir manualmente os certificados.

Este artigo apresenta como verificar os componentes e serviços relacionados ao ADFS. Essas etapas podem ajudar quando você estiver solucionando problemas de SSO (logon) com o Serviços de Federação do Active Directory (AD FS) (ADFS).

Verificar DNS

O acesso ao ADFS deve apontar diretamente para um dos servidores WAP (web Proxy de Aplicativo) ou o balanceador de carga na frente dos servidores WAP. Faça as seguintes verificações:

  • Executar ping no nome do serviço de federação (por exemplo, fs.contoso.com). Confirme se o endereço IP para o qual o Ping resolve é de um dos servidores WAP ou do balanceador de carga dos servidores WAP.
  • Verifique se há um registro A para o serviço de federação no servidor DNS. O registro A deve apontar para um dos servidores WAP ou para o balanceador de carga dos servidores WAP.

Se o WAP não for implementado em seu cenário de acesso externo, verifique se o acesso ao ADFS aponta diretamente para um dos servidores do ADFS ou para o balanceador de carga na frente dos servidores do ADFS:

  • Executar ping no nome do serviço de federação (por exemplo, fs.contoso.com). Confirme se o endereço IP que você obtém é resolvido para um dos servidores ADFS ou o balanceador de carga dos servidores do ADFS.
  • Verifique se há um registro A para o serviço de federação no servidor DNS. O registro A deve apontar para um dos servidores do ADFS ou para o balanceador de carga dos servidores do ADFS.

Verificar se o balanceador de carga é usado

Verifique se o firewall está bloqueando o tráfego entre:

  • O servidor do ADFS e o balanceador de carga.
  • O servidor WAP (web Proxy de Aplicativo) e o balanceador de carga se o WAP for usado.

Se a investigação estiver habilitada no balanceador de carga, verifique o seguinte:

  • Se você estiver executando Windows Server 2012 R2, verifique se o pacote cumulativo de atualizações de agosto de 2014 está instalado.
  • Verifique se a porta 80 está habilitada no firewall nos servidores WAP e servidores ADFS.
  • Verifique se a investigação está definida para a porta 80 e para o ponto de extremidade /adfs/probe.

Verificar as configurações de firewall

Verifique se o tráfego de entrada por meio da porta TCP 443 está habilitado em:

  • o firewall entre o servidor web Proxy de Aplicativo e o farm de servidores de federação.
  • o firewall entre os clientes e o servidor web Proxy de Aplicativo web.

Verifique se o tráfego de entrada por meio da porta TCP 49443 está habilitado no firewall entre os clientes e o servidor web Proxy de Aplicativo quando as seguintes condições forem verdadeiras:

  • A autenticação de cliente TLS usando o certificado X.509 está habilitada.
  • Você está usando o ADFS no Windows Server 2012 R2.

Observação

A configuração não é necessária no firewall entre o servidor web Proxy de Aplicativo e os servidores de federação.

Verifique se o ponto de extremidade está habilitado no proxy

O ADFS fornece vários pontos de extremidade para diferentes funcionalidades e cenários. Nem todos os pontos de extremidade estão habilitados por padrão. Para verificar se o ponto de extremidade está habilitado no proxy, siga estas etapas:

  1. No servidor do ADFS, abra o Console de Gerenciamento do ADFS.

  2. Expanda pontos>de extremidade de serviço.

  3. Localize o ponto de extremidade e verifique se o status está habilitado na coluna Habilitado para Proxy .

    Verifique o status dos pontos de extremidade AD F S mostrado na coluna Habilitado para Proxy.

Verificar a relação de confiança do proxy

Se a Proxy de Aplicativo Web (WAP) for implantada, a relação de confiança de proxy deverá ser estabelecida entre o servidor WAP e o servidor do AD FS. Verifique se a relação de confiança do proxy está estabelecida ou começa a falhar em algum momento.

Observação

As informações nesta página se aplicam ao AD FS 2012 R2 e posterior.

Informações gerais

A relação de confiança de proxy é baseada em certificado do cliente. Quando você executa o assistente de Proxy de Aplicativo web pós-instalação, o assistente gera um certificado de cliente autoassinado usando as credenciais especificadas no assistente. Em seguida, o assistente insere o certificado no banco de dados de configuração do AD FS e o adiciona ao repositório de certificados AdfsTrustedDevices no servidor do AD FS.

Para qualquer comunicação SSL, o http.sys usa a seguinte ordem de prioridade para que as associações de certificado SSL correspondam a um certificado:

Prioridade Nome Parâmetros Descrição
1 IP IP:port Correspondência exata de IP e porta
2 Sni Nome do host:porta Correspondência exata do nome do host (a conexão deve especificar sNI)
3 Ccs Porta Invocar Repositório de Certificados Central
4 Curinga IPv6 Porta Correspondência de curinga IPv6 (a conexão deve ser IPv6)
5 Curinga IP Porta Correspondência de curinga ip (a conexão pode ser IPv4 ou IPv6)

O AD FS 2012 R2 e posterior são independentes dos Serviços de Informações da Internet (IIS) e são executados como um serviço sobre http.sys. as associações de certificado SSL hostname:port são usadas pelo AD FS. Durante a autenticação de certificado do cliente, o AD FS envia uma CTL (lista de certificados confiáveis) com base nos certificados no repositório AdfsTrustedDevices. Se uma associação de certificado SSL para o servidor do AD FS usar IP:port ou o repositório CTL não for AdfsTrustedDevices, talvez não seja estabelecida uma relação de confiança de proxy.

Obter as associações de certificado SSL para o AD FS

No servidor do AD FS, execute o seguinte comando Windows PowerShell:
netsh http show sslcert

Na lista de associações retornadas, procure aquelas com a ID do Aplicativo de 5d89a20c-beab-4389-9447-324788eb944a. Aqui está um exemplo de uma associação íntegra. Anote a linha "Nome do Repositório Ctl".

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)  
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

Executar script para detectar problemas automaticamente

Para detectar automaticamente problemas com a relação de confiança de proxy, execute o script a seguir. Com base no problema detectado, execute a ação adequadamente.

param
(
  [switch]$syncproxytrustcerts
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1
$certbindingissuedetected = $false
While($i -lt $httpsslcertoutput.count)
{
        $ipport = $false
        $hostnameport = $false
        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }
        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }
        ## Check for IP specific certificate bindings
        if ( ( $ipport -eq $true ) )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )
            {
                $warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning
                $certbindingissuedetected = $true
            }
            $i = $i + 14
            continue
        }
        ## check that CTL Store is set for ADFS service binding
        elseif ( $hostnameport -eq $true )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )
            {
                Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"
                $certbindingissuedetected = $true
            }
        $i = $i + 14
        continue
        }
    $i++
}
If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues detected" }
}
function checkadfstrusteddevicesstore()
{
## check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store
Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"
$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}
If ( $certlist.count -gt 0 )
{
    Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"
    $certlist | Format-List Subject
}
Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }
}
function checkproxytrustcerts
{
    Param ([bool]$repair=$false)
    Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")
    $doc = new-object Xml
    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")
    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"
    $cli = new-object System.Data.SqlClient.SqlConnection
    $cli.ConnectionString = $connString
    $cmd = new-object System.Data.SqlClient.SqlCommand
    $cmd.CommandText = $command
    $cmd.Connection = $cli
    $cli.Open()
    $configString = $cmd.ExecuteScalar()
    $configXml = new-object XML
    $configXml.LoadXml($configString)
    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2
    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices
    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")
    $store.open("MaxAllowed")
    $atLeastOneMismatch = $false
    $badCerts = @()
    foreach($rawCert in $rawCerts)
    {   
        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
        $now = Get-Date
        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))
        {
            $certThumbprint = $cert.Thumbprint
         $certSubject = $cert.Subject
         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue
         if ($ctlMatch -eq $null)
         {
       $atLeastOneMismatch = $true
          Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"
       if ($repair -eq $true)
       {
        write-Warning "Attempting to repair"
        $store.Add($cert)
        Write-Warning "Repair successful"
       }
                else
                {
                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")
                }
         }
        }
    }
    $store.Close()
    if ($atLeastOneMismatch -eq $false)
    {
     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")
    }
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")

Problema 1: há uma associação específica de IP

A associação pode entrar em conflito com a associação de certificado do AD FS na porta 443.

A associação IP:port tem a precedência mais alta. Se uma associação IP:port estiver nas associações de certificado SSL do AD FS, http.sys sempre usará o certificado para a associação para comunicação SSL. Para resolver esse problema, use os métodos a seguir.

  1. Remover a associação IP:port

    Lembre-se de que a associação IP:port pode voltar depois que você a removeu. Por exemplo, um aplicativo configurado com essa associação IP:port pode recriá-lo automaticamente na próxima inicialização do serviço.

  2. Usar outro endereço IP para comunicação SSL do AD FS

    Se a associação IP:port for necessária, resolva o FQDN do serviço ADFS para outro endereço IP que não seja usado em nenhuma associação. Dessa forma, http.sys usará a associação hostname:port para comunicação SSL.

  3. Definir AdfsTrustedDevices como o Repositório CTL para a associação IP:port

    Esse será o último recurso se você não puder usar os métodos acima. Mas é melhor entender as seguintes condições antes de alterar o repositório CTL padrão para AdfsTrustedDevices:

    • Por que a associação IP:port está lá.
    • Se a associação depender do repositório CTL padrão para autenticação de certificado do cliente.

Problema 2: a associação de certificado do AD FS não tem o Nome do Repositório CTL definido como AdfsTrustedDevices

Se Azure AD Connect estiver instalado, use o AAD Connect para definir o Nome do Repositório CTL como AdfsTrustedDevices para as associações de certificado SSL em todos os servidores do AD FS. Se Azure AD Connect não estiver instalado, regenere as associações de certificado do AD FS executando o comando a seguir em todos os servidores do AD FS.

Set-AdfsSslCertificate -Thumbprint Thumbprint

Problema 3: um certificado que não é autoassinado existe no repositório de certificados AdfsTrustedDevices

Se um certificado emitido pela AC estiver em um repositório de certificados em que apenas certificados autoassinados normalmente existiriam, a CTL gerada do repositório conteria apenas o certificado emitido pela AC. O repositório de certificados AdfsTrustedDevices é um repositório que deve ter apenas certificados autoassinados. Esses certificados são:

  • MS-Organization-Access: o certificado autoassinado usado para emitir certificados de ingresso no local de trabalho.
  • Confiança de proxy do ADFS: os certificados para cada servidor de Proxy de Aplicativo Web.

Os certificados para cada servidor web Proxy de Aplicativo web.

Portanto, exclua qualquer certificado emitido pela AC do repositório de certificados AdfsTrustedDevices.

Problema 4: instalar o KB2964735 ou executar novamente o script com -syncproxytrustcerts

Quando uma relação de confiança de proxy é estabelecida com um servidor do AD FS, o certificado do cliente é gravado no banco de dados de configuração do AD FS e adicionado ao repositório de certificados AdfsTrustedDevices no servidor do AD FS. Para uma implantação de farm do AD FS, espera-se que o certificado do cliente seja sincronizado com os outros servidores do AD FS. Se a sincronização não acontecer por algum motivo, uma relação de confiança de proxy só funcionará no servidor do AD FS com o qual a relação de confiança foi estabelecida, mas não em relação aos outros servidores do AD FS.

Para resolver esse problema, use um dos métodos a seguir.

Método 1

Instale a atualização documentada em KB 2964735 em todos os servidores do AD FS. Depois que a atualização for instalada, espera-se que uma sincronização do certificado do cliente ocorra automaticamente.

Método 2

Execute o script com a opção – syncproxytrustcerts para sincronizar manualmente os certificados do cliente do banco de dados de configuração do AD FS para o repositório de certificados AdfsTrustedDevices. O script deve ser executado em todos os servidores do AD FS no farm.

Observação

Essa não é uma solução permanente porque os certificados do cliente serão renovados regularmente.

Problema 5: todas as verificações são aprovadas. Mas o problema persiste

Verifique se há uma incompatibilidade de fuso horário ou hora. Se a hora corresponder, mas o fuso horário não, a relação de confiança de proxy também não será estabelecida.

Verifique se há terminação SSL entre o servidor do AD FS e o servidor WAP

Se a terminação SSL estiver acontecendo em um dispositivo de rede entre os servidores do AD FS e o servidor WAP, a comunicação entre o AD FS e o WAP será interrompida porque a comunicação é baseada no certificado do cliente.

Desabilite a terminação SSL no dispositivo de rede entre os servidores AD FS e WAP.

Usar o aplicativo Token de Despejo

O aplicativo token de despejo é útil ao depurar problemas com o serviço de federação, bem como validar regras de declaração personalizadas. Não é uma solução oficial, mas uma boa solução de depuração independente recomendada para fins de solução de problemas.

Antes de usar o aplicativo token de despejo

Antes de usar o aplicativo Token de Despejo, você precisa:

  1. Obtenha as informações da terceira parte confiável para o aplicativo que você deseja acessar. Se a autenticação OAuth for implementada, obtenha as informações do cliente OAuth também.
  2. Configure o aplicativo Token de Despejo.

Obter a terceira parte confiável e as informações do cliente OAuth

Se você usar uma terceira parte confiável convencional, siga estas etapas:

  1. No servidor do AD FS, abra Windows PowerShell com a opção Executar como administrador.

  2. Adicione o componente do AD FS 2.0 Windows PowerShell executando o seguinte comando:

    Add-PSSnapin Microsoft.Adfs.PowerShell
    
  3. Obtenha as informações da terceira parte confiável executando o seguinte comando:

    $rp = Get-AdfsRelyingPartyTrust RPName
    
  4. Obtenha as informações do cliente OAuth executando o seguinte comando:

    $client = Get-AdfsClient ClientName
    

Se você usar o recurso Grupo de Aplicativos Windows Server 2016, siga as etapas abaixo:

  1. No servidor do AD FS, abra Windows PowerShell com a opção Executar como administrador.

  2. Obtenha as informações da terceira parte confiável executando o seguinte comando:

    $rp = Get-AdfsWebApiApplication ResourceID
    
  3. Se o cliente OAuth for público, obtenha as informações do cliente executando o seguinte comando:

    $client = Get-AdfsNativeClientApplication ClientName
    

    Se o cliente OAuth for confidencial, obtenha as informações do cliente executando o seguinte comando:

    $client = Get-AdfsServerApplication ClientName
    

Configurar o aplicativo token de despejo

Para configurar o aplicativo de Token de Despejo, execute os seguintes comandos na Windows PowerShell janela:

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

Agora, continue com os seguintes métodos de solução de problemas. No final de cada método, veja se o problema foi resolvido. Caso contrário, use outro método.

Métodos de solução de problemas

Verifique a política de autorização para ver se o usuário foi afetado

Nesse método, você começa obtendo os detalhes da política e, em seguida, usa o aplicativo token de despejo para diagnosticar a política para ver se o usuário é afetado.

Obter os detalhes da política

$rp. IssuanceAuthorizationRules mostra as regras de autorização da terceira parte confiável.

No Windows Server 2016 e versões posteriores, você pode usar $rp. AccessControlPolicyName para configurar a política de autenticação e autorização. Se $rp. AccessControlPolicyName tem valor, uma política de controle de acesso está em vigor que rege a política de autorização. Nesse caso, $rp. IssuanceAuthorizationRules está vazio. Use $rp. ResultantPolicy para descobrir detalhes sobre a política de controle de acesso.

Se $rp. ResultantPolicy não tem os detalhes sobre a política, examine as regras de declaração reais. Para obter as regras de declaração, siga estas etapas:

  1. Defina a política de controle de $null executando o seguinte comando:
    Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
  2. Obtenha as informações da terceira parte confiável executando o seguinte comando:
    $rp = Get-AdfsRelyingPartyTrust RPName
  3. Verifique $rp.IssuanceAuthorizationRules e $rp. AdditionalAuthenticationRules.
Usar o aplicativo Token de Despejo para diagnosticar a política de autorização
  1. Defina a política de autenticação de Token de Despejo como a mesma que a terceira parte confiável com falha.

  2. Fazer com que o usuário abra um dos links a seguir, dependendo da política de autenticação definida.

    • WS-Fed: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Forçar a autenticação multifator: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  3. Faça logon na Sign-In página.

O que você obtém é o conjunto de declarações do usuário. Veja se há algo na política de autorização que nega ou permite explicitamente ao usuário com base nessas declarações.

Verifique se alguma declaração ausente ou inesperada causa negação de acesso ao recurso

  1. Configure as regras de declaração no aplicativo token de despejo para que sejam iguais às regras de declaração da terceira parte confiável com falha.

  2. Configure a política de autenticação do Token de Despejo para ser a mesma que a terceira parte confiável com falha.

  3. Fazer com que o usuário abra um dos links a seguir, dependendo da política de autenticação definida.

    • WS-Fed: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • Forçar a autenticação multifator: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  4. Faça logon na Sign-In página.

Esse é o conjunto de declarações que a terceira parte confiável obterá para o usuário. Se alguma declaração estiver ausente ou inesperada, examine a política de emissão para descobrir o motivo.

Se todas as declarações estiverem presentes, verifique com o proprietário do aplicativo para ver qual declaração está ausente ou inesperada.

Verificar se um estado do dispositivo é necessário

Se as regras de autorização verificarem se há declarações de dispositivo, verifique se alguma dessas declarações de dispositivo está ausente na lista de declarações que você obtém do aplicativo token de despejo. As declarações ausentes podem bloquear a autenticação do dispositivo. Para obter as declarações do aplicativo token de despejo, siga as etapas no aplicativo Usar o token de despejo para diagnosticar a seção de política de autorização na política de autorização de verificação se o usuário tiver sido afetado .

A seguir estão as declarações do dispositivo. As regras de autorização podem usar algumas delas.

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
  • http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
  • http://schemas.microsoft.com/2014/02/deviceusagetime
  • http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
  • http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

Se houver uma declaração ausente, siga as etapas em Configurar Acesso Condicional Local usando dispositivos registrados para verificar se o ambiente está configurado para autenticação do dispositivo.

Se todas as declarações estiverem presentes, veja se os valores das declarações do aplicativo token de despejo correspondem aos valores necessários na política de autorização.