Microsoft Entra logon único contínuo: aprofundamento técnico

Este artigo fornece detalhes técnicos sobre como o recurso de logon único contínuo (SSO contínuo) do Microsoft Entra funciona.

Como funciona o SSO Totalmente Integrado?

Esta secção divide-se em três partes:

1. A configuração do recurso SSO contínuo.
2. Como funciona uma transação de login de usuário único em um navegador da Web com o Seamless SSO.
3. Como uma transação de login de usuário único em um cliente nativo funciona com o Seamless SSO.

Como funciona a configuração?

O SSO contínuo é ativado usando o Microsoft Entra Connect, conforme mostrado aqui. Ao habilitar o recurso, as seguintes etapas ocorrem:

• Uma conta de computador (AZUREADSSOACC) é criada no Ative Directory (AD) local em cada floresta do AD sincronizada com a ID do Microsoft Entra (usando o Microsoft Entra Connect).
• Além disso, vários SPNs (nomes principais de serviço) Kerberos são criados para uso durante o processo de entrada do Microsoft Entra.
• A chave de desencriptação Kerberos da conta de computador é partilhada de forma segura com o Microsoft Entra ID. Se houver várias florestas AD, cada conta de computador terá sua própria chave de descriptografia Kerberos exclusiva.

Importante

A conta de computador AZUREADSSOACC tem de ser fortemente protegida, por motivos de segurança. Só os Administradores de Domínio devem poder gerir a conta de computador. Verifique se a delegação Kerberos na conta de computador está desabilitada e se nenhuma outra conta no Ative Directory tem permissões de delegação na conta de AZUREADSSOACC computador. Armazene a conta de computador numa Unidade Organizacional (UO) onde esteja protegida contra eliminações acidentais e onde apenas os Administradores de Domínio tenham acesso. A chave de desencriptação Kerberos na conta do computador também deve ser tratada como sensível. É altamente recomendável rolar a chave de descriptografia Kerberos da conta do computador pelo menos a AZUREADSSOACC cada 30 dias.

Importante

O SSO contínuo suporta os AES256_HMAC_SHA1tipos de criptografia e AES128_HMAC_SHA1RC4_HMAC_MD5 e e para Kerberos. Recomenda-se que o tipo de encriptação para a AzureADSSOAcc$ conta seja definido como AES256_HMAC_SHA1, ou um dos tipos AES vs. RC4 para maior segurança. O tipo de criptografia é armazenado no msDS-SupportedEncryptionTypes atributo da conta no Ative Directory. Se o AzureADSSOAcc$ tipo de criptografia de conta 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 AzureADSSOAcc$ conta, conforme explicado no documento de perguntas frequentes sob a pergunta relevante, caso contrário, o SSO contínuo não acontecerá.

Quando a configuração estiver concluída, o SSO contínuo funcionará da mesma forma que qualquer outro início de sessão que utilize a autenticação integrada do Windows (IWA).

Como funciona o início de sessão num browser com o SSO Totalmente Integrado?

O fluxo de entrada em um navegador da Web é o seguinte:

1. O usuário tenta acessar um aplicativo Web (por exemplo, o Outlook Web App - https://outlook.office365.com/owa/) a partir de um dispositivo corporativo associado a um domínio dentro de sua rede corporativa.

2. Se o usuário ainda não estiver conectado, ele será redirecionado para a página de entrada do Microsoft Entra.

3. O usuário digita seu nome de usuário na página de entrada do Microsoft Entra.

   Nota

   Para determinados aplicativos, as etapas 2 e 3 são ignoradas.

4. Usando JavaScript em segundo plano, o Microsoft Entra ID desafia o navegador, por meio de uma resposta 401 não autorizada, a fornecer um tíquete Kerberos.

5. O navegador, por sua vez, solicita um ticket do Ative Directory para a conta do computador (que representa o AZUREADSSOACC Microsoft Entra ID).

6. O Ative Directory localiza a conta do computador e retorna um tíquete Kerberos para o navegador criptografado com o segredo da conta do computador.

7. O navegador encaminha o tíquete Kerberos adquirido do Ative Directory para o Microsoft Entra ID.

8. O Microsoft Entra ID descriptografa o tíquete Kerberos, que inclui a identidade do usuário conectado ao dispositivo corporativo, usando a chave compartilhada anteriormente.

9. Após a avaliação, o Microsoft Entra ID retorna um token de volta ao aplicativo ou solicita que o usuário execute provas adicionais, como autenticação multifator.

10. Se o login do usuário for bem-sucedido, o usuário poderá acessar o aplicativo.

O diagrama a seguir ilustra todos os componentes e as etapas envolvidas.

O SSO transparente é oportunista. Isto significa que, se falhar, a experiência de início de sessão volta ao seu comportamento normal. Nesse caso, o usuário precisa digitar sua senha para entrar.

Como funciona o início de sessão num cliente nativo com o SSO Totalmente Integrado?

O fluxo de entrada em um cliente nativo é o seguinte:

1. O usuário tenta acessar um aplicativo nativo (por exemplo, o cliente Outlook) de um dispositivo corporativo associado ao domínio dentro de sua rede corporativa.
2. Se o usuário ainda não estiver conectado, o aplicativo nativo recuperará o nome de usuário do usuário da sessão do Windows do dispositivo.
3. O aplicativo envia o nome de usuário para o Microsoft Entra ID e recupera o ponto de extremidade WS-Trust MEX do seu locatário. Este ponto de extremidade WS-Trust é usado exclusivamente pelo recurso Seamless SSO e não constitui uma implementação geral do protocolo WS-Trust no Microsoft Entra ID.
4. Em seguida, o aplicativo consulta o ponto de extremidade WS-Trust MEX para ver se o ponto de extremidade de autenticação integrada está disponível. O ponto de extremidade de autenticação integrado é usado exclusivamente pelo recurso SSO contínuo.
5. Se a etapa 4 for bem-sucedida, um desafio Kerberos será emitido.
6. Se o aplicativo conseguir recuperar o tíquete Kerberos, ele o encaminhará para o ponto de extremidade de autenticação integrada do Microsoft Entra.
7. O Microsoft Entra ID descriptografa o tíquete Kerberos e o valida.
8. O Microsoft Entra ID inicia sessão no utilizador e emite um token SAML para a aplicação.
9. Em seguida, o aplicativo envia o token SAML para o ponto de extremidade do token OAuth2 do Microsoft Entra ID.
10. O Microsoft Entra ID valida o token SAML e emite um token de acesso, um token de atualização para o recurso especificado e um token de ID para o aplicativo.
11. O usuário tem acesso ao recurso do aplicativo.

O diagrama a seguir ilustra todos os componentes e as etapas envolvidas.

Próximos passos

• Início rápido - Comece a executar o SSO contínuo do Microsoft Entra.
• Perguntas Frequentes - Respostas a perguntas frequentes.
• Solução de problemas - Saiba como resolver problemas comuns com o recurso.
• UserVoice - Para preencher novas solicitações de recursos.