Bedingter Microsoft Entra-Zugriff: Tokenschutz (Vorschau)

Der Tokenschutz (in der Branche manchmal als Tokenbindung bezeichnet) versucht, Angriffe über Tokendiebstahl zu reduzieren, indem sichergestellt wird, dass ein Token nur vom Zielgerät verwendet werden kann. Wenn ein Angreifer ein Token durch Hijacking oder Replay stehlen kann, kann er die Identität seines Opfers annehmen, bis das Token abläuft oder widerrufen wird. Tokendiebstahl kommt zwar relativ selten vor, der Schaden kann allerdings erheblich sein.

Der Tokenschutz schafft eine kryptografisch sichere Bindung zwischen dem Token und dem Gerät (geheimer Clientschlüssel), für das es ausgestellt wird. Ohne den geheimen Clientschlüssel ist das gebundene Token nutzlos. Wenn ein Benutzer ein Windows 10- oder neueres Gerät in der Microsoft Entra-ID registriert, ist seine primäre Identität an das Gerät gebunden. Dies bedeutet, dass eine Richtlinie sicherstellen kann, dass nur gebundene Anmeldesitzungstoken (oder Aktualisierungstoken), die auch als primäre Aktualisierungstoken (PRTs) bezeichnet werden, von Anwendungen verwendet werden, wenn der Zugriff auf eine Ressource angefordert wird.

Wichtig

Der Tokenschutz befindet sich derzeit in der öffentlichen Vorschauversion. Weitere Informationen zu Vorschauen finden Sie unter "Universelle Lizenzbedingungen für Onlinedienste". Mit dieser Vorschau erhalten Sie die Möglichkeit, eine Richtlinie für bedingten Zugriff zu erstellen, um Tokenschutz für Anmeldetoken (Aktualisierungstoken) für bestimmte Dienste anzufordern. Wir unterstützen den Tokenschutz für Anmeldetoken beim bedingten Zugriff für Desktopanwendungen, die auf Windows-Geräten auf Exchange Online und SharePoint Online zugreifen.

Wichtig

Seit der ersten öffentlichen Vorschauversion wurden die folgenden Änderungen am Tokenschutz vorgenommen:

• Ausgabe der Anmeldeprotokolle: Der Wert der in "enforcedSessionControls " und "sessionControlsNotSatisfied " verwendeten Zeichenfolge wurde ende Juni 2023 von Binding zu SignInTokenProtection geändert. Abfragen für Anmeldeprotokolldaten sollten aktualisiert werden, um diese Änderung zu berücksichtigen.
• Geräte, die mit bestimmten Methoden mit Microsoft Entra verbunden sind, werden nicht mehr unterstützt. Eine vollständige Liste finden Sie im Abschnitt "Bekannte Einschränkungen ".
• Fehlercodeänderung: Der Fehlercode für den bedingten Zugriff für den Tokenschutz ändert sich von 53003 zu 530084, um Fehler im Zusammenhang mit dem Tokenschutz besser zu erkennen.
• Der Tokenschutz unterstützt jetzt die Windows-App und erweitert den Schutz auf Windows 365 und Azure Virtual Desktop.

Anforderungen

Für die Verwendung dieses Features werden Microsoft Entra ID P2-Lizenzen benötigt. Um die richtige Lizenz für Ihre Anforderungen zu finden, lesen Sie Microsoft Entra-Pläne und -Preise.

Hinweis

Die Erzwingung des Tokenschutzes ist Teil von Microsoft Entra ID Protection und erfordert Microsoft Entra ID P2-Lizenzen, wenn allgemein verfügbar.

Folgende Geräte und Anwendungen unterstützen den Zugriff auf Ressourcen, auf die eine Token-Schutz-Richtlinie für bedingten Zugriff angewendet wird.

Unterstützte Geräte:

• Geräte mit Windows 10 oder höher, die in Microsoft Entra eingebunden, in Microsoft Entra Hybrid eingebunden oder bei Microsoft Entra registriert sind. Informationen zu nicht unterstützten Gerätetypen finden Sie im Abschnitt "Bekannte Einschränkungen ".
• Windows Server 2019 oder höher, die mit Microsoft Entra hybrid verbunden sind.

Unterstützte Anwendungen:

• OneDrive-Synchronisierungsclient, Version 22.217 oder höher
• Microsoft Teams Native Client Version 1.6.00.1331 oder höher
• Power BI-Desktopversion 2.117.841.0 (Mai 2023) oder höher
• Exchange PowerShell-Modul, Version 3.7.0 oder höher
• Microsoft Graph PowerShell, Version 2.0.0 oder höher, mit der Option "EnableLoginByWAM"
• Visual Studio 2022 oder höher bei Verwendung der Anmeldeoption "Windows-Authentifizierungsbroker"
• Windows-App, Version 2.0.379.0 oder höher

Bekannte Einschränkungen

• Unbefristete Office-Clients werden nicht unterstützt.
• Die folgenden Anwendungen unterstützen die Anmeldung mit geschützten Tokenflows nicht, und Benutzer werden beim Zugriff auf Exchange und SharePoint blockiert:
  • PowerShell-Module, die auf SharePoint zugreifen
  • PowerQuery-Erweiterung für Excel
  • Erweiterungen für Visual Studio Code, die auf Exchange oder SharePoint zugreifen
• Die folgenden Windows-Clientgeräte werden nicht unterstützt:
  • Oberflächen-Hub
  • Windows-basierte Microsoft Teams-Räume (MTR)-Systeme
• Externe Benutzer , die die Anforderungen für die Tokenschutzgeräteregistrierung in ihrem Heimmandanten erfüllen, werden unterstützt. Benutzer, die diese Anforderungen nicht erfüllen, sehen jedoch eine unklare Fehlermeldung ohne Angabe der Ursache.
• Geräte, die mit der Microsoft Entra-ID mit den folgenden Methoden registriert sind, werden nicht unterstützt:
  • Microsoft Entra hat sich den Azure Virtual Desktop-Sitzungshosts angeschlossen.
  • Windows-Geräte, die mittels der Massenregistrierung bereitgestellt werden.
  • Von Windows 365 bereitgestellte Cloud-PCs, die mit Microsoft Entra verbunden sind.
  • Power Automate gehostete Maschinengruppen, die mit Microsoft Entra verbunden sind.
  • Windows Autopilot-Geräte, die mithilfe des Self-Deploying-Modus bereitgestellt werden.
  • In Azure bereitgestellte virtuelle Windows-Computer mit der Erweiterung "Virtueller Computer", die für die Microsoft Entra ID-Authentifizierung aktiviert sind.
• Neue microsoft Entra registrierte Geräte unter Windows-Versionen vor 24H2 werden möglicherweise blockiert, wenn Benutzer während der Registrierung keine neue Anmeldung durchführen. Wenn dies blockiert ist, müssen Benutzer das Gerät erneut registrieren.

Um die betroffenen Geräte aufgrund der zuvor aufgeführten nicht unterstützten Registrierungstypen zu identifizieren, prüfen Sie tokenProtectionStatusDetails das Attribut in den Anmeldeprotokollen. Tokenanforderungen, die aufgrund eines nicht unterstützten Geräteregistrierungstyps blockiert werden, können mit dem signInSessionStatusCode Wert 1003 identifiziert werden.

Um Unterbrechungen beim Onboarding neuer Mitarbeiter zu verhindern, können Sie die Richtlinie für bedingten Zugriff ändern, indem Sie eine Gerätefilterbedingung hinzufügen, die alle Geräte ausschließt, die in der zuvor beschriebenen Bereitstellungskategorie liegen. So schließen Sie beispielsweise Folgendes aus:

• Cloud-PCs, denen Microsoft Entra beigetreten ist, können Sie verwenden systemLabels -eq "CloudPC" and trustType -eq "AzureAD".
• Azure Virtual Desktops, die Microsoft Entra beigetreten sind, können Sie verwenden systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD".
• Power Automate gehostete Computergruppen, denen Microsoft Entra beigetreten ist, können Sie verwenden systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD".
• Windows Autopilot-Geräte, die im Self-Deploying-Modus bereitgestellt werden, können die enrollmentProfileName-Eigenschaft verwenden. Wenn Sie beispielsweise ein Registrierungsprofil in Intune für Ihre Autopilot-Geräte im Self-Deployment-Modus als "Autopilot Self-Deployment Profile" erstellt haben, können Sie "enrollmentProfileName" -eq "Autopilot Self-Deployment Profile" verwenden.
• Virtuelle Windows-Computer in Azure, denen Microsoft Entra beigetreten ist, können Sie verwenden profileType -eq "SecureVM" and trustType -eq "AzureAD".

Bereitstellung

Für Benutzer sollte die Bereitstellung einer Richtlinie für bedingten Zugriff zum Erzwingen des Tokenschutzes unsichtbar sein, wenn kompatible Clientplattformen auf registrierten Geräten und kompatiblen Anwendungen verwendet werden.

Um die Wahrscheinlichkeit einer Benutzerunterbrechung aufgrund der Inkompatibilität von Apps oder Geräten zu minimieren, wird dringend empfohlen:

• mit einer Pilotgruppe von Benutzern zu beginnen und diese im Laufe der Zeit zu erweitern.
• Erstellen Sie eine Richtlinie für bedingten Zugriff im Nur-Bericht-Modus , bevor Sie zur Erzwingung des Tokenschutzes wechseln.
• Erfassen Sie sowohl interaktive als auch nicht interaktive Anmeldeprotokolle.
• Diese Protokolle lang genug analysieren, um den normalen Gebrauch der Anwendung abzudecken.
• Fügen Sie einer bekannte gute Benutzer einer Erzwingungsrichtlinie hinzu.

Dieser Prozess hilft ihnen, die Client- und App-Kompatibilität Ihrer Benutzer für die Erzwingung des Tokenschutzes zu bewerten.

Erstellen Sie eine Richtlinie für bedingten Zugriff

Benutzer, die spezielle Rollen wie die in den Sicherheitsstufen für privilegierten Zugriff beschriebenen ausführen, sind mögliche Ziele für diese Funktionalität. Es wird empfohlen, mit einer kleinen Pilotgruppe zu beginnen.

Die folgenden Schritte helfen beim Erstellen einer Richtlinie für bedingten Zugriff, um Tokenschutz für Exchange Online und SharePoint Online auf Windows-Geräten anzufordern.

1. Melden Sie sich beim Microsoft Entra Admin Center als mindestens Administrator für Bedingten Zugriff an.
2. Navigieren Sie zu Entra ID-Richtlinien> fürbedingten Zugriff>.
3. Wählen Sie "Neue Richtlinie" aus.
4. Benennen Sie Ihre Richtlinie. Es wird empfohlen, dass Unternehmen einen aussagekräftigen Standard für die Namen ihrer Richtlinien erstellen.
5. Unter Assignments wählen Sie Benutzer oder Workload-Identitäten aus.
   1. Wählen Sie unter "Einschließen" die Benutzer oder Gruppen aus, die diese Richtlinie testen.
   2. Wählen Sie unter Ausschließen die Option Benutzer und Gruppen aus, und wählen Sie die Notfall- oder Breakglass-Konten Ihrer Organisation aus.
6. Unter Zielressourcen>Ressourcen (ehemals Cloud-Apps)>einschließen>Ressourcen auswählen

   1. Wählen Sie unter "Auswählen" die folgenden Anwendungen aus, die von der Vorschau unterstützt werden:

      1. Office 365 Exchange Online
      2. Office 365 SharePoint Online
      3. Wenn Sie Windows-App in Ihrer Umgebung bereitgestellt haben, schließen Sie Folgendes ein:
         1. Azure Virtual Desktop
         2. Windows 365
         3. Windows Cloud-Anmeldung

      Warnung

      Ihre Richtlinie für bedingten Zugriff sollte nur für diese Anwendungen konfiguriert werden. Das Auswählen der Office 365-Anwendungsgruppe kann zu unbeabsichtigten Fehlern führen. Diese Änderung ist eine Ausnahme von der allgemeinen Regel, dass die Office 365-Anwendungsgruppe in einer Richtlinie für bedingten Zugriff ausgewählt werden soll.

   2. Wählen Sie "Auswählen" aus.

7. Bedingungen:
   1. Unter Geräteplattformen:
      1. Legen Sie "Konfigurieren" auf "Ja" fest.
      2. Einbeziehen>Geräteplattformen auswählen>Windows.
      3. Wählen Sie "Fertig" aus.
   2. Unter Client-Apps:

      1. Legen Sie "Konfigurieren" auf "Ja" fest.

         Warnung

         Das Nichtkonfigurieren der Client-Apps-Bedingung oder das Belassen des Browsers als ausgewählt kann dazu führen, dass Anwendungen, die MSAL.jsverwenden, wie beispielsweise Teams Web, blockiert werden.

      2. Wählen Sie unter modernen Authentifizierungsclients nur mobile Apps und Desktopclients aus. Lassen Sie alle anderen Optionen deaktiviert.

      3. Wählen Sie "Fertig" aus.

8. Wählen Sie unter "Zugriffssteuerungen>Sitzung die Option "Tokenschutz für Anmeldesitzungen anfordern" aus, und wählen Sie "Auswählen" aus.
9. Bestätigen Sie Ihre Einstellungen, und legen Sie " Richtlinie aktivieren " auf "Nur Bericht" fest.
10. Wählen Sie "Erstellen" aus, um Ihre Richtlinie zu aktivieren.

Nachdem Administratoren die Richtlinieneinstellungen mithilfe des Richtlinieneffekts oder Berichtsmodus ausgewertet haben, können sie die Richtlinie aktivieren-Option von Nur Berichte auf Ein umstellen.

Tipp

Da Richtlinien für bedingten Zugriff, die tokenschutz erfordern, derzeit nur für Windows-Geräte verfügbar sind, müssen Sie Ihre Umgebung vor potenzieller Richtlinienumgehung schützen, wenn ein Angreifer möglicherweise von einer anderen Plattform stammen könnte.

Darüber hinaus sollten Sie die folgenden Richtlinien konfigurieren:

• Zugriff von unbekannten Plattformen blockieren
• Gerätecompliance für alle bekannten Plattformen erforderlich

Erfassen und Analysieren von Protokollen

Überwachen Sie die Erzwingung des Tokenschutzes vor und nach der Erzwingung mithilfe von Features wie Richtlinienwirkung (Vorschau), Anmeldeprotokolle oder Log Analytics.

Anmeldeprotokolle

Verwenden Sie das Microsoft Entra-Anmeldeprotokoll, um das Ergebnis einer Richtlinie zur Erzwingung des Tokenschutzes im Nur-Melde-Modus oder im aktivierten Modus zu überprüfen.

1. Melden Sie sich beim Microsoft Entra Admin Center als mindestens Administrator für Bedingten Zugriff an.
2. Navigieren Sie zu Entra IDÜberwachung & GesundheitSign-In-Protokollen.
3. Wählen Sie eine bestimmte Anforderung aus, um festzustellen, ob die Richtlinie angewendet wird oder nicht.
4. Wechseln Sie je nach Status zum Bereich "Bedingter Zugriff " oder " Nur Bericht" , und wählen Sie den Namen Ihrer Richtlinie aus, die den Tokenschutz erfordert.
5. Überprüfen Sie unter "Sitzungssteuerelemente", ob die Richtlinienanforderungen erfüllt wurden oder nicht.
6. Wenn Sie weitere Details zum Bindungsstatus der Anforderung finden möchten, wählen Sie den Bereich "Grundlegende Informationen " aus, und lesen Sie das Feld "Tokenschutz – Anmeldesitzung". Mögliche Werte sind:
   1. Gebunden: Die Anforderung verwendete gebundene Protokolle. Einige Anmeldungen können mehrere Anforderungen enthalten, und alle Anforderungen müssen die Tokenschutzrichtlinie erfüllen. Selbst wenn eine einzelne Anforderung gebunden erscheint, stellt sie die Einhaltung der Richtlinie nicht sicher, wenn andere Anforderungen ungebunden sind. Um alle Anforderungen für eine Anmeldung anzuzeigen, können Sie alle Anforderungen für einen bestimmten Benutzer filtern oder nach Korelationid suchen.
   2. Ungebunden: Die Anforderung verwendete keine gebundenen Protokolle. Dies ist möglich statusCodes, wenn die Anforderung ungebunden ist:
      1. 1002: Die Anforderung ist aufgrund des Fehlenden Microsoft Entra ID-Gerätezustands ungebunden.
      2. 1003: Die Anforderung ist ungebunden, da der Gerätestatus der Microsoft Entra-ID die Richtlinienanforderungen für bedingten Zugriff für den Tokenschutz nicht erfüllt. Dieser Fehler kann auf einen nicht unterstützten Geräteregistrierungstyp zurückzuführen sein, oder das Gerät wurde nicht mithilfe neuer Anmeldeinformationen registriert.
      3. 1005: Die Anforderung ist aus anderen nicht angegebenen Gründen ungebunden.
      4. 1006: Die Anforderung ist ungebunden, da die Betriebssystemversion nicht unterstützt wird.
      5. 1008: Die Anforderung ist ungebunden, da der Client nicht in den Plattformbroker integriert ist, z. B. Windows Account Manager (WAM).

Protokolldatenanalyse

Sie können log Analytics auch verwenden, um die Anmeldeprotokolle (interaktiv und nicht interaktiv) für blockierte Anforderungen aufgrund eines Tokenschutz-Erzwingungsfehlers abzufragen.

Hier ist eine Beispiel-Log Analytics-Abfrage, die die nicht interaktiven Anmeldeprotokolle für die letzten sieben Tage durchsucht und blockierte gegenüber zulässigen Anforderungen nach Anwendung hervorhebt. Diese Abfragen sind nur Beispiele und können sich ändern.

Hinweis

Ausgabe der Anmeldeprotokolle: Der Wert der in "enforcedSessionControls" und "sessionControlsNotSatisfied" verwendeten Zeichenfolge wurde ende Juni 2023 von "Binding" in "SignInTokenProtection" geändert. Abfragen für Anmeldeprotokolldaten sollten aktualisiert werden, um diese Änderung zu berücksichtigen. Die Beispiele decken beide Werte ab, um Verlaufsdaten einzuschließen.

//Per Apps query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, Status,UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]' 
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"] 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id,UserPrincipalName, AppDisplayName, Result 
| summarize Requests = count(), Users = dcount(UserPrincipalName), Block = countif(Result == "Block"), Allow = countif(Result == "Allow"), BlockedUsers = dcountif(UserPrincipalName, Result == "Block") by AppDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by Requests desc 

Das Ergebnis der vorherigen Abfrage sollte dem folgenden Screenshot ähneln:

Im folgenden Abfragebeispiel wird das nicht interaktive Anmeldeprotokoll für die letzten sieben Tage untersucht und die blockierten im Vergleich zu den zulässigen Anforderungen der Benutzer hervorgehoben.

//Per users query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies.sessionControlsNotSatisfied 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName,Result  
| summarize Requests = count(),Block = countif(Result == "Block"), Allow = countif(Result == "Allow") by UserPrincipalName, AppDisplayName,ResourceDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by UserPrincipalName asc   

Im folgenden Abfragebeispiel wird das nicht-interaktive Anmeldeprotokoll für die letzten sieben Tage untersucht, wobei Benutzer hervorgehoben werden, die Geräte verwenden, bei denen der Gerätestatus der Microsoft Entra-ID nicht den Anforderungen der Token Protection CA-Richtlinien entspricht.

AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| where TokenProtectionStatusDetails!= "" 
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails) 
| extend bindingStatus = tostring(parsedBindingDetails["signInSessionStatus"]) 
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"]) 
| where bindingStatusCode == 1003 
| summarize count() by UserPrincipalName 

Endbenutzeroberfläche

Ein Benutzer, der sein Gerät registriert oder ordnungsgemäß angemeldet hat, bemerkt keine Unterschiede beim Anmeldevorgang einer Anwendung, die den Tokenschutz unterstützt, wenn die Anforderung des Tokenschutzes aktiviert ist.

Ein Benutzer, der sein Gerät nicht registriert oder angemeldet hat, oder eine nicht unterstützte Anwendung verwendet, wird nach der Authentifizierung den folgenden Screenshot sehen, wenn die Tokenschutzanforderung aktiviert ist.

Ein Benutzer, der keine unterstützte Anwendung verwendet, wenn die Tokenschutzanforderung aktiviert ist, sieht nach der Authentifizierung den folgenden Screenshot.

Verwandte Inhalte

Was ist ein primäres Aktualisierungstoken?