Noções básicas sobre o PRT (Token de Atualização Primária)

Se o dispositivo tiver um TPM/Armazenamento de Hardware Seguro válido e funcional, as chaves privadas serão associadas ao Armazenamento Seguro do dispositivo em plataformas com suporte. As chaves públicas são enviadas para a ID do Microsoft Entra durante o processo de registro do dispositivo para validar o estado do dispositivo durante solicitações PRT.

Há dois cenários em que o PRT é emitido durante a autenticação do usuário em um dispositivo Windows 10 ou mais recente:

• Ingresso no Microsoft Entra ou ingressado no Microsoft Entra híbrido: um PRT é emitido durante a entrada do Windows quando um usuário entra com suas credenciais de organização. Um PRT é emitido com todas as credenciais compatíveis do Windows 10 e posteriores, como senha e Windows Hello for Business. Nesse cenário, o plug-in do Microsoft Entra CloudAP é a principal autoridade para o PRT
• Dispositivo registrado do Microsoft Entra: um PRT é emitido quando um usuário adiciona uma conta de trabalho secundária ao dispositivo Windows 10 ou mais recente. Os usuários podem adicionar uma conta ao Windows 10 ou mais recente de duas maneiras diferentes:
  • Adicionando uma conta usando o prompt Permitir que minha organização gerencie meu dispositivo depois de entrar em um aplicativo (por exemplo, Outlook)
  • Adicionando uma conta pelo caminho Configurações>Contas>Acesso ao Trabalho ou Escola>Conectar

Nos cenários de dispositivo registrados do Microsoft Entra, o plug-in do Microsoft Entra WAM é a principal autoridade para o PRT, pois a entrada do Windows não está acontecendo com essa conta do Microsoft Entra.

macOS com Plataforma SSO

O PSSO (Logon Único) da Plataforma macOS é um novo recurso do plug-in enterprise SSO da Microsoft, credenciais de plataforma para macOS que permite que os usuários entrem em dispositivos Mac usando suas credenciais de ID do Microsoft Entra.

O PRT (Token de Atualização Primária) do PSSO é emitido exclusivamente para dispositivos macOS ingressados na Entra que concluíram com êxito o registro de SSO da Plataforma. Durante esse processo de registro, o macOS gera pares de chaves criptográficas com suporte de enclave seguro: um para assinatura de dispositivo e outro para criptografia de dispositivo. As referências de chave pública são compartilhadas com a extensão de SSO.

A extensão de SSO usa essas chaves para concluir o registro do dispositivo com o Serviço de Registro de Dispositivo da ID do Microsoft Entra. Em seguida, configura a API loginConfiguration da Apple com os parâmetros necessários para aquisição de PRT.

macOS sem SSO da Plataforma

O macOS dá suporte a PRTs não registrados para o Microsoft Edge e a PRTs registrados quando o dispositivo está associado ao ambiente de trabalho e o agente está presente.

Depois que o registro for concluído com êxito, o macOS iniciará uma solicitação de entrada assinada com a chave de Assinatura do Dispositivo. A ID do Microsoft Entra valida a solicitação, a chave de assinatura do dispositivo e os parâmetros associados e emite a resposta PRT.

O iOS, macOS e Android dão suporte a PRTs não registrados para Microsoft Edge e PRTs registrados quando o agente está presente.

O Linux dá suporte a PRTs não registrados para o Microsoft Edge e PRTs registrados quando o agente está presente.

Windows – Efetuará pull do PRT do agente para o navegador nos seguintes navegadores:

• Microsoft Edge

• Firefox

• Chrome

Android – O Microsoft Edge fará o pull do PRT do intermediário para o navegador

No iOS e no macOS, os navegadores também podem obter o PRT quando o perfil de extensão SSO está instalado, habilitando:

• Suporte a Chrome e Firefox no macOS
• Suporte do Safari no iOS e no macOS
• Microsoft Edge no iOS e macOS

Linux – O Microsoft Edge puxará o PRT do intermediário para o navegador.

Um PRT é usado por dois componentes fundamentais no Windows:

• Plug-in CloudAP do Microsoft Entra: ao entrar no Windows, o plug-in CloudAP do Microsoft Entra solicita um PRT do Microsoft Entra ID usando as credenciais fornecidas pelo usuário. Ele também armazena o PRT em cache para permitir o login em cache quando o usuário não tem acesso a uma conexão com a internet.
• Plug-in WAM do Microsoft Entra: quando usuários tentam acessar aplicativos, o plug-in WAM do Microsoft Entra usa o PRT para habilitar o SSO no Windows 10 ou posteriores. O plug-in WAM do Microsoft Entra usa o PRT para solicitar tokens de atualização e de acesso para aplicativos que dependem do WAM para solicitações de token. Ele também injeta o PRT nas solicitações do navegador para habilitar o SSO em navegadores. O SSO do navegador no Windows 10 ou mais recente tem suporte no Microsoft Edge (nativamente), chrome (por meio da extensão Contas do Windows 10 ) e Mozilla Firefox v91+ ( configuração do SSO do Firefox Windows).

  Observação

  Em instâncias 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 primária 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.

Um PRT é usado pela extensão de SSO para fornecer SSO a aplicativos e sites. Um PRT é usado para solicitar tokens de atualização e acesso para aplicativos que dependem da extensão de SSO para solicitações de token. Ele também injeta o PRT nas solicitações do navegador para habilitar o SSO em navegadores.

Os navegadores que dão suporte ao SSO do Navegador são Safari, Firefox, Chrome e Microsoft Edge.

Para iOS, somente o Microsoft Edge e o Safari são compatíveis com o SSO do Navegador.

Para Android, somente o Microsoft Edge tem suporte para o SSO do Navegador.

Os únicos aplicativos nativos integrados hoje são o Intune e o Microsoft Edge Browser. Para o suporte ao navegador, somente o Microsoft Edge Browser é protegido para tokens associados ao dispositivo e imposição de acesso condicional.

Plataforma Windows

Um PRT é renovado de duas maneiras diferentes:

• Plug-in CloudAP do Microsoft Entra a cada 4 horas: o plug-in CloudAP renova o PRT a cada 4 horas durante a entrada no Windows. Se o usuário não tiver conexão com a internet durante esse período, o plug-in CloudAP renovará o PRT após o dispositivo se conectar à internet e uma nova entrada no Windows for concluída.
• Plug-in WAM do Microsoft Entra durante solicitações de token do aplicativo: o plugin WAM habilita o SSO em dispositivos Windows 10 ou posteriores habilitando solicitações de token silenciosas para aplicativos. O plug-in WAM pode renovar o PRT durante essas solicitações de token de duas maneiras:
  • Um aplicativo solicita o WAM para um token de acesso silenciosamente, mas não existe um token de atualização disponível para esse aplicativo. Nesse caso, o WAM usa o PRT para solicitar um token para o aplicativo e retorna um novo PRT na resposta.
  • Um aplicativo solicita um token de acesso ao WAM, mas o PRT é inválido ou o Microsoft Entra ID exige autorização adicional (por exemplo, Autenticação Multifator do Microsoft Entra). Nesse cenário, o WAM inicia uma entrada interativa que exige que o usuário reautentica ou forneça uma verificação extra e um novo PRT é emitido na autenticação bem-sucedida.

Em um ambiente do ADFS, a linha de visão direta para o controlador de domínio não é necessária para renovar o PRT. A renovação do PRT requer apenas pontos de extremidade /adfs/services/trust/2005/usernamemixed e /adfs/services/trust/13/usernamemixed habilitados no proxy ao usar o protocolo WS-Trust.

A autenticação de senha nos endpoints de transporte do Windows é necessária apenas quando uma senha é alterada, não para renovação de PRT.

Considerações-chave

• Nos dispositivos ingressados no Microsoft Entra ou híbridos ingressados no Microsoft Entra, o plug-in CloudAP é considerado a autoridade principal para um PRT. Caso um PRT seja renovado durante uma solicitação de token baseada em WAM, o PRT será enviado de volta para o plug-in CloudAP, o qual verificará sua validade com o Microsoft Entra ID antes de aceitá-lo.

O macOS renova o PRT (Token de Atualização Primária) do PSSO a cada 4 horas ou mais cedo se os tokens SSO estiverem ausentes ou tiverem expirado.

No iOS, também há uma atualização oportunista quando o dispositivo está sendo carregado, ocorrendo não mais do que uma vez a cada dois dias, sujeito à alocação de recursos pelo sistema operacional iOS. Da mesma forma que outras plataformas, um PRT é válido por 90 dias se estiver em uso.

Um PRT é válido por 90 dias e é renovado a cada 4 horas se o usuário usa ativamente o dispositivo.

• Um PRT é válido por 90 dias e é renovado continuamente desde que o usuário use ativamente o dispositivo.
• Um PRT só é emitido e renovado durante uma autenticação de aplicativo nativo. Um PRT não é renovado nem emitido durante uma sessão do navegador.
• É possível obter um PRT sem a necessidade de registro de dispositivo (ingressar no local de trabalho) e habilitar o SSO.
• Os PRTs obtidos sem o registro do dispositivo não podem atender aos critérios de autorização do acesso condicional que dependem do status ou da conformidade do dispositivo.

Um PRT é protegido associando-o ao dispositivo ao qual o usuário se conectou, no qual usará a associação de hardware quando disponível e com suporte.

O Windows 10 ou posteriores e o Microsoft Entra ID habilitam a proteção do PRT através dos seguintes métodos:

• Durante a primeira entrada: durante a primeira entrada, um PRT é emitido por meio de solicitações de assinatura usando a chave do dispositivo gerada criptograficamente durante o registro do dispositivo. Em um dispositivo com um TPM válido e em funcionamento, a chave do dispositivo é protegida pelo TPM, o que impede qualquer acesso mal-intencionado. Um PRT não é emitido se não é possível validar a assinatura da chave de dispositivo correspondente.
• Durante solicitações e renovações de token: quando um PRT é emitido, o Microsoft Entra ID também emite uma chave da sessão criptografada para o dispositivo. Ele é criptografado com a tkpub (chave de transporte pública) gerada e enviada ao Microsoft Entra ID como parte do registro do dispositivo. Essa chave da sessão só pode ser descriptografada pela chave de transporte privada (tkpriv) protegida pelo TPM. A chave de sessão é a chave de prova de posse (POP) para todas as solicitações enviadas ao Microsoft Entra ID. A chave da sessão também é protegida pelo TPM, e nenhum outro componente do sistema operacional pode acessá-la. As solicitações de token ou de renovação de PRT são assinadas com segurança por essa chave da sessão por meio do TPM e, portanto, não podem ser adulteradas. O Microsoft Entra invalida qualquer solicitação do dispositivo que não esteja assinada pela chave da sessão correspondente.

Ao proteger essas chaves com o TPM, aprimoramos a segurança para PRT de atores mal-intencionados que tentam roubar as chaves ou repetir o PRT. Portanto, o uso de um TPM aumenta significativamente a segurança dos dispositivos associados ao Microsoft Entra, dos dispositivos híbridos associados ao Microsoft Entra e dos dispositivos registrados no Microsoft Entra contra o roubo de credenciais. Para melhor desempenho e confiabilidade, o TPM 2.0 é a versão recomendada para todos os cenários de registro de dispositivos do Microsoft Entra no Windows 10 ou posteriores. Após a atualização do Windows 10, 1903, a ID do Microsoft Entra não usa o TPM 1.2 para nenhuma das chaves acima devido a problemas de confiabilidade.

Um PRT (Token de Atualização Primária) é associado com segurança ao dispositivo no qual o usuário entra. A ID do Microsoft Entra e o macOS impõem essa proteção por meio de vários mecanismos:

O PRT é emitido somente depois que uma solicitação é assinada usando uma chave de assinatura de dispositivo com suporte de enclave seguro, que é gerada criptograficamente durante o registro do dispositivo. Se a assinatura dessa chave não puder ser validada, o PRT não será emitido.

Para macOS em que o SSO da Plataforma é usado, ele usará a associação de hardware por padrão.

Para habilitar a associação de hardware no iOS e no Mac, siga as diretrizes do Plug-in do SSO da Apple

Android, iOS e Linux não dão suporte à associação de hardware para PRTs.

Para habilitar a associação de hardware no iOS e no Mac, siga as diretrizes do Plug-in do SSO da Apple

• Quando um aplicativo solicita token por meio do WAM, a ID do Microsoft Entra 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 para o aplicativo e protege o token de atualização:
  • Se for um token de atualização para um usuário de SSO, esse token de atualização será associado 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 não SSO, esse token de atualização não será associado ao dispositivo.
• Todos os tokens de atualização são criptografados pelo DPAPI.

• IOS não gerenciado: em dispositivos sem perfil de extensão de SSO do MDM, o agente retorna o token de acesso e o token de atualização para o aplicativo de chamada. O aplicativo de chamada usa o token de atualização para atualizações subsequentes e esse token de atualização não será protegido.
• macOS/iOS gerenciado: em dispositivos com perfil de extensão de SSO do MDM, o agente retorna apenas o token de acesso ao aplicativo de chamada. O Broker usa PRT para qualquer atualização de token subsequente e não usa token de atualização desprotegido. Recomendamos que os clientes usem essa configuração na não gerenciada devido à proteção extra que ela fornece.

• O Agente retorna apenas o token de acesso ao aplicativo de chamada e armazena o token de atualização do aplicativo localmente para dispositivos gerenciados e não gerenciados.

• No Linux, o agente retorna apenas o token de acesso para o aplicativo de chamada e armazena tokens de atualização localmente para dispositivos gerenciados e não gerenciados.
• Os tokens de atualização armazenados localmente são criptografados com uma chave de criptografia armazenada no keyring de entrada do usuário UNIX.

• No Windows 10 ou mais recente, o Microsoft Entra ID dá suporte ao SSO do navegador no Microsoft Edge nativamente, no Google Chrome por meio de suporte ou extensão nativo e no Mozilla Firefox v91+ por meio de uma configuração de navegador.

• Quando um usuário inicia uma interação com o navegador, o navegador (ou a extensão) invoca uma API de plataforma. A extensão chama essa API por meio de um host de mensagens nativo. A API garante que a página seja de um dos domínios permitidos. O navegador envia uma cadeia de caracteres de consulta completa, que inclui um nonce. A API da plataforma cria um PRT e um cabeçalho de dispositivo, que são assinados com as chaves protegidas pelo TPM. O cabeçalho PRT é assinado pela chave de sessão, o cabeçalho do dispositivo pela chave do dispositivo, portanto, é difícil adulterar. Esses cabeçalhos são incluídos em todas as solicitações para que a ID do Microsoft Entra valide o dispositivo do qual ele é originário e o usuário. Depois que a ID do Microsoft Entra valida esses cabeçalhos, ela emite um cookie de sessão para o navegador. Este cookie de sessão também contém a mesma chave de sessão ou dispositivo usada para assinar a solicitação. Durante as solicitações subsequentes, a chave da sessão é validada, associando efetivamente o cookie ao dispositivo e impedindo retransmissões de outros locais.

O Safari e o Microsoft Edge com o perfil de extensão de SSO terão cookies protegidos pela chave de sessão prt. O Microsoft Edge exige que o usuário seja conectado ao perfil do Microsoft Edge. Os cookies não são protegidos sem o perfil de extensão de SSO.

Durante as entradas interativas, o cookie de SSO do navegador é gerado (usando o PRT e a chave de sessão que está no armazenamento gerenciado da conta android). Aplicável somente ao navegador Microsoft Edge e ao usuário deve estar conectado.

O Microsoft Edge no Linux pode solicitar ao agente um cookie de SSO do navegador para habilitar o SSO no Microsoft Edge. O agente gera o cookie de SSO usando PRT e Chave de Sessão armazenados no contexto do agente do usuário e do dispositivo, respectivamente, para retornar o cookie gerado para o Microsoft Edge. O Microsoft Edge exige que o usuário seja conectado ao perfil. Teoricamente, aplicativos diferentes do Microsoft Edge também podem solicitar esse cookie do Broker, pois não há nenhuma identidade de aplicativo na plataforma Linux. O limite de segurança do sistema operacional está em torno do usuário UNIX e somente os aplicativos no mesmo contexto de usuário podem adquirir cookie de SSO para um usuário nesse contexto.

• Entrar com o Windows Hello para Empresas: O Windows Hello para Empresas substitui senhas e usa chaves criptográficas para fornecer uma autenticação forte de dois fatores. O Windows Hello para Empresas é específico a um usuário em um dispositivo e ele mesmo requer a MFA para provisionar. Quando um usuário faz login usando o Windows Hello para Empresas, o PRT do usuário recebe uma declaração de MFA. Esse cenário também se aplica aos usuários que fizerem logon com cartões inteligentes se a autenticação smartcard produzir uma declaração de MFA do ADFS.
  • Como o Windows Hello para Empresas é considerado uma autenticação multifator, a declaração de MFA é atualizada quando o próprio PRT é atualizado. Portanto, a duração da MFA se estenderá continuamente quando os usuários se conectarem usando o Windows Hello para Empresas.
• MFA durante um login interativo do WAM: durante uma solicitação de token por meio do WAM, caso um usuário seja solicitado a realizar MFA para acessar o aplicativo, o PRT renovado durante essa interação será carregado com uma declaração de MFA.
  • Nesse caso, a declaração de MFA não é atualizada continuamente. Portanto, a duração dela é baseada no tempo de vida definido no diretório.
  • Quando um PRT e um RT já existentes são usados para o acesso a um aplicativo, eles são considerados a primeira prova de autenticação. Um novo RT é obrigatório com uma segunda prova e uma declaração de MFA impressa. Esse 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. Consequentemente, existe um PRT para cada Windows Hello para Empresas, senha ou cartão inteligente. Esse particionamento garante que as declarações de MFA sejam isoladas com base na credencial usada e que não sejam misturadas durante solicitações de token.

Se as políticas de AC tiverem sido definidas pelo administrador, o usuário será obrigado a fazer MFA. Nesses casos, o PRT seria atualizado e obterá uma declaração de MFA. A duração da declaração baseia-se no tempo de vida definido no diretório.