Voorwaardelijke toegang: doelbronnen

Doelresources (voorheen cloud-apps, acties en verificatiecontext) zijn belangrijke signalen in een beleid voor voorwaardelijke toegang. Met beleid voor voorwaardelijke toegang kunnen beheerders controles toewijzen aan specifieke toepassingen, services, acties of verificatiecontext.

• Beheerders kunnen kiezen uit de lijst met toepassingen of services met ingebouwde Microsoft-toepassingen en alle Microsoft Entra geïntegreerde toepassingen, waaronder galerie, niet-galerie en toepassingen die zijn gepubliceerd via Application Proxy.
• Beheerders kunnen een beleid definiëren op basis van een gebruikersactie , zoals Beveiligingsgegevens registrerenof apparaten registreren of eraan deelnemen, zodat besturingselementen voor voorwaardelijke toegang rond deze acties worden afgedwongen.
• Beheerders kunnen profielen voor het doorsturen van verkeer vanuit Global Secure Access richten voor verbeterde functionaliteit.
• Beheerders kunnen verificatiecontext gebruiken om een extra beveiligingslaag in toepassingen te bieden.

Microsoft-cloudtoepassingen

Beheerders kunnen een conditie toegankelijkheidsbeleid toewijzen aan Microsoft-cloud-apps als de service-principal aanwezig is in hun tenant, met uitzondering van Microsoft Graph. Microsoft Graph fungeert als een overkoepelende resource. Gebruik Doelgroeprapportage om de onderliggende services te bekijken en deze services in uw beleid te richten. Sommige apps zoals Microsoft 365/Office 365 en Windows Azure Service Management API bevatten meerdere gerelateerde onderliggende apps of services. Wanneer er nieuwe Microsoft-cloudtoepassingen worden gemaakt, worden deze weergegeven in de app-kiezerlijst zodra de service-principal in de tenant is gemaakt.

Office 365

Microsoft 365 biedt cloudservices voor productiviteit en samenwerking, zoals Exchange, SharePoint en Microsoft Teams. In Voorwaardelijke toegang wordt de Microsoft 365 suite met toepassingen weergegeven onder 'Office 365'. Microsoft 365 cloudservices zijn diep geïntegreerd om soepele en samenwerkingservaringen te garanderen. Deze integratie kan verwarring veroorzaken bij het maken van beleid, omdat sommige apps, zoals Microsoft Teams, afhankelijk zijn van andere apps, zoals SharePoint of Exchange.

Met de Office 365 app-groepering in voorwaardelijke toegang kunt u deze services allemaal tegelijk richten. U wordt aangeraden de Microsoft 365 groep te gebruiken in plaats van afzonderlijke cloud-apps te gebruiken om problemen met serviceafhankelijkheden te voorkomen.

Als u zich richt op deze groep toepassingen, kunt u problemen voorkomen die kunnen optreden vanwege inconsistent beleid en afhankelijkheden. Bijvoorbeeld: de Exchange Online-app is gekoppeld aan traditionele Exchange Online gegevens, zoals e-mail, agenda en contactgegevens. Gerelateerde metagegevens kunnen worden weergegeven via verschillende resources, zoals zoeken. Beheerders moeten beleidsregels toewijzen aan de Microsoft 365-app om ervoor te zorgen dat alle metagegevens worden beveiligd door zoals bedoeld.

Beheerders kunnen de volledige Microsoft 365 suite of specifieke Microsoft 365 cloud-apps uitsluiten van beleid voor voorwaardelijke toegang.

Een volledige lijst met alle services die zijn opgenomen, vindt u in het artikel Apps opgenomen in het app-pakket voor voorwaardelijke toegang Microsoft 365.

Windows Azure Service Management-API

Wanneer u zich richt op de Windows Azure Service Management API-toepassing, wordt beleid afgedwongen voor tokens die zijn uitgegeven aan een set services die nauw zijn gekoppeld aan de portal. Deze groepering omvat de toepassings-id's van:

• Azure Resource Manager
• Azure portal, die ook betrekking heeft op het Microsoft Entra-beheercentrum en het Microsoft Engage Center
• Azure Data Lake
• API voor Application Insights
• Log Analytics-API

Omdat het beleid wordt toegepast op de Azure beheerportal en API, kunnen alle services of clients die afhankelijk zijn van de Azure-API indirect worden beïnvloed. Voorbeeld:

• Azure CLI
• Azure Data Factory portal
• Azure Event Hubs
• Azure PowerShell
• Azure Service Bus
• Azure SQL Database
• Azure Synapse
• Klassieke implementatiemodel-API's
• Microsoft 365-beheercentrum
• Microsoft IoT Central
• Microsoft Defender multitenant-beheer
• SQL Managed Instance
• beheerdersportal voor Visual Studio abonnementen

Microsoft-beheerportal

Wanneer een Beleid voor voorwaardelijke toegang gericht is op de cloud-app Microsoft-beheerportals, wordt het beleid afgedwongen voor tokens die zijn uitgegeven aan specifieke onderliggende resourcetoepassings-ID's die verband houden met Microsoft-beheerportals. De app-groepering bevat niet de back-endservices waarvoor deze portals mogelijk aanroepen of afhankelijk zijn. Als u serviceafhankelijkheden van de beheerportals wilt identificeren, gebruikt u de rapportage van de doelgroep voor voorwaardelijke toegang in aanmeldingslogboeken

De volgende toepassingen bestaan uit de Microsoft-beheerportals:

• App-ID Exchange Admin Center: 497effe9-df71-4043-a8bb-14cf78c4b63b
• Azure portal-app-id: c44b4083-3bb0-49c1-b47d-974e53cbdf3c
• Microsoft Office 365 Portal app ID: 00000006-0000-0ff1-ce00-000000000000
• Microsoft 365 Security And Compliance Center (Protection Center) app-ID: 80ccca67-54bd-44ab-8625-4b79c4dc7775

De groepering van de beheerportal is voornamelijk bedoeld voor scenario's, voor een vereenvoudigde manier om een of meer beheerportals te richten met beleid voor voorwaardelijke toegang (bijvoorbeeld het afdwingen van MFA). Deze groepering wordt gebruikt in ons door Microsoft beheerd MFA-beleid voor beheerders om het opstellen van beleid te stroomlijnen.

Deze optie is niet bedoeld als een mechanisme voor bulkuitsluiting voor alle back-endservices die zijn gekoppeld aan de onderliggende toepassings-id's.

Andere toepassingen

Beheerders kunnen elke Microsoft Entra geregistreerde toepassing toevoegen aan beleid voor voorwaardelijke toegang. Deze toepassingen kunnen het volgende omvatten:

• Toepassingen die zijn gepubliceerd via Microsoft Entra toepassingsproxy
• Toepassingen die zijn toegevoegd vanuit de galerie
• Aangepaste toepassingen niet in de galerie
• Verouderde toepassingen die via controllers en netwerken voor app-distributie zijn gepubliceerd
• Toepassingen die gebruikmaken van eenmalige aanmelding op basis van een wachtwoord

Sommige toepassingen worden helemaal niet weergegeven in het selectiemenu. De enige manier om deze toepassingen op te nemen in een beleid voor voorwaardelijke toegang is door Alle resources (voorheen 'Alle cloud-apps') op te nemen of de ontbrekende service-principal toe te voegen met behulp van de New-MgServicePrincipal PowerShell-cmdlet of met behulp van de Microsoft Graph API.

Voorwaardelijke toegang voor verschillende clienttypen

Voorwaardelijke toegang is van toepassing op resources niet op clients, behalve wanneer de client een vertrouwelijke client is die een id-token aanvraagt.

• Publieke klant
  • Openbare clients zijn clients die lokaal worden uitgevoerd op apparaten zoals Microsoft Outlook op het bureaublad of mobiele apps, zoals Microsoft Teams.
  • Beleid voor voorwaardelijke toegang is niet van toepassing op openbare clients zelf, maar is gebaseerd op de resources die ze aanvragen.
• Vertrouwelijke cliënt
  • Voorwaardelijke toegang is van toepassing op de resources die door de client zijn aangevraagd en de vertrouwelijke client zelf als er een id-token wordt aangevraagd.
  • Bijvoorbeeld: Als Outlook Web een token aanvraagt voor bereiken Mail.Read en Files.Read, past voorwaardelijke toegang beleid toe voor Exchange en SharePoint. Als Outlook web ook een id-token aanvraagt, past voorwaardelijke toegang ook het beleid voor Outlook web toe.

Om aanmeldingslogboeken voor deze clienttypen vanuit het Microsoft Entra-beheercentrum weer te geven:

1. Meld u aan bij het Microsoft Entra-beheercentrum als ten minste een Rapportlezer.
2. Blader naar Entra IDBewaking & gezondheidAanmeldingslogboeken.
3. Voeg een filter toe voor het clientreferentietype.
4. Pas het filter aan om een specifieke set logboeken weer te geven op basis van de clientreferenties die in de aanmelding worden gebruikt.

Zie het artikel Openbare client en vertrouwelijke clienttoepassingen voor meer informatie.

Voorwaardelijke toegang voor ALLE resources

Door een beleid voor voorwaardelijke toegang toe te passen op alle resources (voorheen 'Alle cloud-apps') zonder resourceuitsluitingen, wordt het beleid afgedwongen voor alle tokenaanvragen van websites en services, waaronder profielen voor het doorsturen van verkeer via globale beveiligde toegang. Deze optie omvat toepassingen die niet afzonderlijk zijn gericht op beleid voor voorwaardelijke toegang, zoals Windows Azure Active Directory (00000002-00000-0000-c000-00000000000000000000).

Verouderd voorwaardelijk toegangsbeleidgedrag bij een uitsluiting van een bron in een allesomvattend bronnenbeleid

Als een app wordt uitgesloten van het beleid, om niet per ongeluk de toegang van gebruikers te blokkeren, zijn bepaalde machtigingen met lage rechten eerder uitgesloten van de handhaving van het beleid. Deze scopes maakten oproepen naar de onderliggende Graph API's mogelijk, zoals Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) en Microsoft Graph (00000003-0000-0000-c000-000000000000), voor toegang tot gebruikersprofiel- en groepslidmaatschapsinformatie die vaak door toepassingen wordt gebruikt als onderdeel van authenticatie. Bijvoorbeeld: wanneer Outlook een token voor Exchange aanvraagt, wordt ook gevraagd naar het bereik User.Read om de basisaccountgegevens van de huidige gebruiker weer te geven.

De meeste apps hebben een vergelijkbare afhankelijkheid. Daarom zijn deze lagemachtigingsscopes automatisch uitgesloten in beleid voor Alle resources. De eerder uitgesloten scopes zijn als volgt. Toestemming is nog steeds vereist voor apps om deze machtigingen te gebruiken.

• Native clients en single-page applicaties (SPA's) hebben toegang tot de volgende scopes met lage machtigingen:
  • Azure AD Graph: email, offline_access, openid, profile, User.Read
  • Microsoft Graph: email, offline_access, openid, profile, User.Read, People.Read
• Vertrouwelijke clients hebben toegang tot de volgende low privilege scopes als ze zijn uitgesloten van een All resources policy.
  • Azure AD Graph: email, offline_access, openid, profile, User.Read, User.Read.All,User.ReadBasic.All
  • Microsoft Graph: email, offline_access, openid, profile, User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden

Nieuw gedrag voor voorwaardelijke toegang wanneer een ALL-resourcesbeleid een resourceuitsluiting heeft

De scopes die in de vorige sectie worden vermeld, worden nu geëvalueerd als directorytoegang en toegewezen aan Azure AD Graph (resource: Windows Azure Active Directory, ID: 00000002-0000-0000-c000-000000000000) voor de evaluatie van voorwaardelijke toegang.

Beleidsregels voor voorwaardelijke toegang die zijn gericht op alle resources met een of meer resourceuitsluitingen of beleidsregels die expliciet zijn gericht op Azure AD Graph, worden afgedwongen in gebruikersaanmeldingsstromen waarbij de clienttoepassing alleen deze bereiken aanvraagt. Er is geen wijziging in gedrag wanneer toepassingen een aanvullende machtiging aanvragen buiten de hierboven vermelde machtigingen.

Gebruikerservaring

In aanmeldingsstromen van gebruikers waarbij clienttoepassingen alleen de hierboven vermelde machtigingen aanvragen, kunnen gebruikers nu uitdagingen met voorwaardelijke toegang (zoals MFA of apparaatcompatibiliteit) tegenkomen. De exacte uitdaging is afhankelijk van de toegangscontroles die zijn geconfigureerd in uw beleid dat is gericht op alle resources (met of zonder resourceuitsluitingen) of beleidsregels die expliciet zijn gericht op Azure AD Graph.

In het volgende voorbeeld heeft de tenant een beleid voor voorwaardelijke toegang met de volgende details:

• Doelgericht op alle gebruikers en alle resources
• Resourceuitsluitingen voor een vertrouwelijke clienttoepassing en Exchange Online
• MFA is geconfigureerd als het toekenningsbeheer

Voorbeeldscenario's

Er is geen wijziging in gedrag wanneer een clienttoepassing een bereik aanvraagt buiten de eerder vermelde bereiken, zoals wordt geïllustreerd in de volgende voorbeelden.

Voorbeeldscenario's

De meeste toepassingen vragen om machtigingen buiten de eerder genoemde toegangsbereiken en vallen al onder de handhaving van voorwaardelijke toegang, tenzij de toepassing expliciet is uitgesloten van het beleid. In dergelijke gevallen is er geen wijziging in het gedrag.

Aangepaste toepassingen die opzettelijk zijn ontworpen om alleen de eerder vermelde bereiken aan te vragen en die niet zijn ontworpen voor het afhandelen van problemen met voorwaardelijke toegang, moeten mogelijk worden bijgewerkt, zodat ze problemen met voorwaardelijke toegang kunnen afhandelen. Raadpleeg de richtlijnen voor ontwikkelaars voor voorwaardelijke toegang van Microsoft voor meer informatie over de implementatie.

Toepassingen identificeren die worden beïnvloed door de wijziging in de handhaving van beperkte bevoegdheden.

Toepassingen kunnen vooraf worden geautoriseerd om slechts een of meer van de eerder vermelde toegangsrechten te verzoeken. Gebruik de volgende opties om betrokken toepassingen te identificeren.

# ==============================
# Inventory of apps whose delegated consent grants include ONLY
# the OIDC scopes + specific directory scopes listed below.
#
# Enhancements incorporated:
#  - Supported both PowerShell 5.1 and 7.x
#  - Add user sign-in count (last 7 days) per app
#
# Output:
#  - ServicePrincipalObjectId (oauth2PermissionGrants.clientId = SP object id)
#  - AppId
#  - AppDisplayName
#  - AppOwnerOrganizationId (for classification)
#  - Scopes (union of delegated scopes granted)
#  - UserSigninsLast7Days (Successful + Failed)
# ==============================

$TenantId = Read-Host "Enter your Microsoft Entra tenant ID (GUID)"

$BaselineScopes = @(
  "openid", "profile", "email", "offline_access",
  "User.Read", "User.Read.All", "User.ReadBasic.All",
  "People.Read", "People.Read.All",
  "GroupMember.Read.All", "Member.Read.Hidden"
)

Disconnect-MgGraph -ErrorAction SilentlyContinue

Connect-MgGraph -TenantId $TenantId -Scopes @(
  "DelegatedPermissionGrant.Read.All",
  "Directory.Read.All",
  "Reports.Read.All"
)

# ------------------------------
# Pull oauth2PermissionGrants (paging)
# ------------------------------
$uri = "https://graph.microsoft.com/beta/oauth2PermissionGrants?`$select=clientId,scope,consentType"
$grants = @()
while ($uri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $uri
  $grants += $resp.value
  $uri = $resp.'@odata.nextLink'
}

# ------------------------------
# Build baseline-only candidate set (Jun: HashSet per clientId)
# ------------------------------
$scopesByClient = @{}  # key: clientId (SP objectId), value: HashSet[string] (case-insensitive)

foreach ($g in $grants) {
  $cid = $g.clientId.ToString().Trim()
  if (-not $cid) { continue }

  if (-not $scopesByClient.ContainsKey($cid)) {
    $scopesByClient[$cid] = [System.Collections.Generic.HashSet[string]]::new(
      [System.StringComparer]::OrdinalIgnoreCase
    )
  }

  foreach ($s in ($g.scope -split '\s+')) {
    if ($s -and $s.Trim().Length -gt 0) {
      [void]$scopesByClient[$cid].Add($s.Trim())
    }
  }
}

$candidates = foreach ($cid in $scopesByClient.Keys) {
  $scopes = $scopesByClient[$cid]
  if ($scopes.Count -le 0) { continue }

  $outside = $scopes | Where-Object { $_ -notin $BaselineScopes }
  if ($outside.Count -eq 0) {
    [PSCustomObject]@{
      ServicePrincipalObjectId = $cid
      Scopes = ($scopes -join ' ')
    }
  }
}

# ------------------------------
# Pull per-app sign-in summary for last 7 days (Graph REST via Invoke-MgGraphRequest)
# Endpoint: GET /beta/reports/getAzureADApplicationSignInSummary(period='D7')
# In this API output, 'id' corresponds to the appId (clientId)
# ------------------------------
$signInSummary = @()
$signInUri = "https://graph.microsoft.com/beta/reports/getAzureADApplicationSignInSummary(period='D7')"

while ($signInUri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $signInUri

  if ($resp -and $resp.value) {
    $signInSummary += $resp.value
  }

  # Paging (if present)
  $signInUri = $resp.'@odata.nextLink'
}

# appId -> total sign-ins (7d)
$signInCountByAppId = @{}
foreach ($s in $signInSummary) {
  $appId = $s.id
  if (-not $appId) { continue }

  # PS5.1-safe null handling
  $success = 0
  $failed  = 0
  if ($null -ne $s.successfulSignInCount) { $success = [int]$s.successfulSignInCount }
  if ($null -ne $s.failedSignInCount)     { $failed  = [int]$s.failedSignInCount }

  $signInCountByAppId[$appId] = $success + $failed
}

$resultsTenantOwned = @()
$resultsNotTenantOwned = @()

# ------------------------------
# Filter to tenant-owned or external apps; enrich with appId/displayName + sign-in counts
# ------------------------------
foreach ($c in $candidates) {
  try {
    $spUri = "https://graph.microsoft.com/beta/servicePrincipals/$($c.ServicePrincipalObjectId)?`$select=id,appId,displayName,appOwnerOrganizationId"
    $sp = Invoke-MgGraphRequest -Method GET -Uri $spUri

    $signinCount7d = 0
    if ($sp.appId -and $signInCountByAppId.ContainsKey($sp.appId)) {
      $signinCount7d = $signInCountByAppId[$sp.appId]
    }

    $row = [PSCustomObject]@{
      ServicePrincipalObjectId = $c.ServicePrincipalObjectId
      AppId                   = $sp.appId
      AppDisplayName          = $sp.displayName
      AppOwnerOrganizationId  = $sp.appOwnerOrganizationId
      Scopes                  = $c.Scopes
      UserSigninsLast7Days    = $signinCount7d
    }

    if ($sp.appOwnerOrganizationId -eq $TenantId) {
      $resultsTenantOwned += $row
    }
    else {
      $resultsNotTenantOwned += $row
    }
  }
  catch {
    # Ignore non-enumerable / missing service principals
  }
}

# ------------------------------
# Output
# ------------------------------
'=== Tenant-owned apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

'=== External apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsNotTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

Bescherming van directory-informatie

Als het aanbevolen basislijn-MFA-beleid zonder resource-uitsluitingen vanwege zakelijke redenen niet kan worden geconfigureerd, en het beveiligingsbeleid van uw organisatie moet directory-gerelateerde bereiken met lage bevoegdheden bevatten (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden), maak een apart beleid voor voorwaardelijke toegang gericht op Windows Azure Active Directory (00000002-0000-0000-c000-000000000000). Windows Azure Active Directory (ook wel Azure AD Graph genoemd) is een resource die gegevens vertegenwoordigt die zijn opgeslagen in de directory, zoals gebruikers, groepen en toepassingen. De Windows Azure Active Directory-resource is opgenomen in All resources, maar kan afzonderlijk worden gericht op beleid voor voorwaardelijke toegang met behulp van de volgende stappen:

1. Meld u aan bij het Microsoft Entra-beheercentrum als Attribute Definition Administrator en Toedeeltoewijzingsbeheerder.
2. Blader naaraangepaste beveiligingskenmerken van >.
3. Maak een nieuwe kenmerkset en kenmerkdefinitie. Zie Toevoegen of deactiveren van aangepaste beveiligingskenmerkdefinities in Microsoft Entra ID voor meer informatie.
4. Navigeer naar Entra ID>Enterprise apps.
5. Verwijder het toepassingstypefilter en zoek naar toepassings-id die begint met 00000002-0000-0000-c000-000000000000.
6. Selecteer Windows Azure Active Directory>Custom beveiligingskenmerken>Toewijzing toevoegen.
7. Selecteer de kenmerkset en kenmerkwaarde die u wilt gebruiken in het beleid.
8. Blader naar Entra ID>Voorwaardelijke Toegang>Beleid.
9. Een bestaand beleid maken of wijzigen.
10. Selecteer onder Doelresources>Resources (voorheen cloud-apps)>Opnemen>Resources selecteren> en filter bewerken.
11. Pas het filter aan om de kenmerkenset en definitie van eerder op te nemen.
12. Selecteer onder Toegangsbeheer>Verlenen, Toegang verlenen, vereis Verificatiesterkte, selecteer Meervoudige verificatie en vervolgens Selecteren.
13. Controleer uw instellingen en stel Beleid inschakelen in op Alleen rapporteren.
14. Selecteer Maken om uw beleid in te schakelen.

Alle internetbronnen met Global Secure Access

Met de optie Alle internetresources met globale beveiligde toegang kunnen beheerders zich richten op het internettoegangsprofiel vanuit Microsoft Entra Internet Access.

Met deze profielen in Global Secure Access kunnen beheerders bepalen en bepalen hoe verkeer wordt gerouteerd via Microsoft Entra Internet Access en Microsoft Entra Private Access. Profielen voor het doorsturen van verkeer kunnen worden toegewezen aan apparaten en externe netwerken. Zie het artikel Hoe u beleid voor voorwaardelijke toegang toepast op het Microsoft 365 verkeersprofiel voor een voorbeeld van het toepassen van beleid voor voorwaardelijke toegang op deze verkeersprofielen.

Zie het artikel Global Secure Access Traffic Forwarding-profielen voor meer informatie over deze profielen.

Alle agentmiddelen (Preview)

Door een beleid voor voorwaardelijke toegang toe te passen op alle agentbronnen, wordt het beleid afgedwongen voor alle tokenaanvragen voor blauwdrukprinciplen van agents en agentidentiteiten.

Gebruikersacties

Gebruikersacties zijn taken die een gebruiker uitvoert. Voorwaardelijke toegang ondersteunt twee gebruikersacties:

• Beveiligingsgegevens registreren: met deze gebruikersactie kunnen beleidsregels voor voorwaardelijke toegang regels afdwingen wanneer gebruikers hun beveiligingsgegevens proberen te registreren. Zie Gecombineerde registratie van beveiligingsgegevens voor meer informatie.

• Apparaten registreren of koppelen: Met deze gebruikersactie kunnen beheerders een beleid voor voorwaardelijke toegang afdwingen wanneer gebruikers apparaten registreren of koppelen met Microsoft Entra ID. Hiermee kunnen beheerders meervoudige verificatie configureren voor het registreren of samenvoegen van apparaten met meer granulariteit dan een tenantbreed beleid. Er zijn drie belangrijke overwegingen met deze gebruikersactie:
  • Require multifactor authentication en Require auth strength zijn de enige beschikbare toegangscontroles voor deze gebruikersactie en alle andere zijn uitgeschakeld. Deze beperking voorkomt conflicten met toegangscontroles die afhankelijk zijn van Microsoft Entra apparaatregistratie of die niet van toepassing zijn op Microsoft Entra apparaatregistratie.
    • Windows Hello for Business en apparaatgebonden wachtwoordsleutels worden niet ondersteund omdat voor deze scenario's het apparaat al moet worden geregistreerd.
  • Client apps, Filters for devices en Device state voorwaarden zijn niet beschikbaar voor deze gebruikersactie omdat ze afhankelijk zijn van Microsoft Entra apparaatregistratie om beleid voor voorwaardelijke toegang af te dwingen.

Verificatiecontext

Verificatiecontext beveiligt gegevens en acties in toepassingen. Deze toepassingen omvatten aangepaste toepassingen, LOB-toepassingen (Line-Of-Business), SharePoint of toepassingen die worden beveiligd door Microsoft Defender for Cloud Apps. Het kan ook worden gebruikt met Microsoft Entra Privileged Identity Management (PIM) om beleid voor voorwaardelijke toegang af te dwingen tijdens het activeren van rollen.

Een organisatie kan bijvoorbeeld bestanden opslaan in SharePoint sites zoals een lunchmenu of een geheim BBQ-sausrecept. Iedereen heeft mogelijk toegang tot de lunchmenusite, maar gebruikers die toegang hebben tot de geheime BBQ-sausreceptsite, moeten mogelijk een beheerd apparaat gebruiken en akkoord gaan met specifieke gebruiksvoorwaarden. Een beheerder die een bevoorrechte rol via PIM activeert, kan ook vereist zijn om meervoudige verificatie uit te voeren of een compatibel apparaat te gebruiken.

De context voor verificatie werkt met gebruikers of workload-identiteiten, maar niet binnen hetzelfde beleid voor voorwaardelijke toegang.

Verificatiecontexten configureren

Beheer verificatiecontexten door naar Entra ID>Voorwaardelijke Toegang>Verificatiecontext te gaan.

Selecteer Nieuwe verificatiecontext om een verificatiecontextdefinitie te maken. Organisaties kunnen maximaal 99 verificatiecontextdefinities (c1-c99) maken. Configureer deze kenmerken:

• Display name is de naam die wordt gebruikt om de verificatiecontext te identificeren in Microsoft Entra ID en in toepassingen die verificatiecontexten gebruiken. We raden namen aan die kunnen worden gebruikt voor resources, zoals vertrouwde apparaten, om het aantal benodigde verificatiecontexten te verminderen. Een beperkte set vermindert het aantal omleidingen en zorgt voor een betere gebruikerservaring van begin tot eind.
• Beschrijving bevat meer informatie over het beleid. Deze informatie wordt gebruikt door beheerders en beheerders die verificatiecontexten toepassen op resources.
• Het selectievakje Publiceren naar apps , indien geselecteerd, kondigt de verificatiecontext aan apps aan en maakt deze beschikbaar om te worden toegewezen. Als deze optie niet is geselecteerd, is de verificatiecontext niet beschikbaar voor downstream-resources.
• ID is alleen-lezen en wordt gebruikt in tokens en apps voor contextdefinities voor authenticatie die specifiek zijn voor aanvragen. Hier vermeld voor troubleshooting en gebruiksscenario's bij ontwikkeling.

Toevoegen aan beleid voor voorwaardelijke toegang

Beheerders kunnen gepubliceerde verificatiecontexten selecteren in beleid voor voorwaardelijke toegang door naar Toewijzingen>Cloud-apps of -acties te gaan en verificatiecontext te selecteren in het menu Selecteer waarop dit beleid van toepassing is.

Een verificatiecontext verwijderen

Voordat u een verificatiecontext verwijdert, moet u ervoor zorgen dat er geen toepassingen gebruik van maken. Anders wordt de toegang tot app-gegevens niet beveiligd. Bevestig dit door aanmeldingslogboeken te controleren voor gevallen waarin beleid voor voorwaardelijke toegang voor verificatiecontext wordt toegepast.

Als u een verificatiecontext wilt verwijderen, moet u ervoor zorgen dat er geen beleid voor voorwaardelijke toegang is toegewezen en dat deze niet gepubliceerd is naar apps. Dit voorkomt onbedoelde verwijdering van een verificatiecontext die nog steeds wordt gebruikt.

Bronnen labelen met verificatiecontexten

Zie de volgende artikelen voor meer informatie over het gebruik van verificatiecontexten.

• Vertrouwelijkheidslabels gebruiken om inhoud in Microsoft Teams, Microsoft 365 groepen en SharePoint sites te beveiligen
• Microsoft Defender for Cloud Apps
• Aangepaste toepassingen
• Privileged Identity Management - Voor activering is Microsoft Entra context voor verificatie van voorwaardelijke toegang vereist

Verwante inhoud

• Voorwaardelijke toegang: voorwaarden : informatie over het configureren van voorwaarden om uw beleid te verfijnen.
• Algemene beleidsregels voor voorwaardelijke toegang : algemene beleidssjablonen verkennen om snel aan de slag te gaan.
• Afhankelijkheden van clienttoepassingen : inzicht in hoe afhankelijkheden van invloed zijn op beleid voor voorwaardelijke toegang.