Verificatie en voorwaardelijke toegang voor externe id
Tip
Dit artikel is van toepassing op B2B-samenwerking en B2B direct connect. Als uw tenant is geconfigureerd voor klantidentiteit en toegangsbeheer, raadpleegt u Beveiliging en governance in Microsoft Entra Externe ID.
Wanneer een externe gebruiker toegang heeft tot resources in uw organisatie, wordt de verificatiestroom bepaald door de samenwerkingsmethode (B2B-samenwerking of B2B direct connect), de id-provider van de gebruiker (een externe Microsoft Entra-tenant, sociale id-provider, enzovoort), het beleid voor voorwaardelijke toegang en de instellingen voor toegang tussen tenants die zijn geconfigureerd in de tenant van de gebruiker thuis en de tenanthostingbronnen.
In dit artikel wordt de verificatiestroom beschreven voor externe gebruikers die toegang hebben tot bronnen in uw organisatie. Organisaties kunnen meerdere beleidsregels voor voorwaardelijke toegang afdwingen voor hun externe gebruikers. Deze kunnen op tenant-, app- of individueel gebruikersniveau worden afgedwongen op dezelfde manier als ze zijn ingeschakeld voor fulltime werknemers en leden van de organisatie.
Verificatiestroom voor externe Microsoft Entra-gebruikers
In het volgende diagram ziet u de verificatiestroom wanneer een Microsoft Entra-organisatie resources deelt met gebruikers van andere Microsoft Entra-organisaties. In dit diagram ziet u hoe instellingen voor toegang tussen tenants werken met beleid voor voorwaardelijke toegang, zoals meervoudige verificatie, om te bepalen of de gebruiker toegang heeft tot resources. Deze stroom is van toepassing op zowel B2B-samenwerking als B2B Direct Connect, behalve zoals vermeld in stap 6.
| Stap | Omschrijving |
|---|---|
| 1 | Een gebruiker van Fabrikam (de home tenant van de gebruiker) initieert aanmelding bij een bron in Contoso (de tenant van bron). |
| 2 | Tijdens het aanmelden evalueert de Microsoft Entra-beveiligingstokenservice (STS) het beleid voor voorwaardelijke toegang van Contoso. Ook wordt gecontroleerd of de Fabrikam-gebruiker toegang heeft toegestaan door de instellingen voor toegang als crosstenant te evalueren (de uitgaande instellingen van Fabrikam en de binnenkomende instellingen van Contoso). |
| 3 | Microsoft Entra ID controleert de instellingen voor binnenkomende vertrouwensrelaties van Contoso om te zien of Contoso MFA en apparaatclaims vertrouwt (apparaatnaleving, status van hybride deelname aan Microsoft Entra) van Fabrikam. Zo niet, ga dan verder met stap 6. |
| 4 | Als Contoso MFA en apparaatclaims vertrouwt van Fabrikam, controleert Microsoft Entra-id de verificatiesessie van de gebruiker op een indicatie dat de gebruiker MFA heeft voltooid. Als Contoso apparaatgegevens van Fabrikam vertrouwt, zoekt Microsoft Entra-id naar een claim in de verificatiesessie die de apparaatstatus aangeeft (compatibel of aan Microsoft Entra toegevoegd). |
| 5 | Als MFA is vereist, maar niet is voltooid, of als er geen apparaatclaim wordt opgegeven, geeft Microsoft Entra ID MFA en apparaatuitdagingen op in de thuistenant van de gebruiker, indien nodig. Wanneer aan MFA en apparaatvereisten in Fabrikam wordt voldaan, heeft de gebruiker toegang tot de bron in Contoso. Als niet aan de controles kan worden voldaan, wordt de toegang geblokkeerd. |
| 6 | Wanneer er geen vertrouwensinstellingen zijn geconfigureerd en MFA is vereist, worden gebruikers van B2B-samenwerking gevraagd om MFA. Ze moeten voldoen aan MFA in de resourcetenant. Toegang is geblokkeerd voor B2B-gebruikers die direct verbinding maken. Als apparaatcompatibiliteit is vereist, maar niet kan worden geëvalueerd, wordt de toegang geblokkeerd voor B2B-samenwerking en gebruikers van B2B Direct Connect. |
Zie voor meer informatie de sectie Voorwaardelijke toegang voor externe gebruikers.
Verificatiestroom voor externe niet-Azure AD-gebruikers
Wanneer een Microsoft Entra-organisatie resources deelt met externe gebruikers met een andere id-provider dan Microsoft Entra-id, is de verificatiestroom afhankelijk van of de gebruiker wordt geverifieerd met een id-provider of met eenmalige wachtwoordcodeverificatie via e-mail. In beide gevallen identificeert de tenant van de bron welke verificatiemethode moet worden gebruikt en wordt de gebruiker vervolgens omgeleid naar de id-provider of wordt een eenmalige wachtwoordcode opgegeven.
Voorbeeld 1: verificatiestroom en token voor een externe niet-Azure AD-gebruiker
Het volgende diagram illustreert de verificatiestroom wanneer een externe gebruiker zich aanmeldt met een account van een niet-Azure AD id-provider, zoals Google, Facebook of een federatieve SAML/WS-Fed-id-provider.
| Stap | Omschrijving |
|---|---|
| 1 | De B2B-gastgebruiker vraagt toegang tot een bron aan. De bron leidt de gebruiker om naar de tenant van de bron, een vertrouwde IdP. |
| 2 | De tenant van de bron identificeert de gebruiker als extern en leidt de gebruiker om naar de IdP van de B2B-gastgebruiker. De gebruiker voert primaire verificatie uit in de IdP. |
| 3 | Autorisatiebeleid wordt geëvalueerd in de IdP van de B2B-gastgebruiker. Als de gebruiker aan dit beleid voldoet, geeft de IdP van de B2B-gastgebruiker een token uit aan de gebruiker. De gebruiker wordt teruggeleid naar de tenant van de bron met het token. De tenant van de bron valideert het token en evalueert vervolgens de gebruiker op basis van het beleid voor voorwaardelijke toegang. De resourcetenant kan bijvoorbeeld vereisen dat de gebruiker Meervoudige Verificatie van Microsoft Entra uitvoert. |
| 4 | Instellingen voor binnenkomende toegang voor meerdere tenants en beleid voor voorwaardelijke toegang worden geëvalueerd. Als aan alle beleidsregels wordt voldaan, geeft de tenant van de bron een eigen token uit en wordt de gebruiker omgeleid naar de bron. |
Voorbeeld 2: verificatiestroom en token voor gebruiker van eenmalige wachtwoordcode
In het volgende diagram ziet u de stroom wanneer eenmalige wachtwoordcodeverificatie voor e-mail is ingeschakeld en de externe gebruiker niet wordt geverifieerd via een andere methode, zoals Microsoft Entra ID, Microsoft-account (MSA) of sociale id-provider.
| Stap | Omschrijving |
|---|---|
| 1 | De gebruiker vraagt toegang tot een bron in een andere tenant. De bron leidt de gebruiker om naar de tenant van de bron, een vertrouwde IdP. |
| 2 | De tenant van de bron identificeert de gebruiker als een externe gebruiker van eenmalige wachtwoordcode (OTP) voor e-mail en verzendt een e-mail met de OTP naar de gebruiker. |
| 3 | De gebruiker haalt de OTP op en verzendt de code. De tenant van de bron evalueert de gebruiker op basis van het beleid voor voorwaardelijke toegang. |
| 4 | Zodra aan alle beleidsregels voor voorwaardelijke toegang is voldaan, geeft de tenant van de bron een token uit en wordt de gebruiker omgeleid naar diens bron. |
Voorwaardelijke toegang voor externe gebruikers
Organisaties kunnen beleidsregels afdwingen voor voorwaardelijke toegang voor externe gebruikers van B2B-samenwerking en B2B Direct Connect, op dezelfde manier waarop deze zijn ingeschakeld voor voltijdse werknemers en leden van de organisatie. Met de introductie van instellingen voor toegang tussen tenants kunt u ook MFA en apparaatclaims van externe Microsoft Entra-organisaties vertrouwen. In deze sectie worden belangrijke overwegingen beschreven voor het toepassen van voorwaardelijke toegang op gebruikers buiten uw organisatie.
Notitie
Aangepaste besturingselementen met voorwaardelijke toegang worden niet ondersteund voor vertrouwensrelaties tussen tenants.
Beleid voor voorwaardelijke toegang toewijzen aan externe gebruikerstypen
Bij het configureren van beleid voor voorwaardelijke toegang hebt u gedetailleerde controle over de typen externe gebruikers waarop u het beleid wilt toepassen. Externe gebruikers worden gecategoriseerd op basis van hoe ze zich verifiëren (intern of extern) en hun relatie met uw organisatie (gast of lid).
- Gastgebruikers van B2B-samenwerking: de meeste gebruikers die vaak als gasten worden beschouwd, vallen in deze categorie. Deze B2B-samenwerkingsgebruiker heeft een account in een externe Microsoft Entra-organisatie of een externe id-provider (zoals een sociale identiteit) en ze hebben machtigingen op gastniveau in uw organisatie. Het gebruikersobject dat is gemaakt in uw Microsoft Entra-directory heeft een UserType of Guest. Deze categorie omvat B2B-samenwerkingsgebruikers die zijn uitgenodigd en die selfserviceregistratie hebben gebruikt.
- B2B-samenwerkingslidgebruikers : deze B2B-samenwerkingsgebruiker heeft een account in een externe Microsoft Entra-organisatie of een externe id-provider (zoals een sociale identiteit) en toegang op lidniveau tot resources in uw organisatie. Dit scenario is gebruikelijk in organisaties die bestaan uit meerdere tenants, waarbij gebruikers worden beschouwd als onderdeel van de grotere organisatie en toegang op lidniveau nodig hebben tot resources in de andere tenants van de organisatie. Het gebruikersobject dat is gemaakt in de resourcemap Microsoft Entra heeft een UserType of Member.
- B2B-gebruikers met directe verbinding: externe gebruikers die toegang hebben tot uw resources via B2B Direct Connect, een wederzijdse, tweerichtingsverbinding met een andere Microsoft Entra-organisatie waarmee eenmalige aanmelding tot bepaalde Microsoft-toepassingen (momenteel Microsoft Teams Verbinding maken gedeelde kanalen) is toegestaan. B2B-gebruikers hebben geen aanwezigheid in uw Microsoft Entra-organisatie, maar worden in plaats daarvan beheerd vanuit de toepassing (bijvoorbeeld door de eigenaar van het gedeelde Teams-kanaal).
- Lokale gastgebruikers : lokale gastgebruikers hebben referenties die worden beheerd in uw directory. Voordat Microsoft Entra B2B-samenwerking beschikbaar was, was het gebruikelijk om samen te werken met distributeurs, leveranciers, leveranciers en anderen door interne referenties voor hen in te stellen en ze aan te wijzen als gasten door het gebruikersobject UserType in te stellen op Gast.
- Gebruikers van serviceproviders : organisaties die fungeren als cloudserviceproviders voor uw organisatie (de eigenschap isServiceProvider in de microsoft Graph-partnerspecifieke configuratie is waar).
- Andere externe gebruikers : is van toepassing op gebruikers die niet in deze categorieën vallen, maar die niet worden beschouwd als interne leden van uw organisatie, wat betekent dat ze intern niet worden geverifieerd via Microsoft Entra-id en het gebruikersobject dat is gemaakt in de microsoft Entra-resourcemap heeft geen UserType of Member.
Notitie
De selectie Alle gast- en externe gebruikers is nu vervangen door gast- en externe gebruikers en alle subtypen. Voor klanten die eerder een Condtional Access-beleid hadden met Alle gast- en externe gebruikers geselecteerd, ziet u nu 'Gast- en externe gebruikers' samen met alle subtypen die worden geselecteerd. Deze wijziging in UX heeft geen functionele invloed op de manier waarop beleid wordt geëvalueerd door de back-end voor voorwaardelijke toegang. De nieuwe selectie biedt klanten de benodigde granulariteit om specifieke typen gast- en externe gebruikers te kiezen voor het opnemen/uitsluiten van gebruikersbereik bij het maken van hun beleid voor voorwaardelijke toegang.
Meer informatie over gebruikerstoewijzingen voor voorwaardelijke toegang.
Beleid voor voorwaardelijke toegang voor externe id vergelijken
De volgende tabel bevat een gedetailleerde vergelijking van de beveiligingsbeleids- en nalevingsopties in Microsoft Entra Externe ID. Beveiligingsbeleid en naleving worden beheerd door de host/uitnodigende organisatie onder beleid voor voorwaardelijke toegang.
| Beleid | B2B-samenwerkingsgebruikers | B2B-gebruikers direct verbinden |
|---|---|---|
| Besturingselementen verlenen- Toegang blokkeren | Ondersteund | Ondersteund |
| Besturingselementen verlenen - Meervoudige verificatie vereisen | Ondersteund | Ondersteund, vereist het configureren van uw instellingen voor binnenkomende vertrouwensrelaties om MFA-claims van de externe organisatie te accepteren |
| Besturingselementen verlenen - Compatibel apparaat vereisen | Hiervoor moet u de instellingen voor binnenkomende vertrouwensrelaties configureren om compatibele apparaatclaims van de externe organisatie te accepteren. | Hiervoor moet u de instellingen voor binnenkomende vertrouwensrelaties configureren om compatibele apparaatclaims van de externe organisatie te accepteren. |
| Besturingselementen verlenen - Hybride apparaat van Microsoft Entra vereisen | Ondersteund, vereist het configureren van uw instellingen voor binnenkomende vertrouwensrelaties om hybride apparaatclaims van Microsoft Entra van de externe organisatie te accepteren | Ondersteund, vereist het configureren van uw instellingen voor binnenkomende vertrouwensrelaties om hybride apparaatclaims van Microsoft Entra van de externe organisatie te accepteren |
| Besturingselementen verlenen - goedgekeurde client-app vereisen | Niet ondersteund | Niet ondersteund |
| Besturingselementen verlenen - Beveiligingsbeleid voor apps vereisen | Niet ondersteund | Niet ondersteund |
| Besturingselementen verlenen - Wachtwoordwijziging vereisen | Niet ondersteund | Niet ondersteund |
| Besturingselementen verlenen - Gebruiksvoorwaarden | Ondersteund | Niet ondersteund |
| Sessiebesturingselementen : afgedwongen beperkingen voor apps gebruiken | Ondersteund | Niet ondersteund |
| Sessiebesturingselementen - App-beheer voor voorwaardelijke toegang gebruiken | Ondersteund | Niet ondersteund |
| Sessiebesturingselementen - Aanmeldingsfrequentie | Ondersteund | Niet ondersteund |
| Sessiebesturingselementen - Permanente browsersessie | Ondersteund | Niet ondersteund |
MFA voor externe Microsoft Entra-gebruikers
In een Scenario voor meerdere tenants van Microsoft Entra kan de resourceorganisatie beleid voor voorwaardelijke toegang maken waarvoor MFA of apparaatcompatibiliteit is vereist voor alle gast- en externe gebruikers. Over het algemeen is een B2B-samenwerkingsgebruiker die toegang heeft tot een resource vervolgens vereist om de meervoudige verificatie van Microsoft Entra in te stellen met de resourcetenant. Microsoft Entra ID biedt nu echter de mogelijkheid om MFA-claims van andere Microsoft Entra-tenants te vertrouwen. Het inschakelen van een MFA-vertrouwensrelatie met een andere tenant stroomlijnt het aanmeldingsproces voor gebruikers van B2B-samenwerking en maakt toegang mogelijk voor gebruikers van B2B Direct Connect.
Als u de instellingen voor binnenkomende vertrouwensrelaties hebt geconfigureerd voor het accepteren van MFA-claims van een B2B-samenwerking of B2B direct connect-tenant van de gebruiker, controleert Microsoft Entra ID de verificatiesessie van de gebruiker. Als de sessie een claim bevat die aangeeft dat er al aan MFA-beleid is voldaan in de basistenant van de gebruiker, krijgt de gebruiker naadloze aanmelding bij uw gedeelde resource.
Als MFA-vertrouwensrelatie niet is ingeschakeld, is de gebruikerservaring anders voor gebruikers van B2B-samenwerking en B2B-gebruikers voor directe verbinding:
B2B-samenwerkingsgebruikers: als de resourceorganisatie MFA-vertrouwen niet inschakelt met de basistenant van de gebruiker, krijgt de gebruiker een MFA-uitdaging van de resourceorganisatie te zien. (De stroom is hetzelfde als de MFA-stroom voor externe niet-Azure AD-gebruikers.)
B2B-gebruikers direct verbinden: als de resourceorganisatie MFA-vertrouwen niet inschakelt met de basistenant van de gebruiker, wordt de gebruiker geblokkeerd voor toegang tot resources. Als u directe B2B-verbindingen met een externe organisatie wilt toestaan en uw beleid voor voorwaardelijke toegang MFA vereist, moet u uw instellingen voor inkomende vertrouwen configureren om MFA-claims van de organisatie te accepteren.
Meer informatie over het Configureren van binnenkomende vertrouwensinstellingen voor MFA.
MFA voor externe niet-Azure AD-gebruikers
Voor externe niet-Azure AD-gebruikers is de tenant van de bron altijd verantwoordelijk voor MFA. In het volgende voorbeeld ziet u een typische MFA-stroom. Dit scenario werkt voor elke identiteit, inclusief een Microsoft-account (MSA) of sociale id. Deze stroom is ook van toepassing op externe Microsoft Entra-gebruikers wanneer u geen vertrouwensinstellingen configureert met hun microsoft entra-organisatie.
Een beheerder of IT-medewerker in een bedrijf met de naam Fabrikam nodigt een gebruiker uit van een ander bedrijf met de naam Contoso om de app van Fabrikam te gebruiken.
De app van Fabrikam is geconfigureerd om meervoudige verificatie van Microsoft Entra te vereisen bij toegang.
Wanneer de B2B-samenwerkingsgebruiker van Contoso toegang probeert te krijgen tot de app van Fabrikam, wordt deze gevraagd om de meervoudige verificatievraag van Microsoft Entra te voltooien.
De gastgebruiker kan vervolgens de meervoudige verificatie van Microsoft Entra instellen met Fabrikam en de opties selecteren.
Fabrikam moet over voldoende Premium Microsoft Entra ID-licenties beschikken die ondersteuning bieden voor Meervoudige Verificatie van Microsoft Entra. De gebruiker van Contoso gebruikt vervolgens deze licentie van Fabrikam. Zie het factureringsmodel voor Microsoft Entra Externe ID voor informatie over de B2B-licentie.
Notitie
MFA wordt voltooid bij tenants van bronnen om voorspelbaarheid te garanderen. Wanneer de gastgebruiker zich aanmeldt, ziet deze de aanmeldingspagina van de tenant van de bron op de achtergrond en de eigen aanmeldingspagina van de home tenant en het bedrijfslogo op de voorgrond.
Microsoft Entra multifactor authentication reset (proof up) voor B2B-samenwerkingsgebruikers
De volgende PowerShell-cmdlets zijn beschikbaar om proof up uit te voeren voor MFA-registratie of deze aan te vragen bij gebruikers van B2B-samenwerking.
Notitie
Azure AD- en MSOnline PowerShell-modules zijn vanaf 30 maart 2024 afgeschaft. Lees de afschaffingsupdate voor meer informatie. Na deze datum is ondersteuning voor deze modules beperkt tot migratieondersteuning voor Microsoft Graph PowerShell SDK en beveiligingsoplossingen. De afgeschafte modules blijven functioneren tot en met 30 maart 2025.
Het is raadzaam om te migreren naar Microsoft Graph PowerShell om te communiceren met Microsoft Entra ID (voorheen Azure AD). Raadpleeg de veelgestelde vragen over migratie voor veelgestelde vragen over migratie. Opmerking: versies 1.0.x van MSOnline kunnen na 30 juni 2024 onderbrekingen ondervinden.
Verbinding maken naar Microsoft Entra-id:
$cred = Get-Credential Connect-MsolService -Credential $credAlle gebruikers ophalen met proof-upmethoden:
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}Voorbeeld:
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}Stel de meervoudige verificatiemethode van Microsoft Entra opnieuw in voor een specifieke gebruiker, zodat de gebruiker opnieuw controlemethoden moet instellen, bijvoorbeeld:
Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.onmicrosoft.com
Beleid voor verificatiesterkte voor externe gebruikers
Verificatiesterkte is een besturingselement voor voorwaardelijke toegang waarmee u een specifieke combinatie van meervoudige verificatiemethoden kunt definiëren die een externe gebruiker moet voltooien met toegang tot uw resources. Dit besturingselement is vooral handig voor het beperken van externe toegang tot gevoelige apps in uw organisatie, omdat u specifieke verificatiemethoden, zoals een phishingbestendige methode, kunt afdwingen voor externe gebruikers.
U hebt ook de mogelijkheid om verificatiesterkte toe te passen op de verschillende typen gast- of externe gebruikers waarmee u samenwerkt of waarmee u verbinding maakt. Dit betekent dat u vereisten voor verificatiesterkte kunt afdwingen die uniek zijn voor uw B2B-samenwerking, B2B direct connect en andere scenario's voor externe toegang.
Microsoft Entra ID biedt drie ingebouwde verificatiesterkten:
- Meervoudige verificatiesterkte
- MFA-sterkte zonder wachtwoord
- Phishingbestendige MFA-sterkte
U kunt een van deze ingebouwde sterke punten gebruiken of een aangepast verificatiesterktebeleid maken op basis van de verificatiemethoden die u wilt vereisen.
Notitie
Op dit moment kunt u alleen beleidsregels voor verificatiesterkte toepassen op externe gebruikers die zich verifiëren met Microsoft Entra-id. Gebruik voor eenmalige wachtwoordcode voor e-mail, SAML/WS-Fed en Google-federatiegebruikers de MFA-toekenningsbeheer om MFA te vereisen.
Wanneer u een verificatiesterktebeleid toepast op externe Microsoft Entra-gebruikers, werkt het beleid samen met MFA-vertrouwensinstellingen in uw instellingen voor toegang tussen tenants om te bepalen waar en hoe de externe gebruiker MFA moet uitvoeren. Een Microsoft Entra-gebruiker verifieert zich eerst met hun eigen account in hun eigen Microsoft Entra-tenant. Wanneer deze gebruiker vervolgens toegang probeert te krijgen tot uw resource, past Microsoft Entra ID het beleid voor voorwaardelijke toegang van de verificatiesterkte toe en controleert of u MFA-vertrouwensrelatie hebt ingeschakeld.
In externe gebruikersscenario's variëren de verificatiemethoden die acceptabel zijn voor het voldoen aan de verificatiesterkte, afhankelijk van of de gebruiker MFA in hun thuistenant of de resourcetenant voltooit. De volgende tabel geeft de acceptabele methoden in elke tenant aan. Als een resourcetenant ervoor kiest claims van externe Microsoft Entra-organisaties te vertrouwen, worden alleen de claims die worden vermeld in de kolom 'Thuistenant' geaccepteerd door de resourcetenant voor MFA-uitvoering. Als de resourcetenant MFA-vertrouwen heeft uitgeschakeld, moet de externe gebruiker MFA in de resourcetenant voltooien met behulp van een van de methoden die worden vermeld in de kolom Resourcetenant.
Tabel 1. MFA-methoden voor verificatiesterkte voor externe gebruikers
| Verificatiemethode | Thuistenant | Resourcetenant |
|---|---|---|
| SMS als tweede factor | ✅ | ✅ |
| Spraakoproep | ✅ | ✅ |
| Pushmelding van Microsoft Authenticator | ✅ | ✅ |
| Aanmelden bij Microsoft Authenticator-telefoon | ✅ | |
| OATH-softwaretoken | ✅ | ✅ |
| OATH-hardware beveiligingstoken | ✅ | |
| FIDO2-beveiligingssleutel | ✅ | |
| Windows Hello voor Bedrijven | ✅ |
Als u een beleid voor voorwaardelijke toegang wilt configureren dat verificatiesterktevereisten toepast op externe gebruikers of gasten, raadpleegt u Voorwaardelijke toegang: Een verificatiesterkte vereisen voor externe gebruikers.
Gebruikerservaring voor externe Microsoft Entra-gebruikers
Beleidsregels voor verificatiesterkte werken samen met MFA-vertrouwensinstellingen in uw instellingen voor toegang tussen tenants om te bepalen waar en hoe de externe gebruiker MFA moet uitvoeren.
Eerst verifieert een Microsoft Entra-gebruiker zich met zijn eigen account in zijn eigen tenant. Wanneer deze gebruiker vervolgens toegang probeert te krijgen tot uw resource, past Microsoft Entra ID het beleid voor voorwaardelijke toegang van de verificatiesterkte toe en controleert of u MFA-vertrouwensrelatie hebt ingeschakeld.
- Als MFA-vertrouwensrelatie is ingeschakeld, controleert Microsoft Entra-id de verificatiesessie van de gebruiker op een claim die aangeeft dat MFA is voldaan in de basistenant van de gebruiker. (Zie Tabel 1 voor verificatiemethoden die acceptabel zijn voor MFA-uitvoering wanneer deze zijn voltooid in de basistenant van een externe gebruiker.) Als de sessie een claim bevat die aangeeft dat aan MFA-beleid al is voldaan in de basistenant van de gebruiker en de methoden voldoen aan de vereisten voor verificatiesterkte, heeft de gebruiker toegang toegestaan. Anders biedt Microsoft Entra ID de gebruiker een uitdaging om MFA in de thuistenant te voltooien met behulp van een acceptabele verificatiemethode. De MFA-methode moet zijn ingeschakeld in de thuistenant en de gebruiker moet zich hiervoor kunnen registreren.
- Als de MFA-vertrouwensrelatie is uitgeschakeld, biedt Microsoft Entra-id de gebruiker een uitdaging om MFA in de resourcetenant te voltooien met behulp van een acceptabele verificatiemethode. (Zie Tabel 1 voor verificatiemethoden die acceptabel zijn voor MFA-uitvoering door een externe gebruiker.)
Als de gebruiker MFA niet kan voltooien of als een beleid voor voorwaardelijke toegang (zoals een compatibel apparaatbeleid) voorkomt dat ze zich registreren, wordt de toegang geblokkeerd.
Apparaatnaleving en hybride apparaatbeleid voor Microsoft Entra
Organisaties kunnen beleid voor voorwaardelijke toegang gebruiken om te vereisen dat apparaten van gebruikers worden beheerd door Microsoft Intune. Dergelijke beleidsregels kunnen de toegang van externe gebruikers blokkeren, omdat een externe gebruiker zijn of haar niet-beheerde apparaat niet kan registreren bij de bronorganisatie. Apparaten kunnen alleen worden beheerd door de home tenant van een gebruiker.
U kunt echter instellingen voor apparaatvertrouwen gebruiken om de blokkering van externe gebruikers op te heffen terwijl u nog steeds beheerde apparaten nodig hebt. In uw toegangsinstellingen voor meerdere tenants kunt u ervoor kiezen claims te vertrouwen van de basistenant van een externe gebruiker over of het apparaat van de gebruiker voldoet aan het nalevingsbeleid voor apparaten of dat microsoft Entra hybride is gekoppeld. U kunt instellingen voor apparaatvertrouwen instellen voor alle Microsoft Entra-organisaties of afzonderlijke organisaties.
Wanneer instellingen voor apparaatvertrouwen zijn ingeschakeld, controleert Microsoft Entra ID de verificatiesessie van een gebruiker op een apparaatclaim. Als de sessie een apparaatclaim bevat die aangeeft dat aan het beleid al is voldaan in de basistenant van de gebruiker, krijgt de externe gebruiker naadloze aanmelding bij uw gedeelde resource.
Belangrijk
- Tenzij u claims wilt vertrouwen met betrekking tot apparaatcompatibiliteit of de hybride status van Microsoft Entra vanuit de thuistenant van een externe gebruiker, raden we u niet aan om beleid voor voorwaardelijke toegang toe te passen waarvoor externe gebruikers beheerde apparaten moeten gebruiken.
Apparaatfilters
Wanneer u beleid voor voorwaardelijke toegang maakt voor externe gebruikers, kunt u een beleid evalueren op basis van de apparaatkenmerken van een geregistreerd apparaat in Microsoft Entra-id. Met behulp van het filter voor apparaatvoorwaarde kunt u specifieke apparaten richten met behulp van de ondersteunde operators en eigenschappen en de andere beschikbare toewijzingsvoorwaarden in uw beleid voor voorwaardelijke toegang.
Apparaatfilters kunnen samen met instellingen voor toegang tussen tenants worden gebruikt om beleidsregels te baseren op apparaten die in andere organisaties worden beheerd. Stel dat u apparaten van een externe Microsoft Entra-tenant wilt blokkeren op basis van een specifiek apparaatkenmerk. U kunt de volgende stappen uitvoeren om een beleid op basis van een apparaatkenmerk in te stellen:
- Configureer de toegangsinstellingen voor meerdere tenants om apparaatclaims van die organisatie te vertrouwen.
- Wijs het apparaatkenmerk toe dat u wilt gebruiken voor filteren op een van de ondersteunde extensiekenmerken van het apparaat.
- Maak een beleid voor voorwaardelijke toegang met een apparaatfilter waarmee de toegang tot apparaten met dat kenmerk wordt geblokkeerd.
Meer informatie over Filteren op apparaten met voorwaardelijke toegang.
Mobile Application Management-beleid
We raden u niet aan een app-beveiligingsbeleid te vereisen voor externe gebruikers. Voorwaardelijke toegang verleent besturingselementen zoals Goedgekeurde client-apps vereisen en Beleid voor app-beveiliging vereisen dat het apparaat wordt geregistreerd in de tenant van de bron. Deze besturingselementen kunnen alleen worden toegepast op iOS- en Android-apparaten. Omdat het apparaat van gebruikers alleen kan worden beheerd door hun home tenant, kunnen deze besturingselementen niet worden toegepast op externe gastgebruikers.
Voorwaardelijke toegang op basis van locatie
Het Beleid op basis van locatie op basis van IP-bereik kan worden afgedwongen als de uitnodigende organisatie een vertrouwd IP-adresbereik kan maken dat zijnde bijhorende partnerorganisaties definieert.
Beleidsregels kunnen ook worden afgedwongen op basis van geografische locaties.
Voorwaardelijke toegang op basis van risico's
Het Beleid voor aanmeldingsrisico's wordt afgedwongen als de externe gastgebruiker voldoet aan het toekenningsbeheer. Een organisatie kan bijvoorbeeld meervoudige verificatie van Microsoft Entra vereisen voor gemiddeld of hoog aanmeldingsrisico. Als een gebruiker zich echter nog niet eerder heeft geregistreerd voor Meervoudige Verificatie van Microsoft Entra in de resourcetenant, wordt de gebruiker geblokkeerd. Dit wordt gedaan om te voorkomen dat kwaadwillende gebruikers hun eigen Referenties voor meervoudige verificatie van Microsoft Entra registreren in het geval dat ze inbreuk maken op het wachtwoord van een legitieme gebruiker.
Het Beleid voor gebruikersrisico's kan echter niet worden opgelost in de tenant van de bron. Als u bijvoorbeeld een wachtwoordwijziging nodig hebt voor externe gastgebruikers met een hoog risico, worden ze geblokkeerd vanwege het niet opnieuw instellen van wachtwoorden in de resourcemap.
Voorwaarde voor client-apps voor voorwaardelijke toegang
Voorwaarden voor client-apps gedragen zich hetzelfde voor B2B-gastgebruikers als voor elk ander type gebruiker. U kunt bijvoorbeeld voorkomen dat gastgebruikers verouderde verificatieprotocollen gebruiken.
Besturingselementen voor voorwaardelijke toegangsessie
Besturingselementen voor sessies gedragen zich hetzelfde voor B2B-gastgebruikers als voor elk ander type gebruiker.
Beleid voor identiteitsbeveiliging en gebruikersrisico's
Identity Protection detecteert gecompromitteerde referenties voor Microsoft Entra-gebruikers en markeert gebruikersaccounts die mogelijk worden aangetast als 'risico'. Als resourcetenant kunt u beleid voor gebruikersrisico's toepassen op externe gebruikers om riskante aanmeldingen te blokkeren. Voor een externe gebruiker wordt het gebruikersrisico geëvalueerd in de basismap. Het realtime aanmeldingsrisico voor deze gebruikers wordt geëvalueerd in de bronmap wanneer ze toegang proberen te krijgen tot de bron. Omdat de identiteit van een externe gebruiker echter bestaat in de basismap, gelden de volgende beperkingen:
- Als externe gebruikers het beleid voor identiteitsbeveiligingsrisico's activeert om wachtwoordherstel af te dwingen, worden ze geblokkeerd omdat ze hun wachtwoord niet opnieuw kunnen instellen in de bronorganisatie.
- Het rapport riskante gebruikers van de resourceorganisatie weerspiegelt geen externe gebruikers omdat de risicoanalyse plaatsvindt in de basismap van de externe gebruiker.
- Beheerders in de bronorganisatie kunnen een riskante externe gebruiker niet verwijderen of herstellen omdat deze geen toegang hebben tot de basismap van de B2B-gebruiker.
U kunt voorkomen dat beleid op basis van risico's van invloed is op externe gebruikers door een groep te maken in Microsoft Entra-id die alle externe gebruikers van uw organisatie bevat. Voeg deze groep vervolgens toe als uitsluiting voor uw ingebouwde beleid voor identiteitsbeveiliging voor gebruikersrisico's en aanmeldingsrisico's, en eventuele beleidsregels voor voorwaardelijke toegang die gebruikmaken van aanmeldingsrisico's als voorwaarde.
Zie voor meer informatie Identiteitsbebescherming en B2B-gebruikers.
Volgende stappen
Raadpleeg voor meer informatie de volgende artikelen: