Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Um PRT (Primary Refresh Token) é um artefato chave da autenticação do Microsoft Entra em versões suportadas do Windows, iOS/macOS, Android e Linux. Um PRT é um artefato seguro especialmente emitido para corretores de token primários da Microsoft para habilitar o logon único (SSO) em todos os aplicativos usados nesses dispositivos. Este artigo explica como um PRT é emitido, usado e protegido, aprimorando sua segurança e habilitando o logon único (SSO) entre aplicativos.
Este artigo pressupõe que você já entenda os diferentes estados do dispositivo disponíveis no Microsoft Entra ID e como o logon único funciona no Windows. Para obter mais informações sobre dispositivos no Microsoft Entra ID, consulte O que é o gerenciamento de dispositivos no Microsoft Entra ID?.
Terminologia e componentes principais
Os seguintes componentes do Windows desempenham um papel fundamental na solicitação e no uso de um PRT (Token de Atualização Primária):
| Vigência | Descrição |
|---|---|
| broker | Um agente de identidade é um serviço que atua como intermediário entre um provedor de identidade (IdPs) e provedores de serviços (SPs), simplificando a autenticação e a autorização. O Web Account Manager é um exemplo de um agente de identidade. |
| Provedor de autenticação na nuvem (CloudAP) | O CloudAP é o provedor de autenticação moderno para login do Windows, que verifica o registro dos usuários em um dispositivo Windows 10 ou mais recente. O CloudAP fornece uma estrutura de plug-in na qual os provedores de identidade podem se basear para habilitar a autenticação no Windows usando as credenciais desse provedor de identidade. |
| Gerente de Conta Web (WAM) | WAM é o agente de token padrão no Windows 10 ou dispositivos mais recentes. O WAM também fornece uma estrutura de plug-in na qual os provedores de identidade podem desenvolver e habilitar o SSO para seus aplicativos que dependem desse provedor de identidade. |
| Plug-in do Microsoft Entra CloudAP | Um plug-in específico do Microsoft Entra criado na estrutura do CloudAP que verifica as credenciais do usuário com o ID do Microsoft Entra durante o login do Windows. |
| Plug-in do Microsoft Entra WAM | Um plug-in específico do Microsoft Entra criado na estrutura WAM que permite o SSO para aplicativos que dependem do Microsoft Entra ID para autenticação. |
| Dsreg | Um componente específico do Microsoft Entra no Windows 10 ou mais recente, que lida com o processo de registro do dispositivo para todos os estados do dispositivo. |
| Módulo de plataforma confiável (TPM) | Um TPM é um componente de hardware incorporado num dispositivo que fornece funções de segurança baseadas em hardware para segredos de utilizador e dispositivo. Mais detalhes podem ser encontrados no artigo Visão geral da tecnologia do Trusted Platform Module. |
Para que é utilizado um PRT?
- Single Sign-On (SSO) - Depois que um usuário entra em seu dispositivo, o PRT permite que ele acesse o Microsoft 365, o Azure e outros aplicativos de nuvem sem exigir que o usuário insira novamente suas credenciais. Aplicativos como Office, Microsoft Edge e Teams usam o PRT por meio de um agente para autenticar usuários silenciosamente, melhorando a experiência do usuário, reduzindo a necessidade de vários logins e aumentando a produtividade.
- Aquisição de tokens - O PRT é usado para solicitar tokens de acesso e atualizar tokens para vários serviços (como Outlook, Teams, SharePoint, etc.) por meio do Windows Web Account Manager (WAM) ou plug-ins do Broker em outras plataformas.
- Conformidade de Acesso Condicional - Carrega declarações de dispositivo e usuário, que são avaliadas pelo ID do Microsoft Entra para aplicar políticas de Acesso Condicional (por exemplo, exigindo dispositivos compatíveis, MFA, etc.).
Quais são os tipos de PRT?
De forma geral, existem dois tipos diferentes de artefatos PRT.
- As PRTs de dispositivos registrados estão vinculadas a um dispositivo que tem uma identidade Microsoft Entra associada.
- As PRTs de dispositivos não registrados estão vinculadas a um dispositivo que não tem uma identidade Microsoft Entra, que está associada a um par de chaves criptográficas no dispositivo gerado pelo cliente.
Os clientes tentam sempre usar "PRTs de dispositivos registados" sempre que possível. Os PRTs só satisfazem as políticas de registo de dispositivos se forem emitidos para dispositivos registados. As PRTs de dispositivos não registrados são usadas em cenários em que o dispositivo não tem uma identidade do Microsoft Entra, como quando um usuário entra em um navegador em um dispositivo pessoal ou quando um usuário entra em um aplicativo que não oferece suporte ao registro de dispositivo.
Posso ver o que há em um PRT?
Um PRT é um blob opaco enviado do Microsoft Entra cujo conteúdo não é conhecido por nenhum componente do cliente. Você não pode ver o que está dentro de um PRT.
Como é emitido um PRT?
Para PRTs de dispositivos registados, o PRT é emitido para utilizadores em dispositivos registados. Para obter detalhes mais detalhados sobre o registo de dispositivos, consulte o artigo Windows Hello para Empresas e Registo de Dispositivos. Durante o registro do dispositivo, o componente dsreg gera dois conjuntos de pares de chaves criptográficas:
- Chave do dispositivo (dkpub/dkpriv)
- Chave de transporte (tkpub/tkpriv)
O PRT só pode ser emitido quando um agente de ID do Microsoft Entra está presente. O Broker é um componente distribuído com os seguintes aplicativos: Portal da Empresa do Intune no macOS e Linux, Autenticador no iOS, Autenticador, Link para Windows e Portal da Empresa no Android. No Mac, o Gerenciamento de Dispositivos Móveis (MDM) é necessário para ativar o corretor junto com o perfil de extensão SSO: Apple SSO Plugin
Se o dispositivo tiver um TPM/Secure Hardware Storage válido e funcional, as chaves privadas serão vinculadas ao Armazenamento Seguro do dispositivo em plataformas suportadas. As chaves públicas são enviadas para o Microsoft Entra ID durante o processo de registro do dispositivo para validar o estado do dispositivo durante as solicitações PRT.
O PRT é emitido durante a autenticação do usuário em um dispositivo Windows 10 ou mais recente em dois cenários:
- Microsoft Entra aderido ou Microsoft Entra aderido híbrido: um PRT é emitido durante o início de sessão do Windows quando um utilizador entra com as suas credenciais de organização. Um PRT é emitido com todas as credenciais suportadas do Windows 10 ou mais recentes, por exemplo, palavra-passe e Windows Hello para Empresas. Nesse cenário, o plugin Microsoft Entra CloudAP constitui a autoridade principal para o PRT
-
Dispositivo registado Microsoft Entra: um PRT é emitido quando um utilizador adiciona uma conta de trabalho secundária ao seu dispositivo Windows 10 ou mais recente. Os utilizadores podem adicionar uma conta ao Windows 10 ou mais recente de duas formas diferentes:
- Adicionar uma conta através da mensagem Permitir que a minha organização gerencie o meu dispositivo depois de fazer login em uma aplicação (por exemplo, Outlook)
- Adicionar uma conta a partir de Definições>Contas>Aceder ao Trabalho ou à Escola>Conectar
Em cenários de dispositivos registrados do Microsoft Entra, o plug-in WAM do Microsoft Entra é a principal autoridade para o PRT, uma vez que o login do Windows não está acontecendo com essa conta do Microsoft Entra.
Comportamento do navegador
Os navegadores obtêm acesso ao PRT de várias maneiras, dependendo do sistema operacional:
Windows - Puxará o PRT do corretor para o navegador nos seguintes navegadores:
Microsoft Edge
Firefox
Cromado
A lista de navegadores suportados está disponível aqui: Navegadores suportados
Nota
Os clientes que habilitam a federação do Entra com Provedores de Identidade que não são da Microsoft devem configurar esses Provedores de Identidade para oferecer suporte a WS-Trust protocolo para habilitar a emissão de PRT em dispositivos Windows 10 ou mais recentes. Sem WS-Trust para casos de federação, um PRT não pode ser emitido para utilizadores em dispositivos aderidos ao Microsoft Entra em modo híbrido ou em dispositivos aderidos ao Microsoft Entra.
Nota
Para endpoints de ADFS, usernamemixed são necessários. Se Smartcard/certificate for usado durante a entrada no Windows, os certificatemixed pontos de extremidade precisarão ser configurados no ADFS.
windowstransport deve ser habilitado apenas como pontos de extremidade voltados para a intranet e NÃO deve ser exposto como pontos de extremidade voltados para a extranet por meio do Proxy de Aplicativo Web.
Nota
As políticas de Acesso Condicional do Microsoft Entra não são avaliadas quando as PRTs são emitidas.
Nota
Não oferecemos suporte a provedores de credenciais que não sejam da Microsoft para emissão e renovação de PRTs do Microsoft Entra.
Como se utiliza um PRT?
Um PRT é usado por dois componentes principais no Windows:
- Plug-in Microsoft Entra CloudAP: Durante o início de sessão no Windows, o plug-in Microsoft Entra CloudAP solicita um PRT do Microsoft Entra ID usando as credenciais fornecidas pelo utilizador. Ele também armazena em cache o PRT para habilitar o login em cache quando o usuário não tem acesso a uma conexão com a Internet.
-
Plug-in Microsoft Entra WAM: Quando os usuários tentam acessar aplicativos, o plug-in Microsoft Entra WAM usa o PRT para habilitar o SSO no Windows 10 ou mais recente. O plugin WAM do Microsoft Entra utiliza o PRT para solicitar tokens de renovação e de acesso para aplicações que dependem do WAM para pedidos de token. Ele também permite o SSO em navegadores, injetando o PRT em solicitações do navegador. O SSO do navegador no Windows 10 ou mais recente é suportado no Microsoft Edge (nativamente), no Chrome (através da extensão Contas do Windows 10) e no Mozilla Firefox (versão 91+), através da configuração de Windows SSO no Firefox.
Nota
Nos casos em que um usuário tem duas contas do mesmo locatário do Microsoft Entra conectado a um aplicativo de navegador, a autenticação de dispositivo fornecida pelo PRT da conta principal também é aplicada automaticamente à segunda conta. Como resultado, a segunda conta também satisfaz qualquer política de Acesso Condicional baseada em dispositivo no locatário.
Qual é o tempo de vida de um PRT?
Uma vez emitido, um PRT é válido por 90 dias e é continuamente renovado, desde que o usuário use ativamente o dispositivo. As organizações podem exigir que os utilizadores se autentiquem novamente para aceder a recursos usando o controlo de sessão de frequência de autenticação
Como é renovada uma PRT?
Plataforma Windows
Um PRT é renovado de duas maneiras diferentes:
- Plug-in do Microsoft Entra CloudAP a cada 4 horas: O plug-in CloudAP renova o PRT a cada 4 horas durante o início de sessão do Windows. Se o usuário não tiver conexão com a Internet durante esse tempo, o plug-in CloudAP renovará o PRT depois que o dispositivo estiver conectado à internet e um novo login do Windows for feito.
-
Plug-in WAM do Microsoft Entra durante solicitações de token de aplicativo: o plug-in WAM permite o SSO em dispositivos Windows 10 ou mais recentes, permitindo requisições silenciosas de token para aplicativos. O plug-in WAM pode renovar o PRT durante essas solicitações de token de duas maneiras diferentes:
- Uma aplicação solicita silenciosamente um token de acesso a WAM, mas não há um token de renovação disponível para essa aplicação. Nesse caso, o WAM usa o PRT para solicitar um token para o aplicativo e recebe de volta um novo PRT na resposta.
- Um aplicativo solicita WAM para um token de acesso, mas o PRT é inválido ou o Microsoft Entra ID requer autorização extra (por exemplo, autenticação multifator do Microsoft Entra). Nesse cenário, o WAM inicia uma entrada interativa exigindo que o usuário se autentique novamente ou forneça verificação extra e um novo PRT é emitido na autenticação bem-sucedida.
Em um ambiente ADFS, a linha de visão direta para o controlador de domínio não é necessária para renovar o PRT. A renovação PRT requer apenas os endpoints /adfs/services/trust/2005/usernamemixed e /adfs/services/trust/13/usernamemixed habilitados no proxy usando o protocolo WS-Trust.
Os endpoints de transporte do Windows são necessários para autenticação de senha somente quando uma senha é alterada, não para renovação de PRT.
Considerações principais
- Nos dispositivos Microsoft Entra unidos e Microsoft Entra híbridos, o plug-in CloudAP é a principal autoridade para um PRT. Se um PRT for renovado durante uma solicitação de token baseada em WAM, o PRT será enviado de volta para o plug-in CloudAP, que verifica a validade do PRT com o Microsoft Entra ID antes de aceitá-lo.
Nota
As políticas de Acesso Condicional do Microsoft Entra não são avaliadas quando as PRTs são renovadas.
Como é protegida a PRT?
Um PRT é protegido associando-o ao dispositivo no qual o utilizador fez login, onde usará a vinculação de hardware quando disponível e suportada.
O Microsoft Entra ID e o Windows 10 ou mais recente habilitam a proteção PRT através dos seguintes métodos:
- Durante o primeiro login: Durante o primeiro login, um PRT é emitido assinando solicitações usando a chave do dispositivo gerada criptograficamente durante o registro do dispositivo. Em um dispositivo com um TPM válido e funcional, a chave do dispositivo é protegida pelo TPM impedindo qualquer acesso mal-intencionado. Um PRT não é emitido se a assinatura da chave de dispositivo correspondente não puder ser validada.
- Durante solicitações de token e renovação: Quando um PRT é emitido, o Microsoft Entra ID também emite uma chave de sessão criptografada para o dispositivo. É encriptado com a chave de transporte público (tkpub) gerada e enviada para o Microsoft Entra ID como parte do registo do dispositivo. Esta chave de sessão só pode ser desencriptada pela chave de transporte privada (tkpriv) protegida pelo TPM. A chave de sessão é a chave de Prova de Posse (POP) para quaisquer solicitações enviadas para o Microsoft Entra ID. A chave de sessão também é protegida pelo TPM e nenhum outro componente do sistema operacional pode acessá-la. As solicitações de token ou solicitações de renovação PRT são assinadas com segurança por essa chave de sessão através do TPM e, portanto, não podem ser adulteradas. O Microsoft Entra invalida quaisquer solicitações do dispositivo que não estejam assinadas pela chave de sessão correspondente.
Ao proteger estas chaves com o TPM, aumentamos a segurança do PRT contra atores mal-intencionados que tentam roubar as chaves ou reproduzir o PRT. Assim, o uso de um TPM aumenta significativamente a segurança de dispositivos associados ao Microsoft Entra, associados híbridos ao Microsoft Entra e registados no Microsoft Entra contra o roubo de credenciais. Para desempenho e confiabilidade, o TPM 2.0 é a versão recomendada para todos os cenários de registro de dispositivo Microsoft Entra no Windows 10 ou mais recente. Após a atualização do Windows 10, 1903, o Microsoft Entra ID não usa o TPM 1.2 para nenhuma das chaves acima devido a problemas de confiabilidade.
Como os tokens de aplicativo são protegidos?
Para obter uma visão geral de como os tokens são protegidos em geral, consulte Protegendo tokens no Microsoft Entra ID
- Quando um aplicativo solicita token por meio do WAM, o Microsoft Entra ID emite um token de acesso e, em alguns tipos de solicitações, um token de atualização. No entanto, o WAM retorna apenas o token de acesso ao aplicativo e protege o token de atualização:
- Se for um token de atualização para um usuário SSO, esse token de atualização será vinculado ao dispositivo, com uma chave de sessão (a mesma que PRT) ou a chave do dispositivo.
- Se for um token de atualização para um usuário que não seja SSO, esse token de atualização não estará vinculado ao dispositivo.
- Todos os tokens de atualização são criptografados pelo DPAPI.
Como são protegidos os cookies do navegador
Quando é que um PRT recebe um pedido de AMF?
Um PRT pode obter uma declaração de autenticação multifator em cenários específicos. Quando um PRT baseado em MFA é usado para solicitar tokens para aplicativos, a declaração de MFA é transferida para esses tokens de aplicativo. Essa funcionalidade fornece uma experiência perfeita aos usuários, evitando o desafio de MFA para cada aplicativo que o exige. Um PRT pode obter uma reivindicação de MFA das seguintes maneiras:
-
Entrar com o Windows Hello for Business: o Windows Hello for Business substitui senhas e usa chaves criptográficas para fornecer autenticação forte de dois fatores. O Windows Hello for Business é específico para um utilizador em um dispositivo e, ele próprio, requer MFA para provisionamento. Quando um usuário faz login com o Windows Hello for Business, o PRT do usuário recebe uma declaração de MFA. Este cenário também se aplica aos utilizadores que iniciam sessão com cartões inteligentes se a autenticação de cartão inteligente produzir uma declaração MFA do ADFS.
- Como o Windows Hello for Business é considerado autenticação multifator, a reivindicação de MFA é atualizada quando o próprio PRT é atualizado, assim, a duração do MFA será continuamente prolongada quando os utilizadores se autenticarem com o Windows Hello for Business.
-
MFA durante o login interativo do WAM: durante uma solicitação de token por meio do WAM, se um usuário for obrigado a fazer MFA para acessar o aplicativo, o PRT renovado durante essa interação será impresso com uma declaração de MFA.
- Nesse caso, a declaração de MFA não é atualizada continuamente, portanto, a duração da MFA é baseada no tempo de vida definido no diretório.
- Quando um PRT e RT existentes anteriormente são usados para acessar um aplicativo, o PRT e o RT são considerados como a primeira prova de autenticação. É necessário um novo RT com uma segunda prova e uma reivindicação de Autenticação Multi-Fator impressa. Este processo também emite um novo PRT e RT.
- O Windows 10 ou mais recente mantém uma lista particionada de PRTs para cada credencial. Portanto, há um PRT para cada um dos seguintes: Windows Hello for Business, senha ou cartão inteligente. Esse particionamento garante que as declarações de MFA sejam isoladas com base na credencial usada e não misturadas durante solicitações de token.
Nota
Ao usar uma senha para entrar no Windows 10 ou num dispositivo ingressado no Microsoft Entra ou híbrido Microsoft Entra, pode ser necessário realizar a Autenticação Multifator (MFA) durante o login interativo do Gestor de Contas Web (WAM) se a chave de sessão associada ao Token de Atualização Primária (PRT) for renovada, dependendo de o utilizador ter passado pelo processo de autenticação de dois fatores (2FA) nessa sessão.
Como um PRT é invalidado?
Um PRT é invalidado nos seguintes cenários:
- Usuário inválido: Se um usuário for excluído ou desabilitado no Microsoft Entra ID, seu PRT será invalidado e não poderá ser usado para obter tokens para aplicativos. Se um usuário excluído ou desativado já tiver entrado em um dispositivo antes, o login armazenado em cache fará login nele, até que o CloudAP esteja ciente de seu estado inválido. Quando o CloudAP determina que o usuário é inválido, ele bloqueia logons subsequentes. Um usuário inválido é automaticamente impedido de entrar em novos dispositivos que não têm suas credenciais armazenadas em cache.
- Dispositivo inválido: Se um dispositivo for excluído ou desativado no Microsoft Entra ID, o PRT obtido nesse dispositivo será invalidado e não poderá ser usado para obter tokens para outros aplicativos. Se um utilizador já tiver sessão iniciada num dispositivo inválido, pode continuar a fazê-lo. Mas todos os tokens no dispositivo são invalidados e o usuário não tem SSO para nenhum recurso desse dispositivo.
-
Alteração de senha: Se um usuário obteve o PRT com sua senha, o PRT é invalidado pelo ID do Microsoft Entra quando o usuário altera sua senha. A alteração de senha resulta na obtenção de um novo PRT pelo usuário. Esta invalidação pode acontecer de duas formas diferentes:
- Se o usuário entrar no Windows com sua nova senha, o CloudAP descartará o PRT antigo e solicitará que o Microsoft Entra ID emita um novo PRT com sua nova senha. Se o usuário não tiver uma conexão com a Internet, a nova senha não poderá ser validada, o Windows pode exigir que o usuário insira sua senha antiga.
- Se um utilizador tiver iniciado sessão com a sua palavra-passe antiga ou alterado a sua palavra-passe depois de iniciar sessão no Windows, o PRT antigo é utilizado para quaisquer pedidos de token baseados em WAM. Nesse cenário, o usuário é solicitado a autenticar novamente durante a solicitação de token WAM e um novo PRT é emitido.
- Problemas de TPM: Às vezes, o TPM de um dispositivo pode vacilar ou falhar, levando à inacessibilidade das chaves protegidas pelo TPM. Neste caso, o dispositivo é incapaz de obter um PRT ou solicitar tokens usando um PRT existente, pois não pode provar a posse das chaves criptográficas. Como resultado, qualquer PRT existente é invalidado pelo Microsoft Entra ID. Quando o Windows 10 deteta uma falha, ele inicia um fluxo de recuperação para registrar novamente o dispositivo com novas chaves criptográficas. Com a junção híbrida do Microsoft Entra, assim como o registro inicial, a recuperação acontece silenciosamente sem a entrada do usuário. Para dispositivos associados ao Microsoft Entra ou registrados no Microsoft Entra, a recuperação precisa ser realizada por um utilizador que tenha privilégios de administrador no dispositivo. Nesse cenário, o fluxo de recuperação é iniciado por um prompt do Windows que orienta o usuário a recuperar com êxito o dispositivo.
Fluxos detalhados
Os diagramas a seguir ilustram os detalhes subjacentes na emissão, renovação e uso de um PRT para solicitar um token de acesso para um aplicativo. Além disso, essas etapas também descrevem como os mecanismos de segurança mencionados anteriormente são aplicados durante essas interações.
Abaixo estão os fluxos detalhados específicos para o sistema operacional Windows.
Emissão de PRT durante o primeiro início de sessão (Windows)
Nota
Nos dispositivos associados do Microsoft Entra, a emissão do Microsoft Entra PRT (etapas A-F) acontece de forma síncrona antes que o usuário possa entrar no Windows. Nos dispositivos associados híbridos do Microsoft Entra, o Ative Directory local é a autoridade principal. Assim, o utilizador consegue iniciar sessão no Windows juntado ao Microsoft Entra híbrido após adquirir um TGT para a autenticação, enquanto a emissão do PRT ocorre de forma assíncrona. Este cenário não se aplica nas sessões de dispositivos registados do Microsoft Entra, uma vez que iniciar sessão não utiliza as credenciais do Microsoft Entra.
Nota
Em um ambiente Windows híbrido associado ao Microsoft Entra, a emissão do PRT ocorre de forma assíncrona. A emissão do PRT pode falhar devido a problemas com o provedor de federação. Essa falha pode resultar em problemas de logon quando os usuários tentam acessar recursos de nuvem. É importante solucionar esse cenário com o provedor de federação.
| Passo | Descrição |
|---|---|
| Um | O usuário insere sua senha na interface do usuário de login. LogonUI passa as credenciais em um buffer de autenticação para LSA, que por sua vez passa internamente para o CloudAP. O CloudAP encaminha essa solicitação para o plug-in do CloudAP. |
| B | O plug-in do CloudAP inicia uma solicitação de descoberta de território para identificar o provedor de identidade do usuário. Se o locatário do usuário tiver uma configuração de provedor de federação, a ID do Microsoft Entra retornará o ponto de extremidade MEX (Metadata Exchange) do provedor de federação. Caso contrário, a ID do Microsoft Entra retorna que o usuário é gerenciado, indicando que o usuário pode se autenticar com a ID do Microsoft Entra. |
| C | Se o usuário for gerenciado, o CloudAP obterá o nonce do ID do Microsoft Entra. Se o usuário for federado, o plug-in do CloudAP solicitará um token SAML (Security Assertion Markup Language) do provedor de federação com as credenciais do usuário. O Nonce é solicitado antes que o token SAML seja enviado para o Microsoft Entra ID. |
| D | O plug-in CloudAP constrói a solicitação de autenticação com as credenciais do utilizador, nonce e um escopo de intermediário, assina a solicitação com a chave do Dispositivo (dkpriv) e envia-a para Microsoft Entra ID. Em um ambiente federado, o plug-in do CloudAP usa o token SAML retornado pelo provedor de federação em vez das credenciais do usuário. |
| E | O Microsoft Entra ID valida as credenciais do usuário, o nonce e a assinatura do dispositivo, verifica se o dispositivo é válido no locatário e emite o PRT criptografado. Junto com o PRT, o Microsoft Entra ID também emite uma chave simétrica, chamada de chave de sessão criptografada pelo Microsoft Entra ID usando a chave de transporte (tkpub). Além disso, a chave Session também está incorporada no PRT. Esta chave de sessão funciona como a chave de prova de posse (PoP) para próximas solicitações com o PRT. |
| F | O plug-in CloudAP passa o PRT criptografado e a chave de sessão para o CloudAP. O CloudAP solicita que o TPM descriptografe a chave de sessão usando a chave de transporte (tkpriv) e criptografe-a novamente usando a própria chave do TPM. O CloudAP armazena a chave de sessão criptografada em seu cache junto com o PRT. |
Renovação do PRT em inícios de sessão subsequentes (Windows)
| Passo | Descrição |
|---|---|
| Um | O usuário insere sua senha na interface do usuário de login. LogonUI passa as credenciais em um buffer de autenticação para LSA, que por sua vez passa internamente para o CloudAP. O CloudAP encaminha essa solicitação para o plug-in do CloudAP. |
| B | Se o utilizador já tiver iniciado sessão anteriormente, o Windows iniciará a sessão em cache e validará as credenciais para efetuar o login do utilizador. A cada 4 horas, o plug-in CloudAP inicia a renovação do PRT de forma assíncrona. |
| C | O plug-in do CloudAP inicia uma solicitação de descoberta de território para identificar o provedor de identidade do usuário. Se o locatário do usuário tiver uma configuração de provedor de federação, o Microsoft Entra ID retornará o ponto de extremidade de Metadata Exchange (MEX) do provedor de federação. Caso contrário, a ID do Microsoft Entra retorna que o usuário é gerenciado, indicando que o usuário pode se autenticar com a ID do Microsoft Entra. |
| D | Se o usuário for federado, o plug-in do CloudAP solicitará um token SAML do provedor de federação com as credenciais do usuário. O Nonce é solicitado antes que o token SAML seja enviado para o Microsoft Entra ID. Se o usuário for gerenciado, o CloudAP obterá diretamente o nonce do Microsoft Entra ID. |
| E | O plug-in CloudAP constrói a solicitação de autenticação com as credenciais do usuário, nonce e o PRT existente, assina a solicitação com a chave de sessão e a envia para o Microsoft Entra ID. Em um ambiente federado, o plug-in do CloudAP usa o token SAML retornado pelo provedor de federação em vez das credenciais do usuário. |
| F | O Microsoft Entra ID valida a assinatura da chave de sessão comparando-a com a chave de sessão embutida no PRT, valida o nonce, verifica se o dispositivo é válido no inquilino e emite um novo PRT. Como visto anteriormente, o PRT é novamente acompanhado com a chave de sessão criptografada pela chave de transporte (tkpub). |
| G | O plug-in CloudAP passa o PRT criptografado e a chave de sessão para o CloudAP. O CloudAP solicita que o TPM descriptografe a chave de sessão usando a chave de transporte (tkpriv) e criptografe-a novamente usando a própria chave do TPM. O CloudAP armazena a chave de sessão criptografada em seu cache junto com o PRT. |
Nota
Um PRT pode ser renovado externamente sem necessidade de conexão VPN, desde que os pontos de extremidade usernamemixed estejam habilitados externamente.
Uso de PRT durante solicitações de token de aplicativo (Windows)
| Passo | Descrição |
|---|---|
| Um | Um aplicativo, como o Microsoft Outlook, inicia uma solicitação de token para o WAM. O WAM, por sua vez, pede ao plugin WAM do Microsoft Entra para processar o pedido de token. |
| B | Se um token de atualização para o aplicativo já estiver disponível, o plug-in Microsoft Entra WAM o usará para solicitar um token de acesso. Para fornecer prova de vinculação de dispositivo, o plug-in WAM assina a solicitação com a chave de sessão. O Microsoft Entra ID valida a chave de sessão e emite um token de acesso e um novo token de atualização para o aplicativo, criptografado pela chave de sessão. O plug-in WAM solicita o plug-in CloudAP para descriptografar os tokens, que, por sua vez, solicita que o TPM descriptografe usando a chave de sessão, resultando no plug-in WAM recebendo ambos os tokens. Em seguida, o plug-in WAM fornece apenas o token de acesso ao aplicativo, enquanto criptografa novamente o token de atualização com DPAPI e o armazena em seu próprio cache |
| C | Se um token de atualização para o aplicativo não estiver disponível, o plug-in WAM do Microsoft Entra usará o PRT para solicitar um token de acesso. Para fornecer prova de posse, o plugin WAM assina a solicitação contendo o PRT com a chave de sessão. O Microsoft Entra ID valida a assinatura da chave de sessão comparando-a com a chave de sessão incorporada no PRT, verifica se o dispositivo é válido e emite um token de acesso e um token de atualização para o aplicativo. Além disso, o Microsoft Entra ID pode emitir um novo PRT (baseado no ciclo de atualização), todos eles criptografados pela chave de sessão. |
| D | O plug-in WAM solicita o plug-in CloudAP para descriptografar os tokens, que, por sua vez, solicita que o TPM descriptografe usando a chave de sessão, resultando no plug-in WAM recebendo ambos os tokens. Em seguida, o plug-in WAM fornece apenas o token de acesso ao aplicativo, enquanto criptografa novamente o token de atualização com DPAPI e o armazena em seu próprio cache. O plug-in WAM usa o token de atualização de agora em diante para este aplicativo. O plug-in WAM também devolve o novo PRT ao plug-in CloudAP, que valida o PRT com o Microsoft Entra ID antes de o atualizar na sua própria cache. O plugin CloudAP usa o novo PRT no futuro. |
| E | O WAM fornece o token de acesso recém-emitido para o aplicativo de chamada. |
SSO do navegador usando PRT (Windows)
| Passo | Descrição |
|---|---|
| Um | O utilizador inicia sessão no Windows com as suas credenciais para obter um PRT. Uma vez que o usuário abre o navegador, o navegador (ou extensão) carrega as URLs do registro. |
| B | Quando um utilizador abre uma URL de início de sessão do Microsoft Entra, o navegador ou a extensão valida a URL com as obtidas do registo. Se corresponderem, o navegador invoca o host do cliente nativo para obter um token. |
| C | O host do cliente nativo valida se as URLs pertencem aos fornecedores de identidade da Microsoft (conta da Microsoft ou Microsoft Entra ID), extrai um nonce enviado pela URL e faz uma chamada ao plug-in CloudAP para obter um cookie PRT. |
| D | O plug-in CloudAP cria o cookie PRT, assina-o com a chave de sessão vinculada ao TPM e envia-o de volta para o host do cliente nativo. |
| E | O host cliente nativo retorna esse cookie PRT para o navegador, que o inclui como parte do cabeçalho de solicitação chamado x-ms-RefreshTokenCredential e solicita tokens do Microsoft Entra ID. |
| F | O Microsoft Entra ID valida a assinatura da chave de sessão no cookie PRT, valida o nonce, verifica se o dispositivo é válido no locatário e emite um token de ID para a página da Web e um cookie de sessão criptografado para o navegador. |
Nota
O fluxo de SSO do navegador descrito nas etapas anteriores não se aplica a sessões em modos privados, como InPrivate no Microsoft Edge, anônimo no Google Chrome (ao usar a extensão Contas da Microsoft) ou no modo privado no Mozilla Firefox v91+
Próximos passos
Para obter mais informações sobre como solucionar problemas relacionados ao PRT, consulte o artigo Solução de problemas do Microsoft Entra em dispositivos híbridos associados ao Windows 10 ou versão mais recente e ao Windows Server 2016.