Resolver Problemas com o Início de Sessão Único Totalmente Integrado no Microsoft Entra

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

Problemas conhecidos

• Em alguns casos, ativar o SSO contínuo pode levar até 30 minutos.
• Se você desabilitar e reativar o SSO contínuo em seu locatário, os usuários não obterão a experiência de logon único até que seus tíquetes Kerberos armazenados em cache, normalmente válidos por 10 horas, tenham expirado.
• Se o SSO contínuo for bem-sucedido, o usuário não terá a oportunidade de selecionar Manter-me conectado.
• Os clientes Microsoft 365 Win32 (Outlook, Word, Excel e outros) com versões 16.0.8730.xxxx e superiores são suportados usando um fluxo não interativo. Outras versões não são suportadas; Nessas versões, os usuários digitarão seus nomes de usuário, mas não senhas, para entrar. Para o OneDrive, tem de ativar a funcionalidade de configuração silenciosa do OneDrive para uma experiência de início de sessão silencioso.
• O SSO Totalmente Integrado não funciona no modo de navegação privada no Firefox.
• O SSO Totalmente Integrado não funciona no Internet Explorer se o modo Protegido Avançado estiver ativado.
• Microsoft Edge (legado) não é mais suportado
• O SSO Totalmente Integrado não funciona em browsers móveis em iOS e Android.
• Se um usuário fizer parte de muitos grupos no Ative Directory, o tíquete Kerberos do usuário provavelmente será muito grande para processar, e isso fará com que o SSO contínuo falhe. As solicitações HTTPS do Microsoft Entra podem ter cabeçalhos com tamanho máximo de 50 KB; Os tíquetes Kerberos precisam ser menores do que esse limite para acomodar outros artefatos do Microsoft Entra (normalmente, 2 a 5 KB), como cookies. Nossa recomendação é reduzir as associações de usuários ao grupo e tentar novamente.
• Se você estiver sincronizando 30 ou mais florestas do Ative Directory, não poderá habilitar o SSO contínuo por meio do Microsoft Entra Connect. Como solução alternativa, você pode 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 impede que os usuários entrem.
• O SSO contínuo suporta os 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 vs. RC4 para maior segurança. O tipo de criptografia é armazenado no atributo msDS-SupportedEncryptionTypes da conta no Ative Directory. Se o tipo de criptografia de conta AzureADSSOAcc$ estiver definido como RC4_HMAC_MD5 e você quiser alterá-lo para um dos tipos de criptografia AES, certifique-se de primeiro rolar a chave de descriptografia Kerberos da conta AzureADSSOAcc$ conforme explicado no documento de perguntas frequentes sob a pergunta relevante, caso contrário, o SSO contínuo não acontecerá.
• Se você tiver mais de uma floresta com confiança de floresta, habilitar o SSO em uma das florestas habilitará o SSO em todas as florestas confiáveis. Se você habilitar o SSO em uma floresta onde o SSO já está habilitado, receberá um erro informando que o SSO já está habilitado na floresta.
• A política que habilita o SSO contínuo tem um limite de caracteres 25600. Esse limite é para tudo o que está incluído na política, incluindo os nomes de floresta nos quais você deseja que o SSO contínuo seja habilitado. Você pode atingir o limite de char se tiver um alto número de florestas em seu ambiente. Se suas florestas tiverem confiança entre elas, basta habilitar o SSO contínuo apenas em uma floresta. Por exemplo, se você tiver contoso.com e fabrikam.com e houver confiança entre os dois, poderá habilitar o SSO contínuo somente no contoso.com e isso também se aplicará ao fabrikam.com. Dessa forma, você pode reduzir o número de florestas habilitadas na política e evitar atingir o limite de caracteres da política.

Verificar o estado da funcionalidade

Garanta que a funcionalidade do SSO Totalmente Integrado ainda está Ativada no inquilino. Você pode verificar o status acessando o painel Microsoft>Entra Connect>Connect Sync de gerenciamento>de identidade híbrida no [Centro de administração do Microsoft Entra]().https://portal.azure.com/

Clique para ver todas as florestas do AD que foram ativadas para o SSO Totalmente Integrado.

Motivos de falha de entrada no centro de administração do Microsoft Entra (precisa de uma licença Premium)

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

Navegue até Monitoramento de Identidades>& integridade>Entradas no [Centro de administração do Microsoft Entra](https://portal.azure.com/) e selecione a atividade de entrada de um usuário específico. Procure no campo CÓDIGO DE ERRO DE INÍCIO DE SESSÃO. Mapeie o valor desse campo para um motivo de falha e resolução através da seguinte tabela:

Lista de verificação de resolução de problemas

Use a seguinte lista de verificação para solucionar problemas de SSO contínuo:

• Verifique se o recurso SSO contínuo está habilitado no Microsoft Entra Connect. Se não conseguir ativar a funcionalidade (por exemplo, devido a uma porta bloqueada), confirme que tem todos os pré-requisitos implementados.
• Se você tiver habilitado a associação do Microsoft Entra e o SSO contínuo em seu locatário, verifique se o problema não está na associação do Microsoft Entra. O SSO na associação ao Microsoft Entra terá precedência sobre o SSO Totalmente Integrado se o dispositivo estiver registado no Microsoft Entra ID e associado a domínio. Com o SSO na associação ao Microsoft Entra, o utilizador vê um mosaico de início de sessão a indicar “Ligado 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.
• Confirme que o dispositivo da empresa está associado ao domínio do Active Directory. O dispositivo não precisa ser associado ao Microsoft Entra para que o Seamless SSO funcione.
• Confirme que o utilizador tem sessão iniciada no dispositivo através de uma conta de domínio do Active Directory.
• Confirme que a conta do utilizador é de uma floresta do Active Directory onde foi criado o SSO Totalmente Integrado.
• Confirme que o dispositivo está ligado à rede da empresa.
• Confirme que a hora do dispositivo está sincronizada com a hora no Active Directory e nos controladores de domínio, e que existe um desfasamento de menos de cinco minutos entre eles.
• Confirme que a conta do computador AZUREADSSOACC está presente e ativada em cada floresta do AD em que quer ativar o SSO Totalmente Integrado. Se a conta do computador tiver sido eliminada ou estiver em falta, poderá utilizar os cmdlets do PowerShell para as recriar.
• Liste as permissões Kerberos existentes no dispositivo ao utilizar o comando klist numa linha de comandos. Confirme que as permissões emitidas para a conta do computador AZUREADSSOACC estão presentes. Normalmente, as permissões Kerberos dos utilizadores são válidas durante 10 horas. Pode ter definições diferentes no Active Directory.
• Se você desabilitou e reativou o SSO contínuo em seu locatário, os usuários não terão a experiência de logon único até que seus tíquetes Kerberos armazenados em cache tenham expirado.
• Remova as permissões Kerberos existentes do dispositivo com o comando klist purge e tente novamente.
• Para determinar se existem problemas relacionados com o JavaScript, veja os registos da consola do browser (nas Ferramentas de Programação).
• Veja os registos do controlador de domínio.

Logs do controlador de domínio

Se você habilitar a auditoria bem-sucedida no controlador de domínio, sempre que um usuário entrar por meio do SSO contínuo, uma entrada de segurança será registrada no log de eventos. Você pode encontrar 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>

Reposição manual da funcionalidade

Se a resolução de problemas não ajudar, pode repor manualmente a funcionalidade no seu inquilino. Siga estas etapas no servidor local onde você está executando o Microsoft Entra Connect.

Etapa 1: Importar o módulo Seamless SSO PowerShell

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

Etapa 2: Obter a lista de florestas do Ative Directory nas quais o SSO contínuo foi habilitado

1. Execute o PowerShell como um administrador. No PowerShell, chame New-AzureADSSOAuthenticationContext. Quando solicitado, insira as credenciais de Administrador de Identidade Híbrida do seu locatário.
2. Chame Get-AzureADSSOStatus. Este comando fornece-lhe a lista de florestas do Active Directory (veja a lista "Domínios") nas quais esta funcionalidade foi ativada.

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

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

   Nota

   O nome de usuário das credenciais de administrador do domínio deve ser inserido no formato de nome de conta SAM (contoso\johndoe ou contoso.com\johndoe). Utilizamos a parte do domínio do nome de utilizador para localizar o Controlador de Domínio do Administrador de Domínio através de DNS.

   Nota

   A conta de administrador de domínio utilizada não pode pertencer ao grupo Utilizadores Protegidos. Se pertencer, a operação falhará.

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

   Nota

   Se, por qualquer motivo, não conseguir aceder ao AD no local, pode ignorar os passos 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 Ative Directory em que você configurou o recurso.

Etapa 4: Habilitar o SSO contínuo para cada floresta do Ative Directory

1. Chame Enable-AzureADSSOForest. Quando lhe for pedido, introduza as credenciais do administrador de domínio da floresta do Active Directory pretendida.

   Nota

   O nome de usuário das credenciais de administrador do domínio deve ser inserido no formato de nome de conta SAM (contoso\johndoe ou contoso.com\johndoe). Utilizamos a parte do domínio do nome de utilizador para localizar o Controlador de Domínio do Administrador de Domínio através de DNS.

   Nota

   A conta de administrador de domínio utilizada não pode pertencer ao grupo Utilizadores Protegidos. Se pertencer, a operação falhará.

2. Repita o passo anterior para cada floresta do Active Directory onde pretenda configurar a funcionalidade.

Etapa 5: habilitar o recurso em seu locatário

Para ativar a funcionalidade no seu inquilino, chame Enable-AzureADSSO -Enable $true.