Distributionsguide för Token Protection – Webbappar (förhandsversion)

Den här guiden beskriver de steg som krävs för att distribuera och framtvinga tokenskydd för inloggningssessionstoken som används av webbprogram (webbläsarbaserade) som har åtkomst till Azure Resource Manager (ARM).

En översikt över tokenskydd och plattformar som stöds finns i Token Protection i Microsoft Entra villkorlig åtkomst. Granska översiktsdokumentationen innan du använder den här distributionsguiden.

Förutsättningar

För att använda den här funktionen krävs Microsoft Entra ID P1-licenser. För att hitta rätt licens för dina krav, se Jämför allmänt tillgängliga funktioner i Microsoft Entra ID.

Program, resurser och webbläsare som stöds

Ansökningar

• Azure portal
• administrationscenter för Microsoft Intune
• Administrationscenter för Microsoft Entra
• Microsoft Engage Center
• Microsoft Engage Hub

Endast de föregående webbprogrammen stöds. Användarnas åtkomst till andra webbprogram som har åtkomst till ARM blockeras när principen tillämpas. De vanligaste webbprogrammen som har åtkomst till ARM men som inte stöds inkluderar, men är inte begränsade till:

• Säkerhets- och efterlevnadscenter för Microsoft 365
• Microsoft AppSource
• Azure Data Factory
• Azure AI Studio-app
• Azure Synapse Studio
• Microsoft Power BI
• Microsoft Developer Portal
• Azure OpenAI Studio
• Administrationscenter för Power Platform

Resurser som stöds

• Azure Resource Manager (ARM) som konfigurerats i villkorsstyrd åtkomst som Windows Azure SERVICE Management API-resurs.

Plattformar och webbläsare som stöds

¹ Vissa enhetsregistreringstyper stöds inte. Se listan över enhetsregistreringstyper som inte stöds.

Aktivera tokenskydd för ARM på Windows och macOS

Följ dessa rekommendationer för att minimera risken för användarstörningar på grund av inkompatibilitet mellan appar, webbläsare eller enheter:

• Börja med en pilotgrupp med användare och expandera med tiden.
• Skapa en princip för villkorlig åtkomst för tokenskydd i rapportläge innan du framtvingar den.
• Samla in både interaktiva och icke-interaktiva inloggningsloggar.
• Analysera loggarna tillräckligt länge för att täcka normal programanvändning. Instruktioner för att analysera och förstå användarpåverkan beskrivs i följande avsnitt.
• Lägg till kända, tillförlitliga användare i en användargrupp och tillämpa principen.

Den här processen hjälper dig att utvärdera användarnas beredskap för tokenskyddsframtvingande.

Steg 1: Konfigurera slutanvändarenheter

Slutför följande på varje enhet manuellt eller via grupprincip eller Intune.

Windows

1. Kontrollera att enheten körs Windows 11 version 26100.8246 /26200.8246 eller senare.

2. Aktivera den här förhandsversionen genom att ange följande registervärde:

   [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\BrowserCore]
   "EnablePlatformAuth"=dword:00000001
   

3. Installera webbläsartillägget Microsoft single Sign-On:

   • Google Chrome: Installera Microsoft enkel inloggning från Chrome Web Store, välj Lägg till i Chrome>Lägg till tillägg och bekräfta att det visas i verktygsfältet.
   • Microsoft Edge: Gå till edge://extensions, aktivera Tillåt tillägg från andra butiker, installera tillägget Microsoft enkel inloggning och bekräfta att det är aktiverat.

macOS

1. Installera Microsoft Company Portal eller distribuera den via din MDM-lösning. Company Portal fungerar som autentiseringskoordinator för Microsoft Entra inloggningar.
2. Aktivera maskinvarubaserad registrering med något av följande alternativ:
   • Alternativ A: Aktivera plugin-programmet Microsoft Enterprise SSO.
   • Alternativ B: Konfigurera plattforms-SSO för macOS. Plattforms-SSO använder maskinvarubaserad lagring som standard och kräver ingen extra flaggkonfiguration. Installationsinstruktioner finns i Konfigurera plattforms-SSO för macOS-enheter i Microsoft Intune.
3. Installera webbläsartillägget Microsoft enkel inloggning i Microsoft Edge eller Google Chrome enligt beskrivningen i föregående Windows avsnitt.

Vad du kan förvänta dig efter steg 1

När enheten uppfyller kraven och konfigurationen sprids slutar autentiseringsbegäranden från program och webbläsare som stöds att slutföras helt i webbläsaren och hanteras i stället av plattformsautentiseringskoordinatorn. Det här är det som gör att dessa program kan använda enhetsbundna inloggningssessionstoken, till exempel primära uppdateringstoken (PRT) och uppfylla principen för villkorlig åtkomst för tokenskydd.

Planera för följande:

• Tillåt minst 24 timmar innan ändringen börjar gälla. Växlingen till koordinatorbaserad autentisering sker inte omedelbart efter att registervärdet, tillägget eller plattformsprofilen för enkel inloggning har tillämpats. Flytta inte till steg 2 förrän det här fönstret har passerat, eller så visar dina rapportdata inte beredskapen korrekt.
• Övergången är automatisk i de flesta fall. Användare vidtar vanligtvis ingen åtgärd. befintliga webbläsarsessioner fortsätter att fungera medan ändringen sprids.
• Vissa användare ser en kort inloggningsdialogruta. Under förhandsversionen kan användare som kommer åt Azure-portalen kort se en "Logga in dig... " meddelande om att ett nytt fönster öppnas. Inget nytt fönster visas och ingen användaråtgärd krävs och inloggningen slutförs på egen hand. Du kan också kommunicera det här beteendet med pilotgruppen i förväg så att det inte rapporteras som ett fel.

Steg 2: Skapa principen för villkorsstyrd åtkomst i rapportläge

När du väntar 24 timmar efter att du har slutfört steg 1 kan du fortsätta att ange en princip i rapportläge för att granska efterlevnadsberedskapen.

1. Logga in på Microsoft Entra administrationscenter som minst en administratör för villkorsstyrd åtkomst.
2. Bläddra till Entra ID>Villkorliga åtkomstprinciper> och välj sedan Ny princip och ge den ett namn.
3. Under Tilldelningar>Användare, inkludera dina pilot- eller testanvändare. Inkludera inte organisationens konton för nödåtkomst eller brytglas.
4. Under Målresurser>Resurser (tidigare molnappar)>Inkludera>Välj resurser väljer du Windows Azure Service Management API.
5. Under Villkor>Enhetsplattformar anger du Konfigurera till Ja och inkluderar Windows, macOS eller båda.
6. UnderVillkorsklientappar> anger du Konfigurera till Ja och inkluderar Webbläsare. Se till att du inte väljer Mobilappar och skrivbordsklienter för den här förhandsversionen.
7. Under Åtkomstkontroller>Session väljer du Kräv tokenskydd för inloggningssessioner och väljer sedan Välj.
8. Ställ in Aktivera policy på Endast rapport och välj Skapa.

Steg 3: Granska beredskapen för tillämpning med loggar och mått

När policyn endast för rapporter har implementerats och är i drift bör du granska Policykonsekvenser, analysera dina sign-in-loggar och undersöka med Log Analytics för att granska efterlevnadsberedskapen.

Inloggningsloggar

Så här visar du tokenskyddsrelaterade inloggningshändelser i administrationscentret:

1. Logga in på Microsoft Entra administrationscenter som minst en Administratör för Villkorsstyrd Åtkomst.
2. Bläddra till Entra ID>Övervakning och hälsa>Inloggningsloggar.
3. Lägg till kolumnen Token Protection – statuskod för inloggningssession i vyn för att snabbt se relaterade inloggningshändelser. Filtrera även efter resursen Azure Resource Manager och ange Klientapp till Webbläsare för att isolera inloggningsbegäranden som är relaterade till den här förhandsversionen.
4. Välj den inloggningshändelse som du undersöker.
5. Granska flikarna Villkorlig åtkomst och Endast rapport , beroende på principtillståndet, och välj din tokenskyddsprincip.
6. Under Sessionskontroller kontrollerar du om principkraven har uppfyllts.
7. Välj fliken Grundläggande information och kontrollera fältet Tokenskydd – inloggningssession för mer information.

Inloggningsloggarna innehåller en tokenProtectionStatusDetails egenskap som anger om en begäran använder en enhetsbunden token:

"tokenProtectionStatusDetails": {
  "signInSessionStatus": "bound | unbound",
  "signInSessionStatusCode": <code>
}

Statuskoder för inloggningssession

Information om varför en begäran visas som obundna eller för att identifiera vilka användare du kan tillämpa principen på finns i följande statuskoder.

Identifiera självreparerbara användare (endast macOS)

På macOS kan koderna 1003 och 1004 repareras själv via en engångsuppgradering av enhetsregistrering.

Om du vill identifiera begäranden som är kompatibla eller uppgraderingsbara med användaråtgärder filtrerar du efter:

• signInSessionStatus == bound, eller
• signInSessionStatus == unbound med signInSessionStatusCode av 1003 eller 1004.

Exempel på Microsoft Graph fråga för icke-interaktiva inloggningar:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=(
  signInEventTypes/any(t: t eq 'nonInteractiveUser')
  and resourceDisplayName eq 'Azure Resource Manager'
  and (tokenProtectionStatusDetails/signInSessionStatusCode eq 1003
    or tokenProtectionStatusDetails/signInSessionStatusCode eq 1004
    or tokenProtectionStatusDetails/signInSessionStatus eq 'bound'))

När tokenskydd tillämpas för dessa användare uppmanas de att logga in igen och kan komma åt resurser när de har slutfört autentiseringen.

Logganalys

Du kan också använda Log Analytics för att fråga interaktiva och icke-interaktiva inloggningsloggar för begäranden som blockerats på grund av tokenskyddsfel. Dessa frågor är endast exempel och kan komma att ändras. De filtrerar på den Azure Resource Manager resursen och lägger till beredskapsmått så att du kan skilja hårda block från självreparabla.

Begäranden per applikation

Följande exempelfråga söker i loggarna för icke-interaktiv inloggning under de senaste sju dagarna, markerar blockerade och tillåtna begäranden till ARM efter program och flaggor som användarna kan åtgärda själv. Växla in SigninLogs för att granska interaktiva webbläsarinloggningar i stället.

// Select the log to query (SigninLogs or AADNonInteractiveUserSignInLogs)
// SigninLogs
AADNonInteractiveUserSignInLogs
// Adjust the time range below
| where TimeGenerated > ago(7d)
| project Id, ConditionalAccessPolicies, Status, UserPrincipalName, AppDisplayName,
    ResourceDisplayName, TokenProtectionStatusDetails
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName == "Azure Resource Manager"
// Add UserPrincipalName if you want to filter to a specific user
// | 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 'Binding', 'Block', 'Allow')
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails)
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"])
| extend IsSelfRemediable = Result == "Block"
    and (bindingStatusCode == "1003" or bindingStatusCode == "1004")
| summarize by Id, UserPrincipalName, AppDisplayName, Result, IsSelfRemediable
| summarize Requests = count(),
    Users = dcount(UserPrincipalName),
    Allow = countif(Result == "Allow"),
    Block = countif(Result == "Block"),
    BlockSelfRemediable = countif(IsSelfRemediable == true),
    BlockedUsers = dcountif(UserPrincipalName, Result == "Block"),
    BlockedUsersSelfRemediable = dcountif(UserPrincipalName, IsSelfRemediable == true)
    by AppDisplayName
| extend PctAllowed = round(100.0 * Allow / (Allow + Block), 2)
| extend PctEnforceable = round(100.0 * (Allow + BlockSelfRemediable) / (Allow + Block), 2)
| project AppDisplayName, Requests, Users, Allow, Block,
    BlockSelfRemediable, BlockedUsers, BlockedUsersSelfRemediable,
    PctAllowed, PctEnforceable
| sort by Requests desc

Begäranden efter användare

Följande fråga tittar på loggarna för icke-interaktiv inloggning under de senaste sju dagarna och markerar blockerade och tillåtna begäranden till ARM av användaren, med samma självreparabla och verkställbara mått.

// Per-user query for the Azure portal -> ARM web app scenario
// SigninLogs
AADNonInteractiveUserSignInLogs
// Adjust the time range below
| where TimeGenerated > ago(7d)
| project Id, ConditionalAccessPolicies, UserPrincipalName, AppDisplayName,
    ResourceDisplayName, TokenProtectionStatusDetails
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName == "Azure Resource Manager"
// Add UserPrincipalName if you want to filter to a specific user
// | 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 'Binding', 'Block', 'Allow')
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails)
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"])
| extend IsSelfRemediable = Result == "Block"
    and (bindingStatusCode == "1003" or bindingStatusCode == "1004")
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName, Result, IsSelfRemediable
| summarize Requests = count(),
    Allow = countif(Result == "Allow"),
    Block = countif(Result == "Block"),
    BlockSelfRemediable = countif(IsSelfRemediable == true)
    by UserPrincipalName, AppDisplayName, ResourceDisplayName
| extend PctAllowed = round(100.0 * Allow / (Allow + Block), 2)
| extend PctEnforceable = round(100.0 * (Allow + BlockSelfRemediable) / (Allow + Block), 2)
| project UserPrincipalName, AppDisplayName, ResourceDisplayName,
    Requests, Allow, Block, BlockSelfRemediable,
    PctAllowed, PctEnforceable
| sort by UserPrincipalName asc

Steg 4: Framtvinga principen

När du har granskat inloggningsloggdata och bekräftat att dina målanvändare och enheter är klara flyttar du växlingsknappen Aktivera princip från Endast rapport till På.

Relaterat innehåll

• Tokenskydd i Villkorsstyrd åtkomst i Microsoft Entra
• Distributionsguide för Token Protection – Windows
• Distributionsguide för Token Protection – Apple-plattformar
• Vad är en primär uppdateringstoken?