Tokenschutz in bedingtem Microsoft Entra-Zugriff

Der Tokenschutz ist ein Sitzungssteuerelement für bedingten Zugriff, das versucht, Token-Replay-Angriffe zu reduzieren, indem sichergestellt wird, dass nur gerätegebundene Anmeldesitzungstoken wie primäre Aktualisierungstoken (PRIMARY Refresh Tokens, PRTs) von Entra-ID akzeptiert werden, wenn Anwendungen zugriff auf geschützte Ressourcen anfordern.

Wenn ein Benutzer ein Windows 10- oder höher-Gerät bei Microsoft Entra registriert, wird ein PRT ausgestellt und kryptografisch an dieses Gerät gebunden. Diese Bindung stellt sicher, dass auch dann, wenn ein Bedrohungsakteur ein Token gestohlen, nicht von einem anderen Gerät verwendet werden kann. Mit erzwungener Tokenschutz überprüft Microsoft Entra, dass nur diese gebundenen Anmeldesitzungstoken von unterstützten Anwendungen verwendet werden.

Sie können die Tokenschutzrichtlinie für Exchange Online-, SharePoint Online- und Teams-Ressourcen erzwingen. Es wird von vielen nativen Microsoft 365-Anwendungen unterstützt. Eine umfassende Liste der unterstützten Anwendungen und Ressourcen finden Sie im Abschnitt "Anforderungen".

Requirements

Die Verwendung dieses Features erfordert Microsoft Entra ID P1-Lizenzen. Informationen zur richtigen Lizenz für Ihre Anforderungen finden Sie unter Vergleich der allgemein verfügbaren Features von Microsoft Entra ID.

Die folgenden Geräte und Anwendungen unterstützen den Zugriff auf Ressourcen, bei denen eine Richtlinie für den bedingten Zugriff auf Tokenschutz 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

Die folgenden Ressourcen unterstützen den Tokenschutz:

• Office 365Exchange Online
• Office 365 SharePoint Online
• Microsoft Teams-Dienste
• Azure Virtual Desktop
• Windows 365

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:
  • Surface Hub
  • Windows-basierte Microsoft Teams-Räume (MTR)-Systeme
• Externe Benutzer, die die Anforderungen für die Token-Schutzgeräteregistrierung in ihrem Heim-Mandanten 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 ist jetzt Teil der Azure Virtual Desktop-Sitzungshosts.
  • Windows-Geräte, die mithilfe der Massenregistrierungbereitgestellt werden.
  • Cloud PCs, die von Windows 365 bereitgestellt werden und die Microsoft Entra angeschlossen sind.
  • Power Automate gehostete Computergruppen, denen Microsoft Entra beigetreten ist.
  • 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.

Um die betroffenen Geräte aufgrund der zuvor aufgeführten nicht unterstützten Registrierungstypen zu identifizieren, überprüfen Sie das tokenProtectionStatusDetails 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 während des Onboardings zu verhindern, ändern Sie die Richtlinie für den bedingten Zugriff durch Hinzufügen einer Gerätefilterbedingung, die Geräte in der zuvor beschriebenen Bereitstellungskategorie ausschließt. 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 Modus der Selbstbereitstellung bereitgestellt werden, können Sie die Eigenschaft enrollmentProfileName 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".

Deployment

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.

Befolgen Sie die folgenden Empfehlungen, um die Wahrscheinlichkeit von Benutzerunterbrechungen aufgrund von App- oder Geräteinkompatibilität zu minimieren:

• Beginnen Sie mit einer Pilotgruppe von Benutzern, und erweitern Sie sie im Laufe der Zeit.
• Erstellen Sie eine Richtlinie für bedingten Zugriff im Modus "Nur Bericht ", bevor Sie den Tokenschutz erzwingen.
• Erfassen Sie interaktive und nicht interaktive Anmeldeprotokolle.
• Analysieren Sie diese Protokolle lang genug, um die normale Anwendungsverwendung abzudecken.
• Fügen Sie bekannte, zuverlässige Benutzer zu einer Erzwingungsrichtlinie hinzu.

Dieser Prozess hilft bei der Bewertung der Client- und App-Kompatibilität Ihrer Benutzer für die Erzwingung des Tokenschutzes.

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 Ihnen beim Erstellen einer Richtlinie für bedingten Zugriff, um Tokenschutz für Exchange Online und SharePoint Online auf Windows-Geräten zu erfordern.

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.
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 und dann die Notfallzugriffs- oder "Break-Glass"-Konten Ihres Unternehmens aus.
6. Unter Zielressourcen>Ressourcen (ehemals Cloud-Apps)>Einschließen>Gewählte Ressourcen

   1. Wählen Sie unter "Auswählen" die folgenden Anwendungen aus:

      1. Office 365Exchange Online
      2. Office 365 SharePoint Online
      3. Microsoft Teams-Dienste
      4. 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

      Warning

      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. Klicken Sie auf Auswählen.

7. Unter 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.

         Warning

         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 Zugriffssteuerung>Sitzung die Option Tokenschutz für Anmeldesitzungen erforderlich aus, und klicken Sie auf Auswählen.
9. Bestätigen Sie Ihre Einstellungen und legen Sie Richtlinie aktivieren auf Nur Berichten fest.
10. Wählen Sie "Erstellen" aus, um Ihre Richtlinie zu aktivieren.

Nachdem Sie Ihre Einstellungen mithilfe des Richtlinieneffekts oder berichtsgeschützten Modus bestätigt haben, verschieben Sie den Umschalter "Richtlinie aktivieren " von " Nur Bericht " auf "Ein".

Erfassen und Analysieren von Protokollen

Überwachen Sie die Erzwingung des Tokenschutzes vor und nach der Erzwingung mithilfe von Features wie Richtlinienwirkungen, Anmeldeprotokollen und 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 melden, und wählen Sie den Namen Ihrer Richtlinie aus, die Tokenschutz erfordert.
5. Überprüfen Sie unter Sitzungssteuerungen, ob die Richtlinienanforderungen erfüllt waren 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).

Log Analytics

Sie können auch Log Analytics verwenden, um die Anmeldeprotokolle (interaktiv und nicht interaktiv) für blockierte Anforderungen aufgrund eines Fehlers bei der Tokenschutzerzwingung abzufragen.

Im Folgenden finden Sie eine Log Analytics-Beispielabfrage, die die nicht interaktiven Anmeldeprotokolle der letzten sieben Tage durchsucht, wobei blockierte und zulässige Anforderungen nach Anwendung hervorgehoben werden. Diese Abfragen sind nur Beispiele und können sich ändern.

//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 der letzten sieben Tage untersucht, wobei blockierte und zulässige Anforderungen nach Benutzer hervorgehoben werden.

//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 

Endbenutzererfahrung

Ein Benutzer, der sein unterstütztes Gerät registriert oder registriert hat, hat keine Unterschiede bei der Anmeldeerfahrung bei einer unterstützten Tokenschutzanwendung, wenn die Tokenschutzanforderung aktiviert ist.

Ein Benutzer, der sein Gerät nicht registriert oder registriert hat und wenn die Tokenschutzrichtlinie aktiviert ist, sieht den folgenden Screenshot nach der Authentifizierung.

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

Verwandte Inhalte

Was ist ein primäres Aktualisierungstoken?