Voorwaardelijke toegang van Microsoft Entra: Beveiliging van tokens (preview)

2025-05-27

Tokenbeveiliging (ook wel tokenbinding genoemd in de branche) probeert aanvallen met behulp van tokendiefstal te verminderen door ervoor te zorgen dat een token alleen kan worden gebruikt vanaf het beoogde apparaat. Wanneer een aanvaller een token kan stelen door een token te kapen of opnieuw af te spelen, kunnen ze hun slachtoffer imiteren totdat het token verloopt of wordt ingetrokken. Tokendiefstal wordt beschouwd als een relatief zeldzame gebeurtenis, maar de schade van het kan aanzienlijk zijn.

Met tokenbeveiliging wordt een cryptografisch veilige koppeling gemaakt tussen het token en het apparaat (clientgeheim) waarnaar het wordt uitgegeven. Zonder het clientgeheim is het afhankelijke token nutteloos. Wanneer een gebruiker een Windows 10- of hoger apparaat in Microsoft Entra ID registreert, is de primaire identiteit gebonden aan het apparaat. Wat dit betekent: een beleid kan ervoor zorgen dat alleen afhankelijke aanmeldingssessietokens (of vernieuwingstokens), ook wel primaire vernieuwingstokens (PRT's genoemd) worden gebruikt door toepassingen bij het aanvragen van toegang tot een resource.

Belangrijk

Tokenbeveiliging is momenteel in openbare preview. Zie Universele licentievoorwaarden voor onlineservices voor meer informatie over previews. Met deze preview kunt u een beleid voor voorwaardelijke toegang maken om tokenbeveiliging te vereisen voor aanmeldingstokens (vernieuwingstokens) voor specifieke services. We ondersteunen tokenbeveiliging voor aanmeldingstokens in voorwaardelijke toegang voor bureaubladtoepassingen die toegang hebben tot Exchange Online en SharePoint Online op Windows-apparaten.

Belangrijk

De volgende wijzigingen zijn aangebracht in Token Protection sinds de eerste openbare preview-versie:

Uitvoer van aanmeldingslogboeken: De waarde van de tekenreeks die wordt gebruikt in enforcedSessionControls en sessionControlsNotSatisfied is eind juni 2023 veranderd van Binding in SignInTokenProtection . Query's voor aanmeldingslogboekgegevens moeten worden bijgewerkt om deze wijziging weer te geven.
Apparaten die zijn toegevoegd aan Microsoft Entra met behulp van bepaalde methoden, worden niet meer ondersteund. Zie de sectie bekende beperkingen voor een volledige lijst.
Foutcodewijziging: de foutcode van het beleid voor voorwaardelijke toegang voor tokenbeveiliging verandert van 53003 in 530084 om fouten met betrekking tot tokenbeveiliging beter te identificeren.
Tokenbeveiliging ondersteunt nu de Windows-app, waardoor de beveiliging wordt uitgebreid naar Windows 365 en Azure Virtual Desktop.

Schermopname van een beleid voor voorwaardelijke toegang dat tokenbeveiliging vereist als sessiebeheer.

Behoeften

Voor het gebruik van deze functie zijn Microsoft Entra ID P2-licenties vereist. Zie Microsoft Entra-abonnementen en -prijzenom de juiste licentie voor uw vereisten te vinden.

Notitie

Afdwingen van tokenbeveiliging maakt deel uit van Microsoft Entra ID Protection en vereist Microsoft Entra ID P2-licenties voor algemene beschikbaarheid.

De volgende apparaten en toepassingen ondersteunen toegang tot resources waarop beleid voor voorwaardelijke toegang voor tokenbeveiliging wordt toegepast:

Ondersteunde apparaten:

Windows 10- of nieuwere apparaten die zijn toegevoegd aan Microsoft Entra, Microsoft Entra hybride gekoppeld of Microsoft Entra geregistreerd. Zie de sectie bekende beperkingen voor niet-ondersteunde apparaattypen.
Windows Server 2019 of nieuwer die hybride gekoppeld zijn met Microsoft Entra.

Ondersteunde toepassingen:

OneDrive-synchronisatieclient versie 22.217 of hoger
Teams-natieve client versie 1.6.00.1331 of nieuwer
Power BI Desktop versie 2.117.841.0 (mei 2023) of hoger
Exchange PowerShell-moduleversie 3.7.0 of hoger
Microsoft Graph PowerShell versie 2.0.0 of hoger met de optie EnableLoginByWAM
Visual Studio 2022 of hoger bij het gebruik van de aanmeldingsoptie 'Windows Authentication Broker'
Windows-app versie 2.0.379.0 of hoger

Bekende beperkingen

Permanente Office-clients worden niet ondersteund.
De volgende toepassingen bieden geen ondersteuning voor aanmelden met beveiligde tokenstromen en gebruikers worden geblokkeerd bij toegang tot Exchange en SharePoint:
- PowerShell-modules die toegang hebben tot SharePoint
- PowerQuery-extensie voor Excel
- Extensies voor Visual Studio Code die toegang hebben tot Exchange of SharePoint
De volgende Windows-clientapparaten worden niet ondersteund:
- Surface Hub (interactief display van Microsoft)
- MTR-systemen (Windows-gebaseerde Microsoft Teams-ruimten)
Externe gebruikers die voldoen aan de vereisten voor apparaatregistratie voor tokenbeveiliging in hun thuistenant, worden ondersteund. Gebruikers die niet aan deze vereisten voldoen, zien echter een onduidelijk foutbericht zonder indicatie van de hoofdoorzaak.
Apparaten die zijn geregistreerd bij Microsoft Entra ID met behulp van de volgende methoden, worden niet ondersteund:
- Microsoft Entra heeft zich aangesloten bij Azure Virtual Desktop-sessiehosts.
- Windows-apparaten die zijn geïmplementeerd met bulkinschrijving.
- Cloud-pc's die door Windows 365 zijn geïmplementeerd en zijn toegevoegd aan Microsoft Entra.
- Door Power Automate gehoste machinegroepen die lid zijn van Microsoft Entra.
- Windows Autopilot-apparaten die zijn geïmplementeerd met behulp van de zelf-implementatiemodus.
- Virtuele Windows-machines die zijn geïmplementeerd in Azure met behulp van de vm-extensie (virtuele machine) die zijn ingeschakeld voor Microsoft Entra ID-verificatie.
Nieuwe door Microsoft Entra geregistreerde apparaten in Windows-versies vóór 24H2 kunnen worden geblokkeerd als gebruikers geen nieuwe aanmelding uitvoeren tijdens de registratie. Als het geblokkeerd is, moeten gebruikers het apparaat opnieuw registreren.

Om de betrokken apparaten te identificeren door de niet-ondersteunde registratietypen die eerder zijn vermeld, inspecteert u het tokenProtectionStatusDetails-kenmerk in de aanmeldingslogboeken. Tokenaanvragen die worden geblokkeerd vanwege een niet-ondersteund apparaatregistratietype, kunnen worden geïdentificeerd met de signInSessionStatusCode waarde 1003.

Als u onderbrekingen voor nieuwe onboarding wilt voorkomen, kunt u het beleid voor voorwaardelijke toegang voor tokenbeveiliging wijzigen door een apparaatfiltervoorwaarde toe te voegen die alle apparaten uitsluit die in de eerder beschreven implementatiecategorie vallen. Als u bijvoorbeeld het volgende wilt uitsluiten:

Cloud-pc's die lid zijn van Microsoft Entra, kunt u gebruiken systemLabels -eq "CloudPC" and trustType -eq "AzureAD".
Azure Virtual Desktops die met Microsoft Entra verbonden zijn, kunt u systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD" gebruiken.
Machinegroepen die door Power Automate gehost worden en met Microsoft Entra zijn gekoppeld, kunt u gebruiken systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD".
Windows Autopilot-apparaten die zijn geïmplementeerd met de zelfuitrolmodus, dan kunt u de eigenschap enrollmentProfileName gebruiken. Als u bijvoorbeeld een inschrijvingsprofiel in Intune hebt gemaakt voor uw autopilot-apparaten in de modus voor zelfimplementatie als 'Autopilot-profiel voor zelfimplementatie', kunt u enrollmentProfileName -eq 'Autopilot-profiel voor zelfimplementatie' gebruiken.
U kunt Windows-virtuele machines in Azure die zijn toegevoegd aan Microsoft Entra, gebruiken met profileType -eq "SecureVM" and trustType -eq "AzureAD".

Implementatie

Voor gebruikers moet de implementatie van beleid voor voorwaardelijke toegang om tokenbeveiliging af te dwingen onzichtbaar zijn bij het gebruik van compatibele clientplatforms op geregistreerde apparaten en compatibele toepassingen.

We raden u ten zeerste aan om de kans op gebruikersonderbreking vanwege incompatibiliteit van apps of apparaten te minimaliseren:

Begin met een testgroep van gebruikers en vouw in de loop van de tijd uit.
Maak een beleidsregel voor voorwaardelijke toegang in alleen-rapportagemodus voordat u overgaat op het afdwingen van beveiliging van tokens.
Leg zowel interactieve als niet-interactieve aanmeldingslogboeken vast.
Analyseer deze logboeken lang genoeg om normaal gebruik van toepassingen te dekken.
Vertrouwde gebruikers toevoegen aan een beleidsregel voor handhaving.

Dit proces helpt bij het beoordelen van de compatibiliteit van de client en app van uw gebruikers voor het afdwingen van tokenbeveiliging.

Beleid voor voorwaardelijke toegang maken

Gebruikers die gespecialiseerde rollen uitvoeren, zoals die worden beschreven in beveiligingsniveaus voor bevoegde toegang , zijn mogelijke doelen voor deze functionaliteit. We raden u aan om te beginnen met een kleine deelgroep.

De stappen die volgen bij het maken van een beleid voor voorwaardelijke toegang om tokenbeveiliging voor Exchange Online en SharePoint Online op Windows-apparaten te vereisen.

Meld u aan bij het Microsoft Entra-beheercentrum als minimaal een Administrator voor voorwaardelijke toegang.
Blader naar Entra ID>Voorwaardelijke Toegang>Beleid.
Selecteer Nieuw beleid.
Geef uw beleid een naam. We raden organisaties aan een zinvolle standaard te maken voor de namen van hun beleidsregels.
Onder Toewijzingen, selecteer gebruikers of workload identiteiten.
1. Selecteer onder Opnemen de gebruikers of groepen die dit beleid testen.
2. Selecteer onder UitsluitenGebruikers en groepen en kies de noodtoegangs- of break-glass-accounts van uw organisatie.
Onder Doelresources>Resources (voorheen cloud-apps)>Omvat>Selecteer resources
1. Selecteer onder Selecteren de volgende toepassingen die door de preview worden ondersteund:
  1. Office 365 Exchange Online
  2. Office 365 SharePoint Online
  3. Als u de Windows App in uw omgeving hebt geïmplementeerd, neemt u het volgende op:
    1. Azure Virtual Desktop
    2. Windows 365
    3. Aanmelding bij Windows Cloud
  Waarschuwing
  
  Uw beleid voor voorwaardelijke toegang mag alleen worden geconfigureerd voor deze toepassingen. Als u de Office 365-toepassingsgroep selecteert, kan dit leiden tot onbedoelde fouten. Deze wijziging is een uitzondering op de algemene regel die de Office 365-toepassingsgroep moet worden geselecteerd in een beleid voor voorwaardelijke toegang.
2. Kies Selecteren.
Onder voorwaarden:
1. Onder Apparaatplatforms:
  1. Stel Configureren in op Ja.
  2. Bevatten>Apparaatplatforms selecteren>Windows.
  3. Selecteer Gereed.
2. Onder Client-apps:
  1. Stel Configureren in op Ja.
    
    Waarschuwing
    
    Als u de voorwaarde Client-apps niet configureert of browser niet selecteert, kan dit ertoe leiden dat toepassingen die gebruikmaken van MSAL.js, zoals Teams Web, worden geblokkeerd.
  2. Selecteer onder Clients met moderne verificatie alleen mobiele apps en desktopclients. Laat andere items niet aangevinkt.
  3. Selecteer Gereed.
Selecteer onder Sessie voor toegangsbeheer>tokenbeveiliging vereisen voor aanmeldingssessies en selecteer Selecteren.
Bevestig uw instellingen en stel Beleid inschakelen in op Alleen rapport.
Selecteer Maken om uw beleid in te schakelen.

Nadat beheerders de beleidsinstellingen hebben geëvalueerd met behulp van de beleidsimpactmodus of de modus Alleen rapporten, kunnen ze de wisselknop Beleid inschakelen van alleen rapport naar Aan verplaatsen.

Hint

Aangezien beleid voor voorwaardelijke toegang waarvoor tokenbeveiliging is vereist, momenteel alleen beschikbaar is voor Windows-apparaten, is het noodzakelijk om uw omgeving te beveiligen tegen mogelijke bypass van beleid wanneer een aanvaller mogelijk afkomstig is van een ander platform.

Daarnaast moet u het volgende beleid configureren:

Logboeken vastleggen en analyseren

Bewaken van de handhaving van voorwaardelijke toegang en tokenbescherming vóór en na de handhaving met behulp van functies zoals Beleidsimpact (Preview), inloglogboeken of Log Analytics.

Gebruik het aanmeldingslogboek van Microsoft Entra om het resultaat van een afdwingingsbeleid voor tokenbeveiliging te controleren in de rapportmodus of in de ingeschakelde modus.

Meld u aan bij het Microsoft Entra-beheercentrum als minimaal een Administrator voor voorwaardelijke toegang.
Blader naar Entra IDBewaking & gezondheidAanmeldingslogboeken.
Selecteer een specifieke aanvraag om te bepalen of het beleid al dan niet wordt toegepast.
Ga naar het deelvenster Voorwaardelijke toegang of het deelvenster Alleen rapport , afhankelijk van de status en selecteer de naam van uw beleid waarvoor tokenbeveiliging is vereist.
Controleer onder Sessiebesturingselementen of aan de beleidsvereisten is voldaan of niet.
Als u meer informatie wilt over de bindingsstatus van de aanvraag, selecteert u het deelvenster Basisgegevens en bekijkt u de aanmeldingssessie van het veld Tokenbeveiliging. Mogelijke waarden zijn:
1. Gebonden: de aanvraag maakt gebruik van afhankelijke protocollen. Sommige aanmeldingen kunnen meerdere aanvragen bevatten en alle aanvragen moeten zijn gebonden aan het beveiligingsbeleid voor tokens. Zelfs als een afzonderlijke aanvraag afhankelijk lijkt te zijn, zorgt deze niet voor naleving van het beleid als andere aanvragen niet afhankelijk zijn. Als u alle verzoeken voor een aanmelding wilt zien, kunt u verzoeken voor een specifieke gebruiker filteren of zoeken op de correlation-id.
2. Niet-afhankelijk: de aanvraag maakt geen gebruik van afhankelijke protocollen. Mogelijk statusCodes wanneer het verzoek niet gebonden is, zijn:
  1. 1002: De aanvraag is ongebonden vanwege het gebrek aan Microsoft Entra ID-apparaatstatus.
  2. 1003: De aanvraag is niet gebonden omdat de apparaatstatus van Microsoft Entra ID niet voldoet aan de beleidsvereisten voor voorwaardelijke toegang tot beveiliging van tokens. Deze fout kan worden veroorzaakt door een niet-ondersteund apparaatregistratietype of het apparaat is niet geregistreerd met nieuwe aanmeldingsreferenties.
  3. 1005: De aanvraag is om andere, niet-gespecificeerde redenen ongebonden.
  4. 1006: Het verzoek is losgekoppeld omdat de versie van het besturingssysteem niet wordt ondersteund.
  5. 1008: De aanvraag is ongebonden omdat de client niet is geïntegreerd met de platform-broker, zoals Windows Account Manager (WAM).

Logboekanalyse

U kunt Log Analytics ook gebruiken om query's uit te voeren op de aanmeldingslogboeken (interactief en niet-interactief) voor geblokkeerde aanvragen vanwege een mislukte afdwinging van tokenbeveiliging.

Hier volgt een voorbeeld van een Log Analytics-query voor het doorzoeken van de niet-interactieve aanmeldingslogboeken voor de afgelopen zeven dagen, waarbij geblokkeerde versus toegestane aanvragen door de toepassing worden gemarkeerd. Deze query's zijn alleen voorbeelden en kunnen worden gewijzigd.

Notitie

Uitvoer van aanmeldingslogboeken: De waarde van de tekenreeks die wordt gebruikt in 'enforcedSessionControls' en 'sessionControlsNotSatisfied' is veranderd van 'Binding' in 'SignInTokenProtection' eind juni 2023. Query's voor aanmeldingslogboekgegevens moeten worden bijgewerkt om deze wijziging weer te geven. In de voorbeelden worden beide waarden behandeld om historische gegevens op te nemen.

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

Het resultaat van de vorige query moet er ongeveer uitzien als in de volgende schermopname:

In het volgende queryvoorbeeld wordt gekeken naar het niet-interactieve aanmeldingslogboek voor de afgelopen zeven dagen, waarbij geblokkeerde en toegestane aanvragen door de gebruiker worden gemarkeerd.

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

In het volgende queryvoorbeeld wordt gekeken naar het niet-interactieve aanmeldingslogboek voor de afgelopen zeven dagen, waarbij gebruikers worden gemarkeerd die apparaten gebruiken, waarbij de apparaatstatus van Microsoft Entra ID niet voldoet aan de beleidsvereisten voor tokenbeveiligings-CA.

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

Eindgebruikerservaring

Een gebruiker die zijn apparaat heeft geregistreerd of geregistreerd, ondervindt geen verschillen in de aanmeldingservaring op een toepassing die wordt ondersteund voor tokenbeveiliging wanneer de vereiste tokenbeveiliging is ingeschakeld.

Een gebruiker die zijn apparaat niet heeft geregistreerd of ingeschreven, of wanneer een niet-ondersteunde toepassing wordt gebruikt wanneer de vereiste tokenbeveiliging is ingeschakeld, ziet u de volgende schermopname na verificatie.

Schermopname van het foutbericht over tokenbeveiliging wanneer uw apparaat niet is geregistreerd of ingeschreven.

Een gebruiker die geen ondersteunde toepassing gebruikt wanneer de vereiste tokenbeveiliging is ingeschakeld, ziet de volgende schermopname na verificatie.

Schermopname van het foutbericht wanneer een tokenbeveiligingsbeleid de toegang blokkeert.

Wat is een Primary Refresh Token?

Delen via