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

2025-01-15

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

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

Aplica-se a: Serviços de Federação do Active Directory
Número original do KB: 4034932

NTLM ou prompt de autenticação baseado em formulários

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

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

Para solucionar esse problema, verifique as configurações de 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.

Verifique o navegador do cliente do usuário

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

Na guia Avançado, verifique se a configuração Habilitar Autenticação Integrada do Windows está habilitada.
Após Segurança Sites>da intranet>local avançados, verifique se a URL do AD FS está na lista de sites.>
Após o nível Personalizado da intranet > local de segurança>, verifique se a configuração Logon automático somente na zona da intranet está selecionada.

Se você usa Firefox, Chrome ou Safari, certifique-se de que as configurações equivalentes nesses navegadores estejam ativadas.

Verificar as configurações do AD FS

Verificar a configuração WindowsIntegratedFallback

Inicie o Windows PowerShell com a opção Executar como administrador.
Obtenha a política de autenticação global executando o seguinte comando:
```
Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
```
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. Consulte 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

Obtenha a lista de agentes de usuário suportados executando o seguinte comando:
```
Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
```
Examine a lista de cadeias de caracteres do agente do usuário que o comando retorna.

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

Vá para http://useragentstring.com/ que detecta e mostra a string do agente do usuário do seu navegador.

Obtenha a lista de agentes de usuário suportados executando o seguinte comando:

$wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

Adicione a string do agente do usuário do seu navegador executando o seguinte comando:

$wiaStrings = $wiaStrings+"NewUAString"

Exemplo:

$wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"

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

Se a solicitação de autenticação for uma solicitação do WS-Federation, verifique se a solicitação inclui wauth= urn:oasis:names:tc:SAML:1.0:am:password.
Se a solicitação de autenticação for uma solicitação SAML, verifique se a solicitação inclui um elemento samlp:AuthnContextClassRef com o 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ê experimenta é esperado e controlado pela solicitação de autenticação de entrada. Trabalhe com o proprietário do aplicativo para alterar o comportamento.

Observação

Os módulos Azure AD e MSOnline PowerShell estão preteridos desde 30 de março de 2024. Para saber mais, leia a atualização de preterição. Após essa data, o suporte a esses módulos se limitará à assistência à migração para o SDK do Microsoft Graph PowerShell e às correções de segurança. Os módulos preteridos continuarão funcionando até 30 de março de 2025.

Recomendamos migrar para o Microsoft Graph PowerShell para interagir com o Microsoft Entra ID (antigo Azure AD). Para perguntas comuns sobre migração, consulte as Perguntas Frequentes sobre Migração. Observação: as versões 1.0.x do MSOnline poderão sofrer interrupções após 30 de junho de 2024.

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

Abra o Windows PowerShell com a opção "Executar como administrador".
Obtenha a configuração de federação de domínio existente executando o seguinte comando:
```
Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
```
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 do parâmetro PromptLoginBehavior são:
1. TranslateToFreshPasswordAuth: a ID do Microsoft Entra 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 no estado em que se encontra para o AD FS.
3. Desabilitado: nada é enviado para o AD FS.

Para saber mais sobre o comando Set-MSOLDomainFederationSettings, consulte Suporte ao parâmetro prompt=login dos Serviços de Federação do Active Directory.

Cenário do Microsoft Entra

Se a solicitação de autenticação enviada para a ID do Microsoft Entra incluir o parâmetro prompt=login, desabilite o recurso prompt=login executando o seguinte comando:

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

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

Cenário que não é do Microsoft Entra

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. Em caso afirmativo, modifique o parâmetro de solicitação para usar o método de autenticação esperado.

Verifique se o SSO está desabilitado

Se o SSO estiver desabilitado, ative-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 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.

Para verificar a configuração no servidor do AD FS, execute o comando a seguir em uma janela do Windows PowerShell.
```
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. Pule esta seção.
Observe o conjunto de regras de declaração configurado.

Verifique 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 declaração de condição: C:[Type=``…,Value=…]
A declaraçã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 não 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 respondente 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:

Execute o seguinte comando no Windows PowerShell:
```
Get-ADFSRelyingPartyTrust -TargetName ClaimApp
```
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)

Verifique 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 uma solicitação 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.

Obtenha a configuração atual de federação de domínio SupportsMFA executando o seguinte comando:
```
Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
```
Se a configuração SupportsMFA for FALSE, defina-a como TRUE executando o seguinte comando:
```
Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
```

Verifique se o SSO está desabilitado

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

Os usuários não podem fazer login 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á uma mensagem "Ocorreu um erro", "O serviço HTTP 503 não está disponível" ou alguma 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 o local onde você encontra esse problema.

Para solucionar esse problema, verifique se todos os usuários são 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á ativo e em execução e se a funcionalidade de autenticação está funcionando corretamente. Para abrir a página IdpInitiatedSignOn, siga estas etapas:

Habilite a página IdpInitiatedSignOn executando o seguinte comando no servidor do AD FS:
```
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
```
Em um computador que está dentro da sua rede, visite a seguinte página:
https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx
Insira as credenciais corretas de um usuário válido na página de entrada.

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

No servidor do AD FS, abra o Gerenciador do Servidor.
No Gerenciador do Servidor, clique em Ferramentas>Serviços.
Verifique se o Status dos Serviços de Federação do Active Directory é 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á ativo e em execução e se a funcionalidade de autenticação está funcionando corretamente. Para abrir a página IdpInitiatedSignOn, siga estas etapas:

Habilite a página IdpInitiatedSignOn executando o seguinte comando no servidor do AD FS:
```
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
```
Em um computador que esteja fora da rede, visite a seguinte página:
https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx
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.

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.

No servidor do AD FS, abra o Gerenciador do Servidor.
No Gerenciador do Servidor, clique em Ferramentas>Serviços.
Verifique se o Status dos Serviços de Federação do Active Directory é Em Execução.

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

No servidor do AD FS, abra o Console de Gerenciamento do AD FS.
Expanda Pontos de Extremidade de Serviço>.
Localize os pontos de extremidade e verifique se os status estão habilitados na coluna Habilitado .

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

Se o Microsoft Entra Connect estiver instalado, certifique-se de usá-lo para gerenciar e atualizar certificados SSL.

Se o Microsoft Entra 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 requer 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 de terceiros confiável, 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 AD FS primário:
Get-AdfsProperties | select hostname
O certificado não é revogado.

Verificar se há revogação de certificado. Se o certificado for revogado, a conexão SSL não 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 Microsoft Entra Connect, que facilita o gerenciamento de certificados SSL. Consulte Atualizar o certificado TLS/SSL para um farm dos Serviços de Federação do Active Directory (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 no . PFX do certificado e siga o assistente.

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

Liste os certificados que estão no repositório pessoal do computador local executando o seguinte comando:
dir Cert:\LocalMachine\My
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 esperada do certificado.

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

Get-AdfsSslCertificate

Se o certificado errado 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 de 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:

No Console de Gerenciamento do AD FS, expanda Certificados de Serviço>.
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:

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.
Verifique se o serviço do AD FS tem a permissão de leitura para o certificado:
1. Adicione o snap-in Certificados da conta do 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, clique em Todas as tarefas>Gerenciar chaves privadas.
4. Verifique se o adfssrv está listado em Nomes de grupo e usuário com a permissão de leitura .
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 clique em OK.
2. Em Insira 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.

Verifique se o DRS (Serviço de Registro de Dispositivo) está configurado no AD FS

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

Para verificar se o certificado SSL tem as SANs corretas, siga estas etapas:

Liste todos os sufixos UPN que estão sendo usados na organização executando o seguinte comando:
```
Get-AdfsDeviceRegistratrionUpnSuffix
```
Verifique se o certificado SSL tem as SANs necessárias configuradas.
Se o certificado SSL não tiver os nomes DRS corretos como SANs, obtenha um novo certificado SSL que tenha as SANs corretas para DRS e use-o como o certificado SSL para 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}: esta é a ID do aplicativo para o AD FS.
- {f955c070-e044-456c-ac00-e9e4275b3f04}: esta é a ID do aplicativo para o Proxy de Aplicativo Web.
Por exemplo, se o certificado SSL for especificado para uma associação de fallback como 0.0.0.0:443, certifique-se de que a associação seja 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 partes confiáveis

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

No servidor primário do AD FS, abra o Windows PowerShell com a opção Executar como administrador .
Adicione o componente AD FS 2.0 ao Windows PowerShell executando o seguinte comando:
```
Add-PSSnapin Microsoft.Adfs.PowerShell
```
Obtenha as informações da terceira parte confiável executando o seguinte comando:
```
$rp = Get-AdfsRelyingPartyTrust RPName
```
Obtenha as informações do cliente OAuth executando o seguinte comando:
```
$client = Get-AdfsClient ClientName
```

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

No servidor primário do AD FS, abra o Windows PowerShell com a opção Executar como administrador .
Obtenha as informações da terceira parte confiável executando o seguinte comando:
$rp = Get-AdfsWebApiApplication ResourceID
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 definidas no AD FS. As etapas na página anterior fornecem 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	Uma correspondência de prefixo ou curinga de $rp. WSFedEndpoint para uma terceira parte confiável do WS-Fed $rp. SamlEndpoints para uma terceira parte confiável SAML
ID do Cliente	$client. ID do cliente
URI de redirecionamento do cliente	Uma correspondência de prefixo de $client. RedirectUri

Se os itens na tabela corresponderem, verifique adicionalmente 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 tem a seguinte aparência:

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.

Parâmetros da solicitação	Configurações definidas no AD FS
client_id	$client. ID do cliente
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 da 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 no Windows Server 2016, execute o seguinte comando:
Get-AdfsWebApiApplication "ValueOfTheResourceParameter"

Solicitações do WS-Fed

Uma solicitação WS-Fed tem a seguinte aparência:

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:

Parâmetros da solicitação	Configurações definidas no AD FS
que reino	$rp. Identificador
wreply	Uma correspondência de prefixo ou correspondência curinga de $rp. WSFedEndpoint

Solicitações SAML

Uma solicitação SAML tem a seguinte aparência:

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

Decodifique o valor do parâmetro SAMLRequest usando a opção "From DeflatedSAML" no Assistente de Texto do 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 de Issuer corresponde a $rp.Identifier.

Notas 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 endpoint SAML pode usar ligaçõ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 "Assinatura" precisam estar presentes na solicitação.
$rp. RequestSigningCertificate: Este é 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.

Verifique o certificado de criptografia

Se $rp.EncryptClaims retornar Enabled, 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 esse 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.

Verifique 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.

Verificar o status do usuário com o Windows PowerShell

Faça logon em qualquer um dos controladores de domínio.
Abra o Windows PowerShell.

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

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

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

Verificar o status do usuário na interface do usuário

Faça logon em qualquer um dos controladores de domínio.
Abra o console de gerenciamento Usuários e Computadores do Active Directory.
Clique no nó Usuários , clique com o botão direito do mouse no usuário no painel direito e clique em Propriedades.
Clique na guia Conta.
Em Opções da conta, verifique se a conta está desabilitada está marcada.
Se a opção estiver marcada, desmarque-a.

Verificar se as propriedades do usuário foram atualizadas recentemente

Se alguma 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, certifique-se de que elas sejam selecionadas pelos serviços relacionados. Para verificar se houve alterações de propriedade em um usuário, siga estas etapas:

Faça logon em um controlador de domínio.
Abra o Windows PowerShell.
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"
Nos metadados, examine a coluna Hora/Data de cada atributo para obter qualquer pista para uma alteração. No exemplo a seguir, o atributo userPrincipleName usa uma data mais recente do que os outros atributos, o que representa uma alteração nos metadados do objeto do usuário.

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:

Faça logon em um controlador de domínio na floresta em que o AD FS está implantado.
Abra o console de gerenciamento de Domínios e Relações de Confiança do Active Directory.
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.
Clique na guia Relações de Confiança.
Em Domínios confiáveis por este domínio (relações de confiança de saída) ou Domínios que confiam neste domínio (relações de confiança de entrada), clique na relação de confiança a ser verificada e clique em Propriedades.
Clique em Validar.
Na caixa de diálogo Serviços de Domínio Active Directory, selecione uma das opções.
- Se você selecionar Não, recomendamos que 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 há necessidade de realizar o mesmo procedimento para o domínio recíproco.

Se essas etapas não ajudarem a resolver o problema, continue a solução de problemas com as etapas na seção Nem todos os usuários são afetados pelo problema e o usuário pode acessar algumas das terceiras 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 cenário do Microsoft Entra. Em caso afirmativo, 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 a ID do Microsoft Entra

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

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

Se o usuário não estiver na lista, sincronize-o com a ID do Microsoft Entra.

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

A ID do Microsoft Entra 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 o Microsoft Entra Connect para gerenciamento automático da confiança do AD FS com a ID do Microsoft Entra. Se você não estiver gerenciando a relação de confiança por meio do Microsoft Entra Connect, recomendamos que você faça isso baixando o Microsoft Entra Connect O Microsoft Entra 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 ao que a ID do Microsoft Entra usa, siga estas etapas:

Obtenha sourceAnchor e UPN no Microsoft Entra Connect.
1. Abra o Microsoft Entra Connect.
2. Clique em Exibir configuração atual.
3. Na página Examinar sua solução, anote os valores de SOURCE ANCHOR e USER PRINCIPAL NAME.
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 de terceira parte confiável com a ID do Microsoft Entra 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 para valores de immutableID e UPN são as mesmas que aparecem no Microsoft Entra Connect.
Se houver uma diferença, use um dos métodos abaixo:
- Se o AD FS for gerenciado pelo Microsoft Entra Connect, redefina a relação de confiança da terceira parte confiável usando o Microsoft Entra Connect.
- Se o AD FS não for gerenciado pelo Microsoft Entra Connect, corrija as declarações com os atributos corretos.

Se essas verificações não ajudarem 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 selecionado 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:

Obtenha o certificado de assinatura de token atual no AD FS executando o seguinte comando:
```
Get-ADFSCertificate -CertificateType token-signing
```
Na lista de certificados retornados, localize aquele com IsPrimary = TRUE e anote a impressão digital.
Obtenha a impressão digital do certificado de assinatura de token atual no parceiro de federação. O proprietário do aplicativo precisa fornecer isso.
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 parceiros da organização de recursos ou da organização da conta, representados no 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 da federação

Se os parceiros puderem acessar os metadados da federação, peça aos parceiros que usem os novos certificados.
Os parceiros não podem acessar os metadados da 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 que usem 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:

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.
Verifique com o proprietário do aplicativo o algoritmo usado no lado do aplicativo.
Verifique se os dois algoritmos correspondem.

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

No servidor do AD FS, despeje as regras de transformação de emissão executando o seguinte comando:
```
(Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
```
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
Peça ao proprietário do aplicativo o formato NameIdentifier exigido pelo aplicativo.
Verifique se os dois formatos NameIdentifier correspondem.
Se os formatos não corresponderem, configure a declaração NameIdentifier para usar o formato que o aplicativo exige. Para fazer isso, siga estas etapas:
1. Abra o console de gerenciamento do 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 atualize uma regra existente. Selecione ID do Nome para Tipo de declaração de entrada e especifique o formato que o aplicativo exige.

Se os dois algoritmos forem incompatíveis, atualize o algoritmo de assinatura usado pela relação de confiança de terceira parte confiável.

Abra o console de gerenciamento do AD FS.
Clique com o botão direito do mouse na relação de confiança de terceira parte confiável e clique em Propriedades.
Na guia Avançado, selecione o algoritmo para corresponder ao que o aplicativo exige.

Sobre a renovação automática de certificado

Se o certificado de assinatura de token ou o certificado de descriptografia de token for autoassinado, 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 da expiração.

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

Execute o comando a seguir:

Get-ADFSCerticate -CertificateType "token-signing"

Execute o cmdlet Get-ADFSCerticate, assinatura de token do tipo de certificado.

Examine os atributos do certificado.

Se os atributos Assunto e Emissor começarem com "CN=ADFS Signing...", o certificado será autoassinado e gerenciado pelo AutoCertRollover.

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

Execute o comando a seguir:

Get-ADFSProperties | FL AutoCertificateRollover

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

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 os 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 logon (SSO) com os Serviços de Federação do Active Directory (ADFS).

Verifique o DNS

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

Faça 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 é resolvido é 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 para acesso externo, verifique se o acesso ao ADFS aponta diretamente para um dos servidores ADFS ou para o balanceador de carga na frente dos servidores ADFS:

Faça ping no nome do serviço de federação (por exemplo, fs.contoso.com). Confirme se o endereço IP obtido é resolvido para um dos servidores ADFS ou para o balanceador de carga dos servidores 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 ADFS ou para o balanceador de carga dos servidores ADFS.

Verifique se o balanceador de carga está sendo usado

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

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

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

Se você estiver executando o 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 ADFS.
Verifique se a investigação está definida para a porta 80 e para o ponto de extremidade /adfs/probe.

Verifique as configurações do firewall

Verifique se o tráfego de entrada pela porta TCP 443 está habilitado em:

o firewall entre o servidor Proxy de Aplicativo Web e o farm de servidores de federação.
o firewall entre os clientes e o servidor 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 Proxy de Aplicativo Web 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 Proxy de Aplicativo Web e os servidores de federação.

Verifique se o endpoint está habilitado no proxy

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

No servidor ADFS, abra o Console de Gerenciamento do ADFS.
Expanda Pontos de Extremidade de Serviço>.
Localize o ponto de extremidade e verifique se o status está habilitado na coluna Proxy Habilitado .

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

Se o WAP (Proxy de Aplicativo Web) for implantado, a relação de confiança de proxy deverá ser estabelecida entre o servidor WAP e o servidor AD FS. Verifique se a relação de confiança de proxy foi 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 básicas

A relação de confiança de proxy é baseada em certificado de cliente. Quando você executa o assistente de pós-instalação do Proxy de Aplicativo Web, 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, http.sys usa a seguinte ordem de prioridade para que as associações de certificado SSL correspondam a um certificado:

Priority	Nome	Parâmetros	Descrição
1	IP	IP:porta	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 o Repositório Central de Certificados
4	Curinga IPv6	Porta	Correspondência de curinga IPv6 (a conexão deve ser IPv6)
5	Curinga de IP	Porta	Correspondência de curinga de IP (a conexão pode ser IPv4 ou IPv6)

O AD FS 2012 R2 e posterior são independentes do IIS (Serviços de Informações da Internet) e são executados como um serviço sobre http.sys. hostname:as associações de certificado SSL de porta são usadas pelo AD FS. Durante a autenticação do 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, a relação de confiança de proxy poderá não ser estabelecida.

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

No servidor do AD FS, execute o seguinte comando no 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. Observe a linha "Nome da Loja 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 do proxy, execute o script a seguir. Com base no problema detectado, execute a ação de acordo.

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 ligaçã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.

Remova a vinculação IP:port

Esteja ciente de que a ligaçã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.
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 vinculação Hostname:port para comunicação SSL.
Definir AdfsTrustedDevices como o repositório CTL para a associação IP:port

Este é 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 ligaçã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 o Microsoft Entra Connect estiver instalado, use o Microsoft Entra 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 o Microsoft Entra Connect não estiver instalado, gere novamente 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: Existe um certificado que não é autoassinado no repositório de certificados AdfsTrustedDevices

Se um certificado emitido pela CA estiver em um repositório de certificados em que normalmente existiriam apenas certificados autoassinados, a CTL gerada no repositório conterá apenas o certificado emitido pela CA. 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 Proxy de Aplicativo Web.

Os certificados para cada servidor Proxy de Aplicativo Web.

Portanto, exclua qualquer certificado emitido pela autoridade de certificação do repositório de certificados AdfsTrustedDevices.

Problema 4: Instale KB2964735 ou execute 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 ocorrer 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 nos outros servidores do AD FS.

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

Método 1

Instale a atualização documentada no KB 2964735 em todos os servidores do AD FS. Após a instalação da atualização, 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 com o repositório de certificados AdfsTrustedDevices. O script deve ser executado em todos os servidores do AD FS no farm.

Observação

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

Problema 5: Todas as verificações foram aprovadas. Mas o problema persiste

Verifique se há uma incompatibilidade de horário ou fuso horário. 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 AD FS e o servidor WAP

Se a terminação SSL estiver ocorrendo 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 Dump Token

O aplicativo Token de Despejo é útil ao depurar problemas com seu 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 Dump Token

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

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

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

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

No servidor do AD FS, abra o Windows PowerShell com a opção Executar como administrador .
Adicione o componente AD FS 2.0 ao Windows PowerShell executando o seguinte comando:
```
Add-PSSnapin Microsoft.Adfs.PowerShell
```
Obtenha as informações da terceira parte confiável executando o seguinte comando:
```
$rp = Get-AdfsRelyingPartyTrust RPName
```
Obtenha as informações do cliente OAuth executando o seguinte comando:
```
$client = Get-AdfsClient ClientName
```

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

No servidor do AD FS, abra o Windows PowerShell com a opção Executar como administrador .
Obtenha as informações da terceira parte confiável executando o seguinte comando:
```
$rp = Get-AdfsWebApiApplication ResourceID
```
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 Dump Token

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

$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 e ver se o usuário é afetado.

Obtenha 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 reivindicação reais. Para obter as regras de reivindicação, siga estas etapas:

Defina a política de controle de acesso como $null executando o seguinte comando:
Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
Obtenha as informações da terceira parte confiável executando o seguinte comando:
$rp = Get-AdfsRelyingPartyTrust RPName
Verifique $rp.IssuanceAuthorizationRules e $rp. AdditionalAuthenticationRules.

Usar o aplicativo Token de Despejo para diagnosticar a política de autorização

Defina a política de autenticação do Token de Despejo como a mesma que a terceira parte confiável com falha.
Faça com que o usuário abra um dos links a seguir, dependendo da política de autenticação definida.
- WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
- SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
- Forçar autenticação multifator: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
Faça login na página Login.

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

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

Configure as regras de declaração no aplicativo Token de Despejo para serem as mesmas que as regras de declaração da terceira parte confiável com falha.
Configure a política de autenticação do Token de Despejo para ser a mesma que a terceira parte confiável com falha.
Faça com que o usuário abra um dos links a seguir, dependendo da política de autenticação definida.
- WS-Fed: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
- SAML-P: https://FederationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
- Forçar autenticação multifator: https://FederationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
Faça login na página Login.

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

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

Verificar se um estado do dispositivo é necessário

Se as regras de autorização verificarem 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 Dump Token. As declarações ausentes podem bloquear a autenticação do dispositivo. Para obter as declarações do aplicativo Token de Despejo, siga as etapas na seção Usar o aplicativo Token de Despejo para diagnosticar a política de autorização no método Verificar a política de autorização se o usuário foi afetado .

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

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 o Acesso Condicional Local usando dispositivos registrados para verificar se o ambiente está configurado para autenticação de dispositivo.

Se todas as declarações estiverem presentes, veja se os valores das declarações do aplicativo Token de Despejo correspondem aos valores exigidos na política de autorização.

Compartilhar via

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

NTLM ou prompt de autenticação baseado em formulários

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

Verifique o navegador do cliente do usuário

Verificar as configurações do AD FS

Verificar a configuração WindowsIntegratedFallback

Verificar a configuração WIASupportedUsersAgents

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

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

Cenário do Microsoft Entra

Cenário que não é do Microsoft Entra

Verifique se o SSO está desabilitado

Prompt de autenticação multifator

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

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

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

Verifique 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

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

Verifique se o SSO está desabilitado

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

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

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

A entrada foi bem-sucedida

A entrada não foi bem-sucedida

Verifique se o certificado SSL está instalado corretamente

Verifique se o certificado SSL correto está em uso

Verifique se o certificado SSL está definido como o certificado de comunicação de serviço

Verifique se o DRS (Serviço de Registro de Dispositivo) está configurado no AD FS

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

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

Solicitações OAuth

Solicitações do WS-Fed

Solicitações SAML

Verifique o certificado de criptografia

Os dois métodos anteriores não funcionam

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

Verifique se o usuário está desabilitado

Verificar o status do usuário com o Windows PowerShell

Verificar o status do usuário na interface do usuário

Verificar se as propriedades do usuário foram atualizadas recentemente

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

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

Verifique se o usuário está sincronizado com a ID do Microsoft Entra

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

Esse problema ocorre no lado do aplicativo

As impressões digitais dos dois certificados correspondem

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

Sobre a renovação automática de certificado

Verificar os componentes e serviços relacionados ao ADFS

Verifique o DNS

Verifique se o balanceador de carga está sendo usado

Verifique as configurações do firewall

Verifique se o endpoint está habilitado no proxy

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

Informações básicas

Executar script para detectar problemas automaticamente

Problema 1: Há uma ligação específica de IP

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

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

Problema 4: Instale KB2964735 ou execute novamente o script com -syncproxytrustcerts

Método 1

Método 2

Problema 5: Todas as verificações foram aprovadas. Mas o problema persiste

Usar o aplicativo Dump Token

Antes de usar o aplicativo Dump Token

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

Configurar o aplicativo Dump Token

Métodos de solução de problemas

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

Obtenha os detalhes da política

Usar o aplicativo Token de Despejo para diagnosticar a política de autorização

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

Verificar se um estado do dispositivo é necessário

Comentários

Recursos adicionais