Grundlegendes zum primären Aktualisierungstoken (Primary Refresh Token, PRT)

Ein primäres Aktualisierungstoken (PRIMARY Refresh Token, PRT) ist ein wichtiges Artefakt der Microsoft Entra-Authentifizierung in unterstützten Versionen von Windows, iOS/macOS, Android und Linux. Ein PRT ist ein sicherheitsrelevantes Artefakt, das speziell an Microsoft-Erstanbieter-Tokenbroker ausgestellt wurde, um einmaliges Anmelden (Single Sign-On, SSO) in den anwendungen zu aktivieren, die auf diesen Geräten verwendet werden. In diesem Artikel wird erläutert, wie ein PRT für alle Anwendungen ausgestellt, verwendet und geschützt wird, um Ihre Sicherheit zu verbessern und einmaliges Anmelden (Single Sign-On, SSO) für alle Anwendungen zu aktivieren.

In diesem Artikel wird davon ausgegangen, dass Sie bereits die verschiedenen Gerätezustände kennen, die in der Microsoft Entra-ID verfügbar sind und wie einmaliges Anmelden in Windows funktioniert. Weitere Informationen zu Geräten in der Microsoft Entra-ID finden Sie unter Was ist die Geräteverwaltung in Microsoft Entra ID?.

Wichtige Terminologie und Komponenten

Die folgenden Windows-Komponenten spielen eine wichtige Rolle beim Anfordern und Verwenden eines primären Aktualisierungstokens (PRT):

Begriff	Beschreibung
Makler	Ein Identitätsbroker ist ein Dienst, der als Vermittler zwischen identitätsanbietern (IdPs) und Dienstanbietern (SPs) fungiert und die Authentifizierung und Autorisierung vereinfacht. Web Account Manager ist ein Beispiel für einen Identitätsbroker.
Cloudauthentifizierungsanbieter (CloudAP)	CloudAP ist der moderne Authentifizierungsanbieter für die Windows-Anmeldung, der überprüft, ob Benutzer sich auf einem Windows 10- oder neueren Gerät anmelden. CloudAP verfügt über ein Plug-In-Framework, das von Identitätsanbietern als Grundlage für die Ermöglichung der Windows-Authentifizierung mit den Anmeldeinformationen des jeweiligen Identitätsanbieters genutzt werden kann.
Web Account Manager (WAM)	WAM ist der Standardtokenbroker auf Windows 10- oder neueren Geräten. WAM verfügt auch über ein Plug-In-Framework, das Identitätsanbieter als Grundlage verwenden können, um einmaliges Anmelden (SSO) für ihre Anwendungen über den jeweiligen Identitätsanbieter zu ermöglichen.
Microsoft Entra CloudAP-Plug-In	Ein microsoft Entra-spezifisches Plug-In, das auf dem CloudAP-Framework basiert, das Benutzeranmeldeinformationen mit Microsoft Entra-ID während der Windows-Anmeldung überprüft.
Microsoft Entra WAM-Plug-In	Ein auf dem WAM-Framework basierendes Microsoft Entra-spezifisches Plug-In, das SSO anwendungen ermöglicht, die auf Microsoft Entra ID für die Authentifizierung angewiesen sind.
Dsreg	Eine microsoft Entra-spezifische Komponente unter Windows 10 oder höher, die den Geräteregistrierungsprozess für alle Gerätezustände verarbeitet.
Trusted Platform Module (TPM)	Ein TPM ist eine Hardwarekomponente, die in ein Gerät integriert ist, das hardwarebasierte Sicherheitsfunktionen für geheime Benutzer- und Geräteschlüssel bereitstellt. Weitere Informationen finden Sie im Artikel Trusted Platform Module – Technologieübersicht.

Wofür wird ein PRT verwendet?

• Single Sign-On (SSO) – Sobald sich ein Benutzer bei seinem Gerät anmeldet, kann der PRT auf Microsoft 365, Azure und andere Cloud-Apps zugreifen, ohne dass der Benutzer seine Anmeldeinformationen erneut eingeben muss. Apps wie Office, Microsoft Edge und Teams verwenden das PRT über einen Broker, um Benutzer automatisch zu authentifizieren, die Benutzererfahrung zu verbessern, die Notwendigkeit mehrerer Anmeldungen zu verringern und die Produktivität zu verbessern.
• Tokenerwerb – Das PRT wird verwendet, um Zugriffstoken und Aktualisierungstoken für verschiedene Dienste (z. B. Outlook, Teams, SharePoint usw.) über den Windows Web Account Manager (WAM) oder Broker-Plug-Ins auf anderen Plattformen anzufordern.
• Compliance für bedingten Zugriff – Es enthält Geräte- und Benutzeransprüche, die von microsoft Entra ID ausgewertet werden, um Richtlinien für bedingten Zugriff zu erzwingen (z. B. erforderliche kompatible Geräte, MFA usw.).

Welche Arten von PRT gibt es?

Auf hoher Ebene gibt es zwei verschiedene Arten von PRT-Artefakten.

• Registrierte Geräte-PRTs sind an ein Gerät gebunden, das über eine zugeordnete Microsoft Entra-Identität verfügt.
• Nicht registrierte Geräte-PRTs sind an ein Gerät gebunden, das nicht über eine Microsoft Entra-Identität verfügt, die einem vom Client generierten kryptografischen Schlüsselpaar auf einem Gerät zugeordnet ist.

Clients versuchen immer, "registrierte Geräte-PRTs" zu verwenden, wenn möglich. PRTs erfüllen nur Geräteregistrierungsrichtlinien, wenn sie für registrierte Geräte ausgestellt werden. Nicht registrierte Geräte-PRTs werden in Szenarien verwendet, in denen das Gerät nicht über eine Microsoft Entra-Identität verfügt, z. B. wenn sich ein Benutzer bei einem Browser auf einem persönlichen Gerät anmeldet oder sich ein Benutzer bei einer App anmeldet, die die Geräteregistrierung nicht unterstützt.

Kann ich sehen, was in einem PRT enthalten ist?

Ein PRT ist ein von Microsoft Entra gesendetes nicht transparentes Blob, dessen Inhalt für Clientkomponenten nicht sichtbar ist. Sie können nicht sehen, was in einem PRT enthalten ist.

Wie wird ein PRT ausgestellt?

Für registrierte Geräte-PRTs wird der PRT für Benutzer auf registrierten Geräten ausgestellt. Ausführlichere Informationen zur Geräteregistrierung finden Sie im Artikel Windows Hello for Business und Geräteregistrierung. Während der Geräteregistrierung werden mit der dsreg-Komponente zwei Sätze mit kryptografischen Schlüsselpaaren generiert:

• Geräteschlüssel (dkpub/dkpriv)
• Transportschlüssel (tkpub/tkpriv)

PRT kann nur ausgestellt werden, wenn ein Microsoft Entra ID-Broker vorhanden ist. Broker ist eine Komponente, die mit den folgenden Apps verteilt wird: Intune Company Portal unter macOS und Linux, Authenticator unter iOS, Authenticator, Link zu Windows und Unternehmensportal unter Android. Auf dem Mac ist die Verwaltung mobiler Geräte (Mobile Device Management, MDM) erforderlich, um den Broker neben dem SSO-Erweiterungsprofil zu aktivieren: Apple SSO-Plug-In

Windows

Wenn das Gerät über einen gültigen und funktionierenden TPM-/sicheren Hardwarespeicher verfügt, sind die privaten Schlüssel an den sicheren Speicher des Geräts auf unterstützten Plattformen gebunden. Die öffentlichen Schlüssel werden während des Geräteregistrierungsprozesses an Die Microsoft Entra-ID gesendet, um den Gerätestatus während PRT-Anforderungen zu überprüfen.

Das PRT wird während der Benutzerauthentifizierung auf einem Gerät mit Windows 10 oder höher in zwei Szenarien ausgestellt:

• Microsoft Entra ist beigetreten oder microsoft Entra hybrid eingebunden: Während der Windows-Anmeldung wird ein PRT ausgegeben, wenn sich ein Benutzer mit seinen Organisationsanmeldeinformationen anmeldet. Ein PRT wird mit allen von Windows 10 oder höheren Versionen unterstützten Anmeldeinformationen ausgestellt, z. B. Kennwort und Windows Hello for Business. In diesem Szenario ist das Microsoft Entra CloudAP-Plug-In die primäre Autorität für das PRT
• Microsoft Entra registriertes Gerät: Ein PRT wird ausgegeben, wenn ein Benutzer dem Windows 10- oder neueren Gerät ein sekundäres Geschäftskonto hinzufügt. Benutzer können windows 10 oder höher auf zwei verschiedene Arten ein Konto hinzufügen:
  • Hinzufügen eines Kontos über die Eingabeaufforderung Verwaltung meines Geräts durch meine Organisation zulassen nach der Anmeldung bei einer App (z. B. Outlook)
  • Hinzufügen eines Kontos über Einstellungen>Konten>Auf Arbeits- oder Schulkonto zugreifen>Verbinden

In Microsoft Entra registrierten Geräteszenarien ist das Microsoft Entra WAM-Plug-In die primäre Autorität für das PRT, da die Windows-Anmeldung nicht mit diesem Microsoft Entra-Konto geschieht.

macOS

macOS mit Plattform-SSO

MacOS Platform Single Sign-On (PSSO) ist ein neues Feature, das vom Microsoft Enterprise SSO-Plug-In, Plattformanmeldeinformationen für macOS, unterstützt wird, mit dem Benutzer sich mit ihren Microsoft Entra ID-Anmeldeinformationen bei Mac-Geräten anmelden können.

Das PRIMÄRE AKTUALISIERUNGstoken (PSSO Primary Refresh Token, PRT) wird ausschließlich für entra-eingebundene macOS-Geräte ausgestellt, die die Plattform-SSO-Registrierung erfolgreich abgeschlossen haben. Während dieses Registrierungsvorgangs generiert macOS sichere Enklaven-gesicherte Kryptografieschlüsselpaare: eine für die Gerätesignierung und eine andere für die Geräteverschlüsselung. Die Verweise auf öffentliche Schlüssel werden für die SSO-Erweiterung freigegeben.

Die SSO-Erweiterung verwendet diese Schlüssel, um die Geräteregistrierung mit dem Microsoft Entra ID Device Registration Service abzuschließen. Anschließend wird die loginConfiguration-API von Apple mit den erforderlichen Parametern für die PRT-Übernahme konfiguriert.

macOS ohne Plattform-SSO

macOS unterstützt Unregistrierte PRTs für Microsoft Edge und Registrierte PRTs, wenn das Gerät im Unternehmensnetzwerk eingebunden ist und der Broker vorhanden ist.

Nachdem die Registrierung erfolgreich abgeschlossen wurde, initiiert macOS eine Anmeldeanforderung, die mit dem Gerätesignaturschlüssel signiert ist. Die Microsoft Entra-ID überprüft die Anforderung, den Gerätesignaturschlüssel und die zugehörigen Parameter und gibt die PRT-Antwort aus.

iOS und Android

iOS, macOS und Android unterstützen sowohl unregisterte PRTs für Microsoft Edge als auch registrierte PRTs, wenn der Broker vorhanden ist.

Linux

Linux unterstützt sowohl unregisterte PRTs für Microsoft Edge als auch registrierte PRTs, wenn der Broker vorhanden ist.

Browserverhalten

Browser erhalten je nach Betriebssystem auf mehrere Arten Zugriff auf das PRT:

Windows

Windows – Ruft die PRT über den Broker in den folgenden Browsern ab:

• Microsoft Edge

• Firefox

• Chrom

Android

Android – Microsoft Edge zieht die PRT vom Broker in den Browser.

iOS und macOS

Auf iOS und macOS können Browser auch den PRT abrufen, wenn das SSO-Erweiterungsprofil installiert ist, und so Folgendes aktivieren:

• Chrome- und Firefox-Unterstützung unter macOS
• Safari-Unterstützung für iOS und macOS
• Microsoft Edge unter iOS und macOS

Linux

Linux - Microsoft Edge zieht den PRT vom Broker in den Browser'

Die Liste der unterstützten Browser ist hier verfügbar: Unterstützte Browser

Hinweis

Kunden, die entra-Partnerverbund mit Nicht-Microsoft-Identitätsanbietern aktivieren, müssen diese Identitätsanbieter konfigurieren, um WS-Trust Protokoll zu unterstützen, um die PRT-Ausstellung auf Windows 10- oder neueren Geräten zu aktivieren. Ohne WS-Trust für Partnerverbundfälle kann ein PRT nicht für Benutzer auf Microsoft Entra-Hybridgeräten oder in Microsoft Entra eingebundenen Geräten ausgestellt werden.

Hinweis

Für ADFS usernamemixed sind Endpunkte erforderlich. Wenn Smartcard/certificate sie während der Windows-Anmeldung verwendet wird, certificatemixed müssen Endpunkte auf ADFS konfiguriert werden. windowstransport sollte nur als intranetorientierte Endpunkte aktiviert sein und darf nicht als extranetgerichtete Endpunkte über den Webanwendungsproxy verfügbar gemacht werden .

Hinweis

Microsoft Entra-Richtlinien für bedingten Zugriff werden nicht ausgewertet, wenn PRTs ausgegeben werden.

Hinweis

Wir unterstützen keine Nicht-Microsoft-Authentifizierungsanbieter bei der Ausstellung und Erneuerung von Microsoft Entra PRTs.

Wie wird ein PRT verwendet?

Windows

Ein PRT wird in Windows von zwei wichtigen Komponenten verwendet:

• Microsoft Entra-CloudAP-Plug-In: Während der Windows-Anmeldung fordert das Microsoft Entra-CloudAP-Plug-In unter Verwendung der vom Benutzer angegebenen Anmeldeinformationen einen PRT von Microsoft Entra ID an. Außerdem wird das PRT zwischengespeichert, um die zwischengespeicherte Anmeldung zu ermöglichen, wenn der Benutzer keinen Zugriff auf eine Internetverbindung hat.
• Microsoft Entra-WAM-Plug-In: Wenn Benutzer versuchen, auf Anwendungen zuzugreifen, wird das PRT vom Microsoft Entra-WAM-Plug-In genutzt, um einmaliges Anmelden unter Windows 10 oder einer höheren Version zu ermöglichen. Das Microsoft Entra-WAM-Plug-In nutzt das PRT, um Aktualisierungs- und Zugriffstoken für Anwendungen anzufordern, für die WAM für Tokenanforderungen verwendet wird. Außerdem wird hiermit SSO in Browsern ermöglicht, indem das PRT in Browseranforderungen eingefügt wird. Browser-SSO in Windows 10 oder höher wird unter Microsoft Edge (nativ), Chrome (über die Windows 10-Kontenerweiterung ) und Mozilla Firefox v91+ (Firefox Windows SSO-Einstellung) unterstützt.

  Hinweis

  In Fällen, in denen ein Benutzer über zwei Konten desselben Microsoft Entra-Mandanten verfügt, die bei einer Browseranwendung angemeldet sind, wird die vom PRT des primären Kontos bereitgestellte Geräteauthentifizierung automatisch auch auf das zweite Konto angewendet. Daher erfüllt das zweite Konto auch alle gerätebasierten Richtlinien für bedingten Zugriff für den Mandanten.

macOS

Eine PRT wird von der SSO-Erweiterung verwendet, um SSO für Apps und Websites bereitzustellen. Ein PRT wird verwendet, um Aktualisierungs- und Zugriffstoken für Anwendungen anzufordern, die auf der SSO-Erweiterung für Tokenanforderungen basieren. Außerdem wird hiermit SSO in Browsern ermöglicht, indem das PRT in Browseranforderungen eingefügt wird.

Die Browser, die Browser-SSO unterstützen, sind Safari, Firefox, Chrome und Microsoft Edge.

Ios

Für iOS werden nur Microsoft Edge und Safari für Browser-SSO unterstützt.

Android

Für Android wird nur Microsoft Edge für Browser-SSO unterstützt.

Linux

Die einzigen nativen Apps, die heute integriert sind, sind Intune und Microsoft Edge Browser. Für die Browserunterstützung ist nur der Microsoft Edge-Browser für gerätegebundene Token und die Erzwingung des bedingten Zugriffs geschützt.

Welche Lebensdauer hat ein PRT?

Nach der Ausstellung ist ein PRT für 90 Tage gültig und wird kontinuierlich verlängert, solange der Benutzer das Gerät aktiv verwendet. Organisationen können verlangen, dass Benutzer sich erneut authentifizieren, um mithilfe der Anmelde-Frequenzsteuerung auf Ressourcen zuzugreifen.

Wie wird ein PRT verlängert?

Windows

Windows-Plattform

Ein PRT wird auf zwei verschiedene Arten erneuert:

• Alle vier Stunden per Microsoft Entra-CloudAP-Plug-In: Das CloudAP-Plug-In verlängert das PRT während der Windows-Anmeldung alle vier Stunden. Wenn der Benutzer während dieses Zeitraums nicht über eine Internetverbindung verfügt, verlängert das CloudAP-Plug-In das PRT, nachdem das Gerät mit dem Internet verbunden wurde und eine neue Windows-Anmeldung durchgeführt wurde.
• Microsoft Entra-WAM-Plug-In bei Anforderungen von App-Token: Mit dem WAM-Plug-In wird einmaliges Anmelden auf Geräten mit Windows 10 oder höher ermöglicht, indem automatische Tokenanforderungen für Anwendungen aktiviert werden. Das WAM-Plug-In kann das PRT während dieser Tokenanforderungen auf zwei Arten verlängern:
  • Eine App fordert WAM automatisch für ein Zugriffstoken an, aber für die App ist kein Aktualisierungstoken vorhanden. In diesem Fall nutzt WAM das PRT, um ein Token für die App anzufordern, und erhält als Antwort ein neues PRT.
  • Eine App fordert von WAM ein Zugriffstoken an, aber das PRT ist ungültig, oder Microsoft Entra ID erfordert eine zusätzliche Autorisierung (z. B. Microsoft Entra-Multi-Faktor-Authentifizierung). In diesem Szenario initiiert WAM eine interaktive Anmeldung, die erfordert, dass der Benutzer erneut authentifiziert oder zusätzliche Überprüfungen bereitstellt und eine neue PRT bei erfolgreicher Authentifizierung ausgestellt wird.

In einer ADFS-Umgebung ist keine direkte Sichtlinie zum Domänencontroller erforderlich, um die PRT zu erneuern. Für die PRT-Verlängerung müssen nur die Endpunkte /adfs/services/trust/2005/usernamemixed und /adfs/services/trust/13/usernamemixed auf dem Proxy mithilfe des WS-Trust-Protokolls aktiviert werden.

Windows-Transportendpunkte werden nur für die Kennwortauthentifizierung benötigt, wenn ein Kennwort geändert wird, nicht aber für die PRT-Verlängerung.

Wichtige Aspekte

• Für in Microsoft Entra eingebundene und hybrid in Microsoft Entra eingebundene Geräte ist das CloudAP-Plug-In die primäre Autorität für ein PRT. Wenn ein PRT während einer WAM-basierten Tokenanforderung verlängert wird, wird es zurück an das CloudAP-Plug-In gesendet. Dort wird die Gültigkeit des PRT für Microsoft Entra ID überprüft, bevor es akzeptiert wird.

macOS

macOS erneuert das primäre PSSO-Aktualisierungstoken (PRT) alle 4 Stunden oder früher, wenn die SSO-Token fehlen oder abgelaufen sind.

Ios

Unter iOS gibt es auch ein opportunistisches Update, wenn das Gerät geladen wird und nicht mehr als einmal alle zwei Tage stattfindet, vorbehaltlich der Ressourcenzuweisung durch das iOS-Betriebssystem. Ähnlich wie bei anderen Plattformen ist ein PRT 90 Tage lang gültig, wenn er verwendet wird.

Linux

Ein PRT ist 90 Tage gültig und wird alle 4 Stunden verlängert, wenn der Benutzer das Gerät aktiv verwendet.

Android

• Ein PRT ist 90 Tage lang gültig und wird kontinuierlich verlängert, solange der Benutzer das Gerät aktiv verwendet.
• Ein PRT wird nur während einer nativen App-Authentifizierung ausgestellt und verlängert. Ein PRT wird während einer Browsersitzung nicht verlängert oder ausgestellt.
• Es ist möglich, eine PRT ohne Geräteregistrierung (Workplace Join) zu erhalten und SSO zu aktivieren.
• PRTs, die ohne Geräteregistrierung ausgestellt wurden, können die Autorisierungskriterien für den bedingten Zugriff, der sich auf den Status oder die Konformität des Geräts stützt, nicht erfüllen.

Hinweis

Microsoft Entra-Richtlinien für bedingten Zugriff werden nicht ausgewertet, wenn PRTs erneuert werden.

Wie wird das PRT geschützt?

Windows

Ein PRT ist geschützt, indem es an das Gerät gebunden wird, bei dem sich der Benutzer angemeldet hat, wo er hardwarebindung verwendet, wenn verfügbar und unterstützt wird.

Für Microsoft Entra ID und Windows 10 oder höher wird der PRT-Schutz anhand der folgenden Methoden ermöglicht:

• Während der ersten Anmeldung: Während der ersten Anmeldung wird ein PRT ausgestellt, indem Anforderungen mit dem Geräteschlüssel signiert werden, der während der Geräteregistrierung kryptografisch generiert wurde. Auf einem Gerät mit einem gültigen und funktionierenden TPM wird der Geräteschlüssel per TPM geschützt, um schädliche Zugriffe zu verhindern. Es wird kein PRT ausgestellt, wenn die entsprechende Geräteschlüsselsignatur nicht überprüft werden kann.
• Bei Tokenanforderungen und -verlängerungen: Wenn ein PRT ausgestellt wird, wird von Microsoft Entra ID auch ein verschlüsselter Sitzungsschlüssel für das Gerät ausgestellt. Der Schlüssel wird mit dem öffentlichen Transportschlüssel (tkpub) generiert und im Rahmen der Geräteregistrierung an Microsoft Entra ID gesendet. Dieser Sitzungsschlüssel kann nur mit dem privaten Transportschlüssel (tkpriv) entschlüsselt werden, der per TPM geschützt ist. Der Sitzungsschlüssel ist der Schlüssel für den Eigentumsnachweis (Proof-of-Possession, POP) für alle Anforderungen, die an Azure AD gesendet werden. Der Sitzungsschlüssel ist außerdem durch das TPM geschützt, und keine anderen Betriebssystemkomponenten können darauf zugreifen. Tokenanforderungen oder Anforderungen zur PRT-Verlängerung werden mit diesem Sitzungsschlüssel über das TPM auf sichere Weise signiert und können daher nicht manipuliert werden. Alle Anforderungen von diesem Gerät, die nicht mit dem entsprechenden Sitzungsschlüssel signiert sind, werden von Microsoft Entra ungültig gemacht.

Durch das Sichern dieser Schlüssel mit dem TPM verbessern wir den Schutz des PRT vor böswilligen Akteuren, die versuchen, die Schlüssel zu stehlen oder das PRT wiederzugeben. Die Verwendung eines TPM erhöht also enorm die Sicherheit gegen Diebstahl von Anmeldeinformationen von in Microsoft Entra eingebundenen, hybrid in Microsoft Entra eingebundenen und bei Microsoft Entra registrierten Geräten. In Bezug auf Leistung und Zuverlässigkeit ist TPM 2.0 die empfohlene Version für alle Szenarien der Microsoft Entra-Geräteregistrierung unter Windows 10 oder höher. Nach dem Windows 10, 1903-Update verwendet Microsoft Entra-ID TPM 1.2 aufgrund von Zuverlässigkeitsproblemen für keinen der oben genannten Schlüssel.

macOS

Ein primäres Aktualisierungstoken (Primary Refresh Token, PRT) ist sicher an das Gerät gebunden, auf dem sich der Benutzer anmeldet. Microsoft Entra ID und macOS erzwingen diesen Schutz über mehrere Mechanismen:

Das PRT wird erst ausgegeben, nachdem eine Anforderung mit einem sicheren Enklaven-gesicherten Gerätesignaturschlüssel signiert wurde, der während der Geräteregistrierung kryptografisch generiert wird. Wenn die Signatur dieses Schlüssels nicht überprüft werden kann, wird die PRT nicht ausgestellt.

Für macOS, bei dem Plattform-SSO verwendet wird, wird standardmäßig Hardwarebindung verwendet.

Um die Hardwarebindung unter iOS und Mac zu aktivieren, folgen Sie den Anweisungen des Apple SSO-Plug-Ins

Andere Betriebssysteme

Android, iOS und Linux unterstützen keine Hardwarebindung für PRTs.

Um die Hardwarebindung unter iOS und Mac zu aktivieren, folgen Sie den Anweisungen des Apple SSO-Plug-Ins

Wie sind App-Token geschützt?

Eine Übersicht darüber, wie Token im Allgemeinen geschützt werden, finden Sie unter Schützen von Token in der Microsoft Entra-ID

Windows

• Wenn eine App token über WAM anfordert, gibt Die Microsoft Entra-ID ein Zugriffstoken und in einigen Arten der Anforderungen ein Aktualisierungstoken aus. WAM gibt jedoch nur das Zugriffstoken an die App zurück und sichert das Aktualisierungstoken:
  • Wenn es sich um ein Aktualisierungstoken für einen SSO-Benutzer handelt, wird dieses Aktualisierungstoken an das Gerät gebunden, mit einem Sitzungsschlüssel (identisch mit PRT) oder dem Geräteschlüssel.
  • Wenn es sich um ein Aktualisierungstoken für einen Nicht-SSO-Benutzer handelt, ist dieses Aktualisierungstoken nicht an das Gerät gebunden.
• Alle Aktualisierungstoken werden von der DPAPI verschlüsselt.

macOS & iOS

• iOS nicht verwaltet: Auf Geräten ohne MDM-SSO-Erweiterungsprofil gibt der Broker sowohl das Zugriffstoken als auch das Aktualisierungstoken an die aufrufende App zurück. Die aufrufende App verwendet das Aktualisierungstoken für nachfolgende Aktualisierungen und dieses Aktualisierungstoken wird nicht geschützt.
• macOS/iOS verwaltet: Auf Geräten mit MDM-SSO-Erweiterungsprofil gibt der Broker nur das Zugriffstoken für die aufrufende App zurück. Broker verwendet PRT für jede nachfolgende Tokenaktualisierung und verwendet kein ungeschütztes Aktualisierungstoken. Wir empfehlen Kunden, diese Konfiguration aufgrund des zusätzlichen Schutzes, den sie bietet, über die nicht verwaltete Konfiguration zu verwenden.

Android

• Broker gibt nur das Zugriffstoken an die aufrufende App zurück und speichert das App-Aktualisierungstoken lokal für verwaltete und nicht verwaltete Geräte.

Linux

• Unter Linux gibt der Broker nur das Zugriffstoken für die aufrufende App zurück und speichert Aktualisierungstoken lokal für verwaltete und nicht verwaltete Geräte.
• Die lokal gespeicherten Aktualisierungstoken werden mit einem Verschlüsselungsschlüssel verschlüsselt, der im Anmeldeschlüsselring des UNIX-Benutzers gespeichert ist.

Wie werden Browsercookies geschützt

Windows

• In Windows 10 oder höher unterstützt Microsoft Entra ID systemeigene Browser-SSO in Microsoft Edge, in Google Chrome über nativen Support oder Erweiterung und in Mozilla Firefox v91+ über eine Browsereinstellung.

• Wenn ein Benutzer eine Browserinteraktion initiiert, ruft der Browser (oder die Erweiterung) eine Plattform-API auf. Die Erweiterung ruft diese API über einen nativen Messaginghost auf. Die API stellt sicher, dass die Seite aus einer der zulässigen Domänen stammt. Der Browser sendet eine vollständige Abfragezeichenfolge, die eine Nonce enthält. Die Plattform-API erstellt einen PRT- und Geräteheader, der mit den TPM-geschützten Schlüsseln signiert ist. Der PRT-Header wird vom Sitzungsschlüssel signiert, der Gerätekopf nach Geräteschlüssel, daher ist es schwierig, sie zu manipulieren. Diese Header sind in allen Anforderungen für Die Microsoft Entra-ID enthalten, um das Gerät zu überprüfen, von dem es stammt, und dem Benutzer. Sobald die Microsoft Entra-ID diese Header überprüft, gibt sie ein Sitzungscookies an den Browser aus. Dieses Sitzungscookies enthält auch denselben Sitzungs- oder Geräteschlüssel, der zum Signieren der Anforderung verwendet wird. Während der nachfolgenden Anforderungen wird der Sitzungsschlüssel auf effektive Weise überprüft, und das Cookie wird an das Gerät gebunden. So werden Wiedergaben von anderen Orten verhindert.

iOS und Mac

Safari und Microsoft Edge mit dem SSO-Erweiterungsprofil verfügen über Cookies, die durch den PRT-Sitzungsschlüssel geschützt sind. Microsoft Edge erfordert, dass der Benutzer beim Microsoft Edge-Profil angemeldet ist. Cookies werden nicht ohne das SSO-Erweiterungsprofil geschützt.

Android

Bei interaktiven Anmeldungen wird das Browser-SSO-Cookie generiert (mithilfe des PRT und des Sitzungsschlüssels, der sich im vom Android-Konto verwalteten Speicher befindet). Nur gültig für Microsoft Edge-Browser und -Benutzer muss angemeldet sein.

Linux

Microsoft Edge unter Linux kann den Broker für ein Browser-SSO-Cookie anfordern, um SSO in Microsoft Edge zu aktivieren. Der Broker generiert das SSO-Cookie mit PRT und Session Key, der im Benutzer- bzw. Gerätebrokerkontext gespeichert ist, um das generierte Cookie an Microsoft Edge zurückzugeben. Microsoft Edge erfordert, dass der Benutzer beim Profil angemeldet ist. Theoretisch können andere Apps als Microsoft Edge auch dieses Cookie von Broker anfordern, da auf der Linux-Plattform keine App-Identität vorhanden ist. Die Sicherheitsgrenze des Betriebssystems ist um den UNIX-Benutzer herum, und nur Apps im selben Benutzerkontext können SSO-Cookie für einen Benutzer in diesem Kontext erwerben.

Wann erhält ein PRT einen MFA-Anspruch?

In bestimmten Szenarien kann ein PRT einen Multi-Faktor-Authentifizierung-Anspruch erhalten. Wenn ein MFA-basiertes PRT zum Anfordern von Token für Anwendungen verwendet wird, wird der MFA-Anspruch auf diese App-Token übertragen. Diese Funktionalität ermöglicht Benutzern eine reibungslose Vorgehensweise, weil die MFA-Überprüfung für alle Apps, für die dies erforderlich ist, verhindert wird. Ein PRT kann einen MFA-Anspruch auf folgende Arten erhalten:

Windows

• Anmeldung mit Windows Hello for Business: Bei Windows Hello for Business werden anstelle von Kennwörtern kryptografische Schlüssel verwendet, um für eine sichere zweistufige Authentifizierung zu sorgen. Windows Hello for Business gilt spezifisch für einen Benutzer auf einem Gerät und erfordert selbst einen MFA-Vorgang für die Bereitstellung. Wenn sich ein Benutzer mit Windows Hello for Business anmeldet, erhält das PRT des Benutzers einen MFA-Anspruch. Dieses Szenario gilt auch für Benutzer, die sich mit Smartcards anmelden, wenn die Smartcard-Authentifizierung einen MFA-Anspruch von ADFS erzeugt.
  • Da Windows Hello for Business als Multi-Faktor-Authentifizierung gilt, wird der MFA-Anspruch aktualisiert, wenn das PRT selbst aktualisiert wird. Die MFA-Dauer wird also fortlaufend verlängert, wenn sich Benutzer mit Windows Hello for Business anmelden.
• MFA während der interaktiven WAM-Anmeldung: Für eine Tokenanforderung per WAM gilt Folgendes: Wenn ein Benutzer einen MFA-Vorgang durchführen muss, um auf die App zuzugreifen, wird das PRT, das während dieser Interaktion verlängert wird, mit einem MFA-Anspruch versehen.
  • In diesem Fall wird der MFA-Anspruch nicht fortlaufend aktualisiert. Die MFA-Dauer basiert daher auf der für das Verzeichnis festgelegten Lebensdauer.
  • Wenn ein bereits vorhandenes PRT und ein Aktualisierungstoken (Refresh Token, RT) für den Zugriff auf eine App verwendet werden, gelten das PRT und das RT als erster Authentifizierungsnachweis. Es ist ein neues RT mit einem zweiten Nachweis und einem MFA-Anspruch erforderlich. Bei diesem Vorgang werden auch ein neues PRT und ein neues RT ausgestellt.
• Unter Windows 10 oder höher wird für jeden Satz von Anmeldeinformationen eine partitionierte Liste mit PRTs geführt. Es ist also ein PRT für jede Windows Hello for Business-Instanz, jedes Kennwort oder jede Smartcard vorhanden. Mit dieser Partitionierung wird sichergestellt, dass MFA-Ansprüche anhand der verwendeten Anmeldeinformationen isoliert und bei Tokenanforderungen nicht verwechselt werden.

Hinweis

Bei Verwendung des Kennworts für die Anmeldung bei Windows 10 oder neuerem Microsoft Entra-Hybridgerät oder einem hybrid verbundenen Microsoft Entra-Gerät ist MFA während der interaktiven WAM-Anmeldung möglicherweise erforderlich, nachdem der mit PRT verknüpfte Sitzungsschlüssel rolld wurde – je nachdem, ob der Benutzer innerhalb dieser Sitzung den 2FA-Prozess bestanden hat.

iOS/Mac/Android/Linux

Wenn die Zertifizierungsstellenrichtlinien vom Administrator festgelegt wurden, muss der Benutzer MFA ausführen. In diesen Fällen würde das PRT aktualisiert und erhält einen MFA-Anspruch. Die Anspruchsdauer basiert auf der für das Verzeichnis festgelegten Lebensdauer.

Wann wird ein PRT ungültig gemacht?

Ein PRT wird in den folgenden Szenarien ungültig gemacht:

• Ungültiger Benutzer: Wenn Sie einen Benutzer in Microsoft Entra ID löschen oder deaktivieren, wird das entsprechende PRT ungültig und kann nicht verwendet werden, um Token für Anwendungen abzurufen. Wenn sich ein gelöschter oder deaktivierter Benutzer vorher an einem Gerät angemeldet hat, wird die Anmeldung für ihn über die zwischengespeicherte Anmeldung durchgeführt, bis CloudAP über den ungültigen Zustand informiert wird. Nachdem von CloudAP ermittelt wurde, dass der Benutzer ungültig ist, werden nachfolgende Anmeldungen blockiert. Für einen ungültigen Benutzer wird die Anmeldung auf neuen Geräten, für die die Anmeldeinformationen nicht zwischengespeichert werden, automatisch gesperrt.
• Ungültiges Gerät: Wenn Sie ein Gerät in Microsoft Entra ID löschen oder deaktivieren, wird das auf diesem Gerät abgerufene PRT ungültig und kann nicht verwendet werden, um Token für andere Anwendungen abzurufen. Wenn ein Benutzer bereits auf einem ungültigen Gerät angemeldet ist, ist dies weiterhin möglich. Es werden jedoch alle Token auf dem Gerät ungültig gemacht, und der Benutzer kann für Ressourcen über dieses Gerät kein SSO nutzen.
• Kennwortänderung: Wenn ein Benutzer das PRT mit dem Kennwort abgerufen hat, wird das PRT von Microsoft Entra ID für ungültig erklärt, wenn der Benutzer sein Kennwort ändert. Eine Kennwortänderung führt dazu, dass der Benutzer ein neues PRT erhält. Token können hierbei auf zwei Arten ungültig gemacht werden:
  • Wenn sich der Benutzer bei Windows mit seinem neuen Kennwort anmeldet, verwirft CloudAP das alte PRT und sendet eine Anforderung an Microsoft Entra ID, dass ein neues PRT mit dem neuen Kennwort ausgestellt werden soll. Wenn der Benutzer keine Internetverbindung hat, kann das neue Kennwort nicht überprüft werden, und der Benutzer wird möglicherweise von Windows aufgefordert, sein altes Kennwort einzugeben.
  • Wenn sich ein Benutzer mit seinem alten Kennwort angemeldet oder das Kennwort nach dem Anmelden bei Windows geändert hat, wird das alte PRT für alle WAM-basierten Tokenanforderungen verwendet. In diesem Szenario wird der Benutzer aufgefordert, während der WAM-Tokenanforderung eine erneute Authentifizierung durchzuführen, und ein neues PRT wird ausgestellt.
• TPM-Probleme: Es kann vorkommen, dass das TPM eines Geräts nicht reibungslos funktioniert oder ausfällt, sodass auf die mit dem TPM geschützten Schlüssel nicht mehr zugegriffen werden kann. In diesem Fall kann das Gerät kein PRT abrufen oder Token über ein vorhandenes PRT anfordern, da der Nachweis über den Besitz der kryptografischen Schlüssel nicht erbracht werden kann. Aus diesem Grund werden alle vorhandenen PRTs von Microsoft Entra ID ungültig gemacht. Wenn Windows 10 einen Fehler erkennt, wird ein Wiederherstellungsverfahren initiiert, um das Gerät mit neuen kryptografischen Schlüsseln wieder zu registrieren. Bei der Microsoft Entra-Hybrideinbindung wird die Wiederherstellung – wie auch bei der ersten Registrierung – automatisch ohne Benutzereingabe durchgeführt. Für in Microsoft Entra eingebundene oder registrierte Geräte muss die Wiederherstellung von einem Benutzer durchgeführt werden, der auf dem Gerät über Administratorrechte verfügt. In diesem Szenario wird das Wiederherstellungsverfahren über eine Windows-Eingabeaufforderung initiiert, in der für den Benutzer die Schritte zur erfolgreichen Wiederherstellung des Geräts angegeben werden.

Ausführliche Verfahren

Im folgenden Diagramm sind die zugrunde liegenden Details für das Ausstellen, Verlängern und Verwenden eines PRT zum Anfordern eines Zugriffstokens für eine Anwendung dargestellt. Darüber hinaus beschreiben diese Schritte auch, wie die zuvor erwähnten Sicherheitsmechanismen während dieser Interaktionen angewendet werden.

Nachfolgend sind die detaillierten Abläufe aufgeführt, die für das Windows-Betriebssystem spezifisch sind.

PRT-Erstellung bei der ersten Anmeldung (Windows)

Hinweis

Bei Geräten, die in Microsoft Entra eingebunden sind, erfolgt die Microsoft Entra-PRT-Ausstellung (Schritte A bis F) synchron, bevor sich der Benutzer bei Windows anmelden kann. Für hybrid in Microsoft Entra ID eingebundene Geräte ist die lokale Active Directory-Instanz die primäre Autorität. Der Benutzer kann sich also bei Microsoft Entra hybrid anmelden, nachdem er eine TGT für die Anmeldung erwerben kann, während die PRT-Ausstellung asynchron erfolgt. Dieses Szenario gilt nicht für registrierte Microsoft Entra-Geräte, da die Anmeldung keine Microsoft Entra-Anmeldeinformationen verwendet.

Hinweis

In einer hybrid in Microsoft Entra eingebundenen Windows-Umgebung erfolgt die Ausstellung des PRT asynchron. Die Ausstellung des PRT kann aufgrund von Problemen mit dem Verbundanbieter fehlschlagen. Dieser Fehler kann zu Anmeldeproblemen führen, wenn Benutzer versuchen, auf Cloudressourcen zuzugreifen. Es ist wichtig, dieses Szenario mit dem Anbieter des Verbunds zu beheben.

Schritt	Beschreibung
A	Benutzer geben ihr Kennwort auf der Benutzeroberfläche für die Anmeldung ein. Die Benutzeroberfläche für die Anmeldung (LogonUI) übergibt die Anmeldeinformationen in einem Authentifizierungspuffer an die lokale Sicherheitsautorität, von der sie wiederum intern an Cloudauthentifizierungsanbieter (CloudAP) übergeben werden. CloudAP leitet diese Anforderung an das CloudAP-Plug-In weiter.
B	Das CloudAP-Plug-In initiiert eine Bereichsermittlungsanforderung, um den Identitätsanbieter für den Benutzer zu identifizieren. Wenn für den Mandanten des Benutzers ein Verbundanbieter eingerichtet wurde, gibt Microsoft Entra ID den MEX-Endpunkt (MetadataExchange, Metadatenaustausch) des Verbundanbieters zurück. Andernfalls gibt Microsoft Entra ID zurück, dass der Benutzer verwaltet wird. Dies weist darauf hin, dass sich der Benutzer mithilfe von Microsoft Entra ID authentifizieren kann.
C	Wenn der Benutzer verwaltet wird, erhält der Cloudauthentifizierungsanbieter die Nonce von Microsoft Entra ID. Falls der Benutzer Teil eines Verbunds ist, fordert das CloudAP-Plug-In ein SAML-Token (Security Assertion Markup Language) mit den Anmeldeinformationen des Benutzers vom Verbundanbieter an. Die Nonce wird angefordert, bevor das SAML-Token an Microsoft Entra ID gesandt wird.
D	Das Cloudauthentifizierungsanbieter-Plug-In erstellt die Authentifizierungsanforderung mit den Anmeldeinformationen des Benutzers, einer Nonce und einem Brokerbereich, signiert die Anforderung mit dem Geräteschlüssel (dkpriv) und sendet sie an Microsoft Entra ID. In einer Verbundumgebung verwendet das CloudAP-Plug-In das VOM Partnerverbundanbieter zurückgegebene SAML-Token anstelle der Anmeldeinformationen des Benutzers.
E	Microsoft Entra ID überprüft die Anmeldeinformationen des Benutzers, die Nonce und die Gerätesignatur, stellt sicher, dass das Gerät im Mandanten gültig ist, und stellt das verschlüsselte PRT aus. Zusammen mit dem PRT stellt Microsoft Entra ID auch einen symmetrischen Schlüssel aus, der als Sitzungsschlüssel bezeichnet wird. Er wird von Microsoft Entra ID mit dem Transportschlüssel (tkpub) verschlüsselt. Darüber hinaus wird der Sitzungsschlüssel auch in das PRT eingebettet. Dieser Sitzungsschlüssel fungiert als Eigentumsnachweis (Proof-of-Possession, PoP) für nachfolgende Anforderungen mit dem PRT.
F	Das CloudAP-Plug-In übergibt das verschlüsselte PRT und den Sitzungsschlüssel an CloudAP. CloudAP fordert vom TPM die Entschlüsselung des Sitzungsschlüssels mit dem Transportschlüssel (tkpriv) und die erneute Verschlüsselung mit dem eigenen Schlüssel des TPM an. CloudAP speichert den verschlüsselten Sitzungsschlüssel zusammen mit dem PRT in seinem Cache.

PRT-Erneuerung in nachfolgenden Anmeldungen (Windows)

Schritt	Beschreibung
A	Benutzer geben ihr Kennwort auf der Benutzeroberfläche für die Anmeldung ein. Die Benutzeroberfläche für die Anmeldung (LogonUI) übergibt die Anmeldeinformationen in einem Authentifizierungspuffer an die lokale Sicherheitsautorität, von der sie wiederum intern an Cloudauthentifizierungsanbieter (CloudAP) übergeben werden. CloudAP leitet diese Anforderung an das CloudAP-Plug-In weiter.
B	Wenn sich der Benutzer bereits vorher in der Sitzung angemeldet hat, initiiert Windows die zwischengespeicherte Anmeldung und überprüft die Anmeldeinformationen, um die Anmeldung für den Benutzer durchzuführen. Alle vier Stunden initiiert das CloudAP-Plug-In asynchron die PRT-Verlängerung.
C	Das CloudAP-Plug-In initiiert eine Bereichsermittlungsanforderung, um den Identitätsanbieter für den Benutzer zu identifizieren. Wenn für den Mandanten des Benutzers ein Verbundanbieter eingerichtet wurde, gibt Microsoft Entra ID den Metadatenaustausch-Endpunkt (MEX-Endpunkt) des Verbundanbieters zurück. Andernfalls gibt Microsoft Entra ID zurück, dass der Benutzer verwaltet wird. Dies weist darauf hin, dass sich der Benutzer mithilfe von Microsoft Entra ID authentifizieren kann.
D	Falls der Benutzer Teil eines Verbunds ist, fordert das CloudAP-Plug-In ein SAML-Token mit den Anmeldeinformationen des Benutzers vom Verbundanbieter an. Die Nonce wird angefordert, bevor das SAML-Token an Microsoft Entra ID gesandt wird. Wenn der Benutzer verwaltet wird, erhält der Cloudauthentifizierungsanbieter die Nonce direkt von Microsoft Entra ID.
E	Das Cloudauthentifizierungsanbieter-Plug-In erstellt die Authentifizierungsanforderung mit den Anmeldeinformationen des Benutzers, einer Nonce und dem vorhandenen PRT, signiert die Anforderung mit dem Sitzungsschlüssel und sendet sie an Microsoft Entra ID. In einer Verbundumgebung verwendet das CloudAP-Plug-In das VOM Partnerverbundanbieter zurückgegebene SAML-Token anstelle der Anmeldeinformationen des Benutzers.
F	Microsoft Entra ID überprüft die Signatur des Sitzungsschlüssels, indem sie mit dem Sitzungsschlüssel verglichen wird, der in das PRT eingebettet ist. Anschließend wird die Nonce überprüft und sichergestellt, dass das Gerät im Mandanten gültig ist, und es wird ein neues PRT ausgestellt. Wie bereits beschrieben, verfügt das PRT auch hier wieder über den Sitzungsschlüssel, der mit dem Transportschlüssel (tkpub) verschlüsselt ist.
G	Das CloudAP-Plug-In übergibt das verschlüsselte PRT und den Sitzungsschlüssel an CloudAP. CloudAP fordert vom TPM die Entschlüsselung des Sitzungsschlüssels mit dem Transportschlüssel (tkpriv) und die erneute Verschlüsselung mit dem eigenen Schlüssel des TPM an. CloudAP speichert den verschlüsselten Sitzungsschlüssel zusammen mit dem PRT in seinem Cache.

Hinweis

Ein PRT kann extern erneuert werden, ohne dass eine VPN-Verbindung erforderlich ist, wenn usernamemixed Endpunkte extern aktiviert sind.

PRT-Verwendung während App-Tokenanforderungen (Windows)

Schritt	Beschreibung
A	Eine Anwendung wie Microsoft Outlook initiiert eine Tokenanforderung an WAM. Von WAM erhält das Microsoft Entra-WAM-Plug-In wiederum die Aufforderung, die Tokenanforderung zu verarbeiten.
B	Wenn für die Anwendung bereits ein Aktualisierungstoken verfügbar ist, wird es vom Microsoft Entra-WAM-Plug-In verwendet, um ein Zugriffstoken anzufordern. Um die Gerätebindung nachzuweisen, wird die Anforderung vom WAM-Plug-In mit dem Sitzungsschlüssel signiert. Microsoft Entra ID überprüft den Sitzungsschlüssel und stellt ein Zugriffstoken und ein neues Aktualisierungstoken mit Verschlüsselung per Sitzungsschlüssel für die App aus. Das WAM-Plug-In fordert das CloudAP-Plug-In auf, die Token zu entschlüsseln. Das CloudAP-Plug-In fordert wiederum das TPM auf, die Entschlüsselung mit dem Sitzungsschlüssel durchzuführen, sodass das WAM-Plug-In beide Token erhält. Als Nächstes stellt das WAM-Plug-In nur das Zugriffstoken für die Anwendung bereit, während es das Aktualisierungstoken per DPAPI wieder verschlüsselt und im eigenen Cache speichert.
C	Wenn kein Aktualisierungstoken für die Anwendung verfügbar ist, verwendet das Microsoft Entra WAM-Plug-In das PRT, um ein Zugriffstoken anzufordern. Als Eigentumsnachweis signiert das WAM-Plug-In die Anforderung, die das PRT enthält, mit dem Sitzungsschlüssel. Microsoft Entra ID überprüft die Sitzungsschlüsselsignatur, indem sie mit dem Sitzungsschlüssel verglichen wird, der in das PRT eingebettet ist. Anschließend wird überprüft, ob das Gerät gültig ist, und für die Anwendung werden ein Zugriffstoken und ein Aktualisierungstoken ausgestellt. Darüber hinaus kann Die Microsoft Entra-ID eine neue PRT (basierend auf dem Aktualisierungszyklus) ausstellen, die alle vom Sitzungsschlüssel verschlüsselt wurden.
D	Das WAM-Plug-In fordert das CloudAP-Plug-In auf, die Token zu entschlüsseln. Das CloudAP-Plug-In fordert wiederum das TPM auf, die Entschlüsselung mit dem Sitzungsschlüssel durchzuführen, sodass das WAM-Plug-In beide Token erhält. Als Nächstes stellt das WAM-Plug-In nur das Zugriffstoken für die Anwendung bereit, während es das Aktualisierungstoken per DPAPI wieder verschlüsselt und im eigenen Cache speichert. Das WAM-Plug-In verwendet das Aktualisierungstoken ab jetzt für diese Anwendung. Darüber hinaus gibt das WAM-Plug-In das neue PRT an das CloudAP-Plug-In zurück, von dem das PRT mit Microsoft Entra ID überprüft wird, bevor der eigene Cache aktualisiert wird. Das CloudAP-Plug-In verwendet ab jetzt das neue PRT.
E	WAM stellt das neu ausgestellte Zugriffstoken für die aufrufende Anwendung bereit.

Browser-SSO mit PRT (Windows)

Schritt	Beschreibung
A	Der Benutzer meldet sich mit seinen Anmeldeinformationen an Windows an, um ein PRT zu erhalten. Nachdem der Benutzer den Browser geöffnet hat, werden die URLs vom Browser (bzw. der Erweiterung) aus der Registrierung geladen.
B	Wenn ein Benutzer eine Microsoft Entra-Anmelde-URL öffnet, überprüft der Browser oder die Erweiterung die URL mit den aus der Registrierung abgerufenen. Wenn sie übereinstimmen, ruft der Browser den nativen Clienthost für den Tokenabruf auf.
C	Der native Clienthost überprüft, ob die URLs zu den Microsoft-Identitätsanbietern (Microsoft-Konto oder Microsoft Entra ID) gehören, extrahiert eine von der URL gesandte Nonce und sendet einen Aufruf zum Abrufen eines PRT-Cookies an das Cloudauthentifizierungsanbieter-Plug-In.
D	Das CloudAP-Plug-In erstellt das PRT-Cookie, signiert es mit dem TPM-gebundenen Sitzungsschlüssel und sendet es an den systemeigenen Clienthost zurück.
E	Der systemeigene Clienthost gibt dieses PRT-Cookie an den Browser zurück, der es als Teil des Anforderungsheaders mit dem Namen "x-ms-RefreshTokenCredential" enthält und Token von Microsoft Entra ID anfordert.
F	Microsoft Entra ID überprüft die Sitzungsschlüsselsignatur im PRT-Cookie, überprüft die Nonce, stellt sicher, dass das Gerät im Mandanten gültig ist, und stellt ein ID-Token für die Webseite und ein verschlüsseltes Sitzungscookie für den Browser aus.

Hinweis

Der in den vorherigen Schritten beschriebene Browser-SSO-Flow gilt nicht für Sitzungen in privaten Modi wie InPrivate in Microsoft Edge, Incognito in Google Chrome (bei Verwendung der Erweiterung für Microsoft-Konten) oder im privaten Modus in Mozilla Firefox ab Version v91+

Nächste Schritte

Weitere Informationen zur Behandlung von PRT-Problemen finden Sie im Artikel Beheben von Problemen bei hybrid in Microsoft Entra eingebundenen Geräten unter Windows 10 oder höher sowie unter Windows Server 2016.