Solucionar problemas de logon único contínuo do Microsoft Entra

Este artigo ajuda você a localizar informações de solução de problemas comuns relacionados ao SSO Contínuo (logon único contínuo) do Microsoft Entra.

Problemas conhecidos

• Em alguns casos, habilitar o SSO contínuo pode levar até 30 minutos.
• Caso desabilite e habilite novamente o SSO Contínuo em seu locatário, os usuários não obterão a experiência de logon único até que os tíquetes de Kerberos deles, armazenados em cache e normalmente válidos por 10 horas, tenham se expirado.
• Se o SSO Contínuo for bem-sucedido, o usuário não terá a oportunidade de selecionar Manter-me conectado.
• Os clientes Win32 do Microsoft 365 (Outlook, Word, Excel e outros) com versões 16.0.8730.xxxx e mais recentes podem usar um fluxo não interativo. Não há suporte para outras versões; nessas versões, os usuários inserirão seus nomes de usuário, mas não senhas, para entrar. Para o OneDrive, ative o recurso de Configuração silenciosa do OneDrive, para uma experiência de logon silenciosa.
• O SSO Contínuo não funciona no modo de navegação particular no Firefox.
• O SSO contínuo não funciona no Internet Explorer quando o modo de Proteção Avançada está ativado.
• O Microsoft Edge (herdado) não tem mais suporte
• O SSO contínuo não funciona em navegadores de dispositivos móveis no iOS e no Android.
• Se um usuário fizer parte de muitos grupos no Active Directory, o tíquete Kerberos do usuário provavelmente será muito grande para processar e isso causará falha no SSO Contínuo. Solicitações de HTTPS do Microsoft Entra podem ter cabeçalhos com um tamanho máximo de 50 KB; os tíquetes Kerberos precisam ser muito menores do que o limite para acomodar outros artefatos do Microsoft Entra (tipicamente, 2 a 5 KB), como cookies. Nossa recomendação é reduzir as associações de grupo do usuário e tentar novamente.
• Se você estiver sincronizando 30 ou mais florestas do Active Directory, não será possível habilitar o SSO Contínuo usando o Microsoft Entra Connect. Como alternativa, você poderá habilitar manualmente o recurso em seu locatário.
• Adicionar a URL do serviço Microsoft Entra (https://autologon.microsoftazuread-sso.com) à zona Sites confiáveis em vez da zona Intranet local bloqueia a entrada dos usuários.
• O SSO contínuo dá suporte aos tipos de criptografia AES256_HMAC_SHA1, AES128_HMAC_SHA1 e RC4_HMAC_MD5 para Kerberos. É recomendável que o tipo de criptografia para a conta AzureADSSOAcc$ seja definido como AES256_HMAC_SHA1 ou um dos tipos AES em vez de RC4 para segurança adicional. O tipo de criptografia é armazenado no atributo msDS-SupportedEncryptionTypes da conta no seu Active Directory. Se o tipo de criptografia da conta AzureADSSOAcc$ for definido como RC4_HMAC_MD5 e você quiser alterá-lo para um dos tipos de criptografia AES, primeiro sobreponha à chave de descriptografia do Kerberos da conta AzureADSSOAcc$, conforme explicado no documento de perguntas frequentes, na pergunta relevante, caso contrário, o SSO contínuo não funcionará.
• Se você tiver mais de uma floresta com relação de confiança de floresta, habilitar o SSO em uma das florestas permitirá o SSO em todas as florestas confiáveis. Se tentar habilitar o SSO em uma floresta na qual o recurso já esteja habilitado, você receberá um erro informando que o SSO já está habilitado naquela floresta.
• A política que habilita o SSO Contínuo tem um limite de caracteres de 25600. Este limite aplica-se a tudo o que está na política, incluindo os nomes de floresta em que você quer que o SSO Contínuo seja habilitado. Você pode atingir o limite de char se tiver um grande número de florestas em seu ambiente. Se suas florestas tiverem uma relação de confiança entre elas, será suficiente habilitar o SSO Contínuo somente em uma floresta. Por exemplo, se você tiver contoso.com e fabrikam.com e houver uma relação de confiança entre os dois, você poderá habilitar o SSO Contínuo somente no contoso.com e que também será aplicado em fabrikam.com. Dessa forma, é possível reduzir o número de florestas habilitadas na política e evitar atingir o limite de char da política.

Verificar o status do recurso

Verifique se o recurso SSO ainda está Habilitado em seu locatário. Você pode verificar o status acessando o painel Identidade>Gerenciamento híbrido>Microsoft Entra Connect>Connect Sync no [Centro de Administração Microsoft Entra Connect](https://portal.azure.com/).

Clique para ver todas as florestas do AD que foram habilitadas para SSO Contínuo.

Motivos de falha na entrada no Centro de Administração do Microsoft Entra (precisa de uma licença Premium)

Se o seu locatário tiver uma licença P1 ou P2 do Microsoft Entra ID associada, você também poderá analisar o relatório de atividade de entrada no Microsoft Entra ID no Centro de administração do MIcrosoft Entra.

Navegue até Identidade>Monitoramento e integridade>Entradas no [centro de administração do Microsoft Entra](https://portal.azure.com/) e, em seguida, selecione a atividade de entrada de um usuário específico. Procure o campo CÓDIGO DE ERRO DE LOGON. Faça o mapeamento do valor desse campo até um motivo da falha e uma resolução usando a tabela a seguir:

Código de erro de logon	Motivo da falha no logon	Resolução
81001	O tíquete Kerberos do usuário é muito grande.	Reduza as associações de grupo do usuário e tente novamente.
81002	Não é possível validar o tíquete Kerberos do usuário.	Veja a Lista de verificação de solução de problemas.
81003	Não é possível validar o tíquete Kerberos do usuário.	Veja a Lista de verificação de solução de problemas.
81004	Falha na tentativa de autenticação Kerberos.	Veja a Lista de verificação de solução de problemas.
81008	Não é possível validar o tíquete Kerberos do usuário.	Veja a Lista de verificação de solução de problemas.
81009	Não é possível validar o tíquete Kerberos do usuário.	Veja a Lista de verificação de solução de problemas.
81010	O SSO Contínuo falhou porque o tíquete Kerberos do usuário expirou ou é inválido.	O usuário precisa entrar em um dispositivo ingressado no domínio dentro da rede corporativa.
81011	Não foi possível localizar o objeto de usuário com base nas informações no tíquete Kerberos do usuário.	Use o Microsoft Entra Connect para sincronizar as informações do usuário no Microsoft Entra ID.
81012	O usuário que está tentando entrar no Microsoft Entra ID é diferente do usuário conectado no dispositivo.	O usuário precisa entrar em um dispositivo diferente.
81013	Não foi possível localizar o objeto de usuário com base nas informações no tíquete Kerberos do usuário.	Use o Microsoft Entra Connect para sincronizar as informações do usuário no Microsoft Entra ID.

Lista de verificação de solução de problemas

Use a lista de verificação a seguir para solucionar problemas de SSO Contínuo:

• Verifique se o recurso de SSO Contínuo está habilitado no Microsoft Entra Connect. Se você não puder habilitar o recurso (por exemplo, devido a uma porta bloqueada), verifique se você cumpriu com todos os pré-requisitos.
• Se você habilitou o Ingresso no Microsoft Entra e o SSO Contínuo em seu locatário, verifique se o problema não está com o Ingresso no Microsoft Entra. O SSO por meio do Ingresso no Microsoft Entra terá precedência sobre SSO Contínuo se o dispositivo estiver registrado no Microsoft Entra ID e ingressado no domínio.. Com o SSO por meio do Ingresso no Microsoft Entra, o usuário verá um bloco de entrada com a informação "Conectado ao Windows".
• Verifique se a URL do Microsoft Entra (https://autologon.microsoftazuread-sso.com) faz parte das configurações de zona da Intranet do usuário.
• Certifique-se de que o dispositivo corporativo tenha ingressado no domínio do Active Directory. O dispositivo não precisa ser Ingressado no Microsoft Entra para que o SSO Contínuo funcione.
• Certifique-se de que o usuário esteja conectado ao dispositivo por meio de uma conta de domínio do Active Directory.
• Verifique se a conta do usuário é de uma floresta do Active Directory na qual o SSO Contínuo foi configurado.
• Certifique-se de que o dispositivo esteja conectado à rede corporativa.
• Certifique-se de que a hora do dispositivo esteja sincronizada com a hora do Active Directory e dos Controladores de Domínio, e que tenham cinco minutos ou menos de diferença.
• Certifique-se de que a conta do computador AZUREADSSOACC está presente e habilitada em cada floresta do AD que você deseja que o SSO contínuo habilitado. Se a conta de computador tiver sido excluída ou estiver ausente, você poderá usar os cmdlets do PowerShell para recriá-las.
• Liste os tíquetes Kerberos existentes no dispositivo usando o comando klist em um prompt de comando. Certifique-se de que os tíquetes emitidos para a conta do computador AZUREADSSOACC estejam presentes. Os tíquetes Kerberos dos usuários são normalmente válidos durante 10 horas. Você pode ter configurações diferentes no Active Directory.
• Se você desabilitou e habilitou novamente o SSO Contínuo em seu locatário, os usuários não obterão a experiência de logon único até que os tíquetes de Kerberos deles, armazenados em cache, tenham se expirado.
• Limpe os tíquetes Kerberos existentes do dispositivo usando o comando klist purge e tente novamente.
• Para determinar se há problemas relacionados a JavaScript, examine os logs do console do navegador (em Ferramentas do Desenvolvedor).
• Examine os logs do controlador de domínio.

Logs do controlador de domínio

Se a auditoria de êxito estiver habilitada em seu controlador de domínio, sempre que um usuário entrar usando SSO Contínuo, uma entrada de segurança será registrada no log de eventos. Encontre esses eventos de segurança usando a consulta a seguir. (Procure o evento 4769 associado à conta de computador AzureADSSOAcc$.)

  <QueryList>
    <Query Id="0" Path="Security">
      <Select Path="Security">*[EventData[Data[@Name='ServiceName'] and (Data='AZUREADSSOACC$')]]</Select>
    </Query>
  </QueryList>

Redefinição manual do recurso

Se a solução de problemas não ajudar, você poderá redefinir manualmente o recurso em seu locatário. Execute estas etapas no servidor local em que você está executando o Microsoft Entra Connect.

Etapa 1: importar o módulo do PowerShell de SSO Contínuo

1. Primeiro, baixe e instale o PowerShell do Microsoft Azure AD.
2. Navegue até a pasta %programfiles%\Microsoft Azure Active Directory Connect.
3. Importe o módulo do PowerShell de SSO Contínuo usando este comando: Import-Module .\AzureADSSO.psd1.

Etapa 2: Obter a lista de florestas do Active Directory em que o SSO Contínuo foi habilitado

1. Execute o PowerShell como administrador. No PowerShell, chame New-AzureADSSOAuthenticationContext. Quando solicitado, insira as credenciais do Administrador de Identidade Híbrida do locatário.
2. Chame Get-AzureADSSOStatus. Esse comando fornece a lista de florestas do Active Directory (veja a lista “Domínios”) em que esse recurso foi habilitado.

Etapa 3: Desabilitar o SSO Contínuo para cada floresta do Active Directory onde você configurou o recurso

1. Chame $creds = Get-Credential. Quando solicitado, insira as credenciais de administrador de domínio da floresta do Active Directory pretendida.

   Observação

   O nome de usuário das credenciais do administrador de domínio deve ser inserido no formato de nome da conta SAM (contoso\johndoe ou contoso.com\johndoe). Usamos a parte de domínio do nome de usuário para localizar o controlador de domínio do administrador de domínio usando DNS.

   Observação

   A conta de administrador de domínio usada não deve ser um membro do grupo usuários protegidos. Nesse caso, a operação falhará.

2. Chame Disable-AzureADSSOForest -OnPremCredentials $creds. Este comando remove a conta do computador AZUREADSSOACC do controlador de domínio local dessa floresta do Active Directory específica.

   Observação

   Se por algum motivo você não puder acessar seu AD local, poderá ignorar as etapas 3.1 e 3.2 e, em vez disso, chamar Disable-AzureADSSOForest -DomainFqdn <Domain name from the output list in step 2>.

3. Repita as etapas anteriores para cada floresta do Active Directory onde você configurou o recurso.

Etapa 4: Habilitar o SSO Contínuo para cada floresta do Active Directory

1. Chame Enable-AzureADSSOForest. Quando solicitado, insira as credenciais de administrador de domínio da floresta do Active Directory pretendida.

   Observação

   O nome de usuário das credenciais do administrador de domínio deve ser inserido no formato de nome da conta SAM (contoso\johndoe ou contoso.com\johndoe). Usamos a parte de domínio do nome de usuário para localizar o controlador de domínio do administrador de domínio usando DNS.

   Observação

   A conta de administrador de domínio usada não deve ser um membro do grupo usuários protegidos. Nesse caso, a operação falhará.

2. Repita as etapas anteriores para cada floresta do Active Directory onde você configurou o recurso.

Etapa 5: Habilitar o recurso no seu locatário

Para habilitar o recurso no locatário, chame Enable-AzureADSSO -Enable $true.