Tokenskydd i Villkorsstyrd åtkomst i Microsoft Entra

Token Protection är en sessionskontroll för villkorsstyrd åtkomst som försöker minska tokenuppspelningsattacker genom att se till att endast sessionstoken för enhetsbundna inloggningar, till exempel primära uppdateringstoken (PRT) godkänns av Entra-ID när program begär åtkomst till skyddade resurser.

När en användare registrerar en Windows 10-enhet eller senare med Microsoft Entra utfärdas en PRT och är kryptografiskt bunden till den enheten. Även om en angripare stjäl en token säkerställer denna bindning att den inte kan användas från en annan enhet. När Token Protection har tvingats fram verifierar Microsoft Entra att endast dessa knutna inloggningssessionstoken används av program som stöds.

Du kan tillämpa tokenskyddsprincipen på Resurser för Exchange Online, SharePoint Online och Teams. Det stöds av många inbyggda Microsoft 365-program. En omfattande lista över program och resurser som stöds finns i avsnittet "Krav".

Requirements

För att använda den här funktionen krävs Microsoft Entra ID P1-licenser. Information om hur du hittar rätt licens för dina krav finns i Jämför allmänt tillgängliga funktioner i Microsoft Entra ID.

Följande enheter och program stöder åtkomst till resurser där en princip för villkorlig åtkomst för tokenskydd tillämpas:

Enheter som stöds

• Windows 10- eller senare enheter som är Microsoft Entra-anslutna, Microsoft Entra-hybridanslutningar eller Microsoft Entra-registrerade. Se avsnittet kända begränsningar för enhetstyper som inte stöds.
• Windows Server 2019 eller senare som är hybridanslutna till Microsoft Entra.

Program som stöds

• OneDrive-synkroniseringsklientversion 22.217 eller senare
• Teams interna klientversion 1.6.00.1331 eller senare
• Power BI Desktop version 2.117.841.0 (maj 2023) eller senare
• Exchange PowerShell-modul version 3.7.0 eller senare
• Microsoft Graph PowerShell version 2.0.0 eller senare med alternativet EnableLoginByWAM
• Visual Studio 2022 eller senare när du använder inloggningsalternativet "Windows-autentiseringskoordinator"
• Windows App version 2.0.379.0 eller senare

Följande resurser stöder tokenskydd:

• Office 365 Exchange Online
• Office 365 SharePoint Online
• Microsoft Teams-tjänster
• Virtuellt Azure-skrivbord
• Windows 365

Kända begränsningar

• Eviga Office-klienter stöds inte.
• Följande program stöder inte inloggning med hjälp av skyddade tokenflöden och användare blockeras vid åtkomst till Exchange och SharePoint:
  • PowerShell-moduler som har åtkomst till SharePoint
  • PowerQuery-tillägg för Excel
  • Tillägg till Visual Studio Code som har åtkomst till Exchange eller SharePoint
• Följande Windows-klientenheter stöds inte:
  • Surface Hub
  • Windows-baserade Microsoft Teams Rooms-system (MTR)
• Externa användare som uppfyller registreringskraven för tokenskyddsenheter i sin hemklientorganisation stöds. Användare som inte uppfyller dessa krav ser dock ett oklart felmeddelande utan någon indikation på grundorsaken.
• Enheter som registrerats med Microsoft Entra-ID med följande metoder stöds inte:
  • Microsoft Entra har anslutit sig till Azure Virtual Desktop-sessionsvärdar.
  • Windows-enheter som distribueras med massregistrering.
  • Molndatorer som distribueras av Windows 365 och är anslutna till Microsoft Entra.
  • Power Automate-värdbaserade datorgrupper som är Microsoft Entra-anslutna.
  • Windows Autopilot-enheter som distribueras med självdistribueringsläge.
  • Virtuella Windows-datorer som distribueras i Azure med hjälp av tillägget för virtuell dator (VM) som är aktiverat för Microsoft Entra-ID-autentisering.

För att identifiera de enheter som påverkas till följd av registreringstyper som inte stöds och som anges tidigare, kontrollerar du tokenProtectionStatusDetails-attributet i inloggningsloggarna. Tokenbegäranden som blockeras på grund av en enhetsregistreringstyp som inte stöds kan identifieras med värdet signInSessionStatusCode 1003.

Om du vill förhindra avbrott under registrering ändrar du principen för villkorlig åtkomst för tokenskydd genom att lägga till ett villkor för enhetsfilter som exkluderar enheter i den tidigare beskrivna distributionskategorin. Om du till exempel vill exkludera:

• Molndatorer som är Microsoft Entra-anslutna kan du använda systemLabels -eq "CloudPC" and trustType -eq "AzureAD".
• Azure Virtual Desktops som är anslutna till Microsoft Entra kan du använda systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD".
• Power Automate-värdbaserade datorgrupper som är Microsoft Entra-anslutna kan du använda systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD".
• Windows Autopilot-enheter som distribueras med självutplaceringläget kan dra nytta av egenskapen enrollmentProfileName. Om du till exempel har skapat en registreringsprofil i Intune för dina självdistributionslägesenheter för Autopilot som "Autopilot självdistributionsprofil" kan du använda `enrollmentProfileName -eq "Autopilot självdistributionsprofil".
• Virtuella Windows-datorer i Azure som är Microsoft Entra-anslutna kan du använda profileType -eq "SecureVM" and trustType -eq "AzureAD".

Deployment

För användare bör distributionen av en princip för villkorsstyrd åtkomst för att framtvinga tokenskydd vara osynlig när kompatibla klientplattformar används på registrerade enheter och kompatibla program.

Följ dessa rekommendationer för att minimera risken för användarstörningar på grund av att appen eller enheten är inkompatibel:

• Börja med en pilotgrupp med användare och expandera med tiden.
• Skapa en princip för villkorsstyrd åtkomst i rapportläge innan du framtvingar tokenskydd.
• Samla in både interaktiva och icke-interaktiva inloggningsloggar.
• Analysera loggarna tillräckligt länge för att täcka normal programanvändning.
• Lägg till kända och pålitliga användare i en verkställighetspolicy.

Den här processen hjälper dig att utvärdera användarnas klient- och appkompatibilitet för tokenskyddsframtvingande.

Skapa en princip för villkorsstyrd åtkomst

Användare som utför specialiserade roller som de som beskrivs i Säkerhetsnivåer för privilegierad åtkomst är möjliga mål för den här funktionen. Vi rekommenderar att du pilottestar med en liten delmängd för att börja.

Följande steg hjälper dig att skapa en princip för villkorlig åtkomst för att kräva tokenskydd för Exchange Online och SharePoint Online på Windows-enheter.

1. Logga in på administrationscentret för Microsoft Entra som minst administratör för villkorsstyrd åtkomst.
2. Bläddra till Entra-ID>Villkorsstyrd åtkomst>Principer.
3. Välj Ny princip.
4. Ge principen ett namn. Vi rekommenderar att organisationer skapar en meningsfull standard för namnen på sina principer.
5. Under Tilldelningar väljer du Användare eller arbetsbelastningsidentiteter.
   1. Under Inkludera väljer du de användare eller grupper som testar den här principen.
   2. Under rubriken Exkludera väljer du Användare och grupper och välj organisationens konton för nödåtkomst eller break-glass-konton.
6. Under Målresurser>Resurser (tidigare molnappar)>Inkludera>Välj resurser

   1. Under Välj väljer du följande program:

      1. Office 365 Exchange Online
      2. Office 365 SharePoint Online
      3. Microsoft Teams-tjänster
      4. Om du har distribuerat Windows App i din miljö inkluderar du:
         1. Virtuellt Azure-skrivbord
         2. Windows 365
         3. Windows Cloud-inloggning

      Warning

      Principen för villkorsstyrd åtkomst bör endast konfigureras för dessa program. Om du väljer Office 365-programgruppen kan det leda till oavsiktliga fel. Den här ändringen är ett undantag från den allmänna regeln att Office 365-programgruppen ska väljas i en princip för villkorsstyrd åtkomst.

   2. Välj Välj.

7. Under villkor:
   1. Under Enhetsplattformar:
      1. Ställ in Konfigurera på Ja.
      2. Inkludera>Välj enhetsplattformar>Windows.
      3. Välj Färdig.
   2. Under Klientappar:

      1. Ställ in Konfigurera på Ja.

         Warning

         Om du inte konfigurerar villkoret Klientappar eller om webbläsaren är vald kan det leda till att program som använder MSAL.js, till exempel Teams Web, blockeras.

      2. Under Moderna autentiseringsklienter väljer du endast Mobilappar och skrivbordsklienter. Lämna andra objekt avmarkerade.

      3. Välj Färdig.

8. Under Åtkomstkontroller>Session väljer du Kräv tokenskydd för inloggningssessioner och väljer Välj.
9. Bekräfta dina inställningar och ändra Aktivera policyn till Endast rapportläge.
10. Välj skapa för att aktivera policyn.

När du har bekräftat dina inställningar med hjälp av princippåverkan eller rapportläge flyttar du växlingsknappen Aktivera princip från Endast rapport till På.

Samla in loggar och analysera

Övervaka tillämpning av villkorlig åtkomst för tokenskydd före och efter tillämpning med hjälp av funktioner som princippåverkan, inloggningsloggar och Log Analytics.

Inloggningsloggar

Använd Inloggningsloggen för Microsoft Entra för att verifiera resultatet av en princip för tvingande tokenskydd i rapportläge eller i aktiverat läge.

1. Logga in på administrationscentret för Microsoft Entra som minst administratör för villkorsstyrd åtkomst.
2. Bläddra till Entra ID Övervakning & hälsa Inloggningsloggar.
3. Välj en specifik begäran för att avgöra om principen tillämpas eller inte.
4. Gå till fönstret Villkorlig åtkomst eller Endast rapportering beroende på dess tillstånd och välj namnet på den policy som kräver tokenskydd.
5. Under Sessionskontroller kontrollerar du om principkraven var uppfyllda eller inte.
6. Om du vill ha mer information om bindningstillståndet för begäran väljer du fönstret Grundläggande information och läser fältet Tokenskydd – Inloggningssession. Möjliga värden är:
   1. Bunden: begäran använde bundna protokoll. Vissa inloggningar kan innehålla flera begäranden och alla begäranden måste vara bundna för att uppfylla tokenskyddsprincipen. Även om en enskild begäran verkar vara bunden ser den inte till att principen efterlevs om andra begäranden är obundna. Om du vill se alla begäranden om en inloggning kan du filtrera alla begäranden för en viss användare eller titta efter corelationid.
   2. Obundet: begäran använde inte bundna protokoll. Möjliga statusCodes när en begäran är obunden är:
      1. 1002: Begäran är avbunden på grund av bristen på enhetstillstånd för Microsoft Entra-ID.
      2. 1003: Begäran är obundet eftersom Enhetstillståndet för Microsoft Entra-ID inte uppfyller principkraven för villkorsstyrd åtkomst för tokenskydd. Det här felet kan bero på en enhetsregistreringstyp som inte stöds eller på att enheten inte har registrerats med nya inloggningsuppgifter.
      3. 1005: Begäran är obunden av andra ospecificerade skäl.
      4. 1006: Begäran är obunden eftersom OS-versionen inte stöds.
      5. 1008: Begäran är obunden eftersom klienten inte är integrerad med plattformens mellanhand, till exempel Windows Account Manager (WAM).

Log Analytics

Du kan också använda Log Analytics för att fråga inloggningsloggarna (interaktiva och icke-interaktiva) om blockerade begäranden på grund av tokenskyddsfel.

Här är ett exempel på en Log Analytics-fråga som söker i loggarna för icke-interaktiv inloggning under de senaste sju dagarna och som markerar Blockerade och Tillåtna begäranden av programmet. Dessa frågor är bara exempel och kan komma att ändras.

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

Resultatet av föregående fråga bör likna följande skärmbild:

I följande frågeexempel tittar vi på den icke-interaktiva inloggningsloggen för de senaste sju dagarna och markerar Blockerad jämfört med Tillåtna begäranden av användare.

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

Följande frågeexempel undersöker den icke-interaktiva inloggningsloggen för de senaste sju dagarna och markerar användare som använder enheter där Microsoft Entra ID-enhetstillståndet inte uppfyller CA-principerna för tokenskydd.

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 

Slutanvändarupplevelse

En användare som har registrerat eller anmält sin enhet som stöds upplever inga skillnader i inloggningsupplevelsen i ett program som har stöd för tokenskydd när tokenskyddskravet är aktiverat.

En användare som inte har registrerat eller registrerat sin enhet och om tokenskyddsprincipen är aktiverad visas följande skärmbild efter autentiseringen.

En användare som inte använder ett program som stöds när tokenskyddsprincipen är aktiverad ser följande skärmbild efter autentisering.

Relaterat innehåll

Vad är en primär uppdateringstoken?