Toegang tot een tenant beperken

Grote organisaties die de beveiliging benadrukken, willen overstappen op cloudservices zoals Microsoft 365, maar moeten weten dat hun gebruikers alleen toegang hebben tot goedgekeurde resources. Normaal gesproken beperken bedrijven domeinnamen of IP-adressen wanneer ze toegang willen beheren. Deze aanpak mislukt in een wereld waarin software als een service-apps (of SaaS)-apps worden gehost in een openbare cloud, die wordt uitgevoerd op gedeelde domeinnamen, zoals outlook.office.com en login.microsoftonline.com. Door deze adressen te blokkeren, hebben gebruikers geen toegang meer tot de webversie van Outlook, in plaats van dat ze alleen worden beperkt tot goedgekeurde identiteiten en resources.

De Microsoft Entra-oplossing voor deze uitdaging is een functie genaamd tenantbeperkingen. Met tenantbeperkingen kunnen organisaties de toegang tot SaaS-cloudtoepassingen beheren, op basis van de Microsoft Entra-tenant die de toepassingen gebruiken voor eenmalige aanmelding. U wilt bijvoorbeeld toegang verlenen tot de Microsoft 365-toepassingen van uw organisatie, terwijl u de toegang tot instanties van andere organisaties van dezelfde toepassingen voorkomt.

Met tenantbeperkingen kunnen organisaties de lijst met tenants opgeven waartoe gebruikers op hun netwerk toegang hebben. Microsoft Entra-id verleent vervolgens alleen toegang tot deze toegestane tenants. Alle andere tenants worden geblokkeerd, zelfs tenants waarin uw gebruikers mogelijk gasten zijn.

Dit artikel is gericht op tenantbeperkingen voor Microsoft 365, maar de functie beveiligt alle apps die de gebruiker naar Microsoft Entra ID verzenden voor eenmalige aanmelding. Als u SaaS-apps gebruikt met een andere Microsoft Entra-tenant dan de tenant die door uw Microsoft 365 wordt gebruikt, moet u ervoor zorgen dat alle vereiste tenants zijn toegestaan. (Bijvoorbeeld in B2B-samenwerkingsscenario's). Zie de Active Directory Marketplace voor meer informatie over SaaS-cloud-apps.

De functie tenantbeperkingen ondersteunt ook het blokkeren van het gebruik van alle Microsoft-consumententoepassingen (MSA-apps), zoals OneDrive, Hotmail en Xbox.com. Deze functionaliteit maakt gebruik van een afzonderlijke header voor het login.live.com eindpunt en wordt aan het einde van dit artikel beschreven.

Uitleg

De algehele oplossing bestaat uit de volgende onderdelen:

1. Microsoft Entra-id: Als de Restrict-Access-To-Tenants: <permitted tenant list> header aanwezig is, geeft Microsoft Entra alleen beveiligingstokens voor de toegestane tenants uit.

2. On-premises proxyserverinfrastructuur: Deze infrastructuur is een proxyapparaat dat TLS-inspectie (Transport Layer Security) kan uitvoeren. U moet de proxy configureren om de header in te voegen die de lijst met toegestane tenants bevat in verkeer dat is bestemd voor Microsoft Entra-id.

3. Clientsoftware: Om tenantbeperkingen te ondersteunen, moet clientsoftware tokens rechtstreeks aanvragen vanaf Microsoft Entra ID, zodat de proxy-infrastructuur verkeer kan onderscheppen. Browsergebaseerde Microsoft 365-toepassingen ondersteunen momenteel tenantbeperkingen, net als Office-clients die moderne verificatie gebruiken (zoals OAuth 2.0).

4. Moderne verificatie: cloudservices moeten moderne verificatie gebruiken om tenantbeperkingen te gebruiken en de toegang tot alle niet-gegenereerde tenants te blokkeren. U moet Microsoft 365-cloudservices configureren om standaard moderne verificatieprotocollen te gebruiken. Lees Moderne verificatie van bijgewerkte Office 365 moderne verificatie voor de meest recente informatie over Microsoft 365-ondersteuning voor moderne verificatie.

In het volgende diagram ziet u de architectuur van de verkeersstroom op hoog niveau. Tenantbeperkingen vereisen alleen TLS-inspectie voor verkeer naar Microsoft Entra ID, niet voor de Microsoft 365-cloudservices. Dit onderscheid is belangrijk, omdat het verkeersvolume voor verificatie bij Microsoft Entra ID doorgaans veel lager is dan het verkeersvolume naar SaaS-toepassingen zoals Exchange Online en SharePoint Online.

Tenantbeperkingen instellen

Er zijn twee stappen om aan de slag te gaan met tenantbeperkingen. Zorg er eerst voor dat uw clients verbinding kunnen maken met de juiste adressen. Daarna configureert u uw proxy-infrastructuur.

URL's en IP-adressen

Als u tenantbeperkingen wilt gebruiken, moeten uw clients verbinding kunnen maken met de volgende Microsoft Entra-URL's om te verifiëren:

• login.microsoftonline.com
• login.microsoft.com
• login.windows.net

Voor toegang tot Office 365 moeten uw clients ook verbinding kunnen maken met de FQDN's (Fully Qualified Domain Names), URL's en IP-adressen die zijn gedefinieerd in Office 365 URL's en IP-adresbereiken.

Proxyconfiguratie en -vereisten

De volgende configuratie is vereist om tenantbeperkingen in te schakelen via uw proxy-infrastructuur. Deze richtlijnen zijn algemeen, dus raadpleeg de documentatie van uw proxyleverancier voor specifieke implementatiestappen.

Vereisten

• De proxy moet TLS-interceptie, HTTP-headerinvoeging en filterbestemmingen kunnen uitvoeren met behulp van FQDN's/URL's.

• Clients moeten de certificaatketen vertrouwen die wordt gepresenteerd door de proxy voor TLS-communicatie. Als bijvoorbeeld certificaten van een interne openbare-sleutelinfrastructuur (PKI) worden gebruikt, moet het interne certificaat van de verlenende basiscertificeringsinstantie worden vertrouwd.

• Microsoft Entra ID P1- of P2-licenties zijn vereist voor het gebruik van tenantbeperkingen.

Configuratie

Voeg voor elke uitgaande aanvraag twee login.microsoft.comlogin.windows.netlogin.microsoftonline.comHTTP-headers in: Restrict-Access-To-Tenants en Restrict-Access-Context.

Notitie

Neem geen subdomeinen op onder *.login.microsoftonline.com in uw proxyconfiguratie. Als u dit doet, wordt verificatie van clientcertificaten opgenomen device.login.microsoftonline.com en beïnvloed, die wordt gebruikt in scenario's voor apparaatregistratie en voorwaardelijke toegang op basis van apparaten. Configureer uw proxyserver om TLS-onderbrekingen en -inspectie en headerinjectie uit te sluiten device.login.microsoftonline.comenterpriseregistration.windows.net en uit te sluiten.

De headers moeten de volgende elementen bevatten:

• Gebruik voor Restrict-Access-To-Tenants een waarde van <toegestane tenantlijst>. Dit is een door komma's gescheiden lijst met tenants waartoe gebruikers toegang mogen hebben. Elk domein dat is geregistreerd bij een tenant, kan worden gebruikt om de tenant in deze lijst te identificeren en de map-id zelf. Voor een voorbeeld van alle drie de manieren waarop een tenant wordt beschreven, ziet het naam-/waardepaar Contoso, Fabrikam en Microsoft er als volgt uit: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,72f988bf-86f1-41af-91ab-2d7cd011db47

• Gebruik voor Restrict-Access-Context een waarde van een enkele map-id, waarbij u aangeeft welke tenant de tenantbeperkingen instelt. Als u bijvoorbeeld Contoso wilt declareren als de tenant die het beleid voor tenantbeperkingen instelt, ziet het naam-/waardepaar er als volgt uit: Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d. U moet hier uw eigen directory-id gebruiken om logboeken voor deze verificaties op te halen. Als u een andere map-id dan uw eigen map-id gebruikt, worden de aanmeldingslogboeken *weergegeven in de tenant van iemand anders, waarbij alle persoonlijke gegevens zijn verwijderd. Zie Beheerderservaring voor meer informatie.

Ga als volgende te werk om uw map-id te vinden:

1. Meld u als globale lezer aan bij het Microsoft Entra-beheercentrum.
2. Blader naar overzicht> van identiteiten.>
3. Kopieer de waarde van de tenant-id .

Als u wilt valideren dat een map-id of domeinnaam naar dezelfde tenant verwijst, gebruikt u die id of het domein in plaats van <de tenant> in deze URL: https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration. Als de resultaten met het domein en de id hetzelfde zijn, verwijzen ze naar dezelfde tenant.

Om te voorkomen dat gebruikers hun eigen HTTP-header met niet-goedgekeurde tenants invoegen, moet de proxy de header Restrict-Access-To-Tenants vervangen als deze al aanwezig is in de binnenkomende aanvraag.

Clients moeten worden gedwongen om de proxy te gebruiken voor alle aanvragen voor login.microsoftonline.com, login.microsoft.comen login.windows.net. Als PAC-bestanden bijvoorbeeld worden gebruikt om clients aan te sturen om de proxy te gebruiken, mogen eindgebruikers de PAC-bestanden niet bewerken of uitschakelen.

De gebruikerservaring

In deze sectie wordt de ervaring voor zowel eindgebruikers als beheerders beschreven.

Ervaring voor de eindgebruiker

Een voorbeeldgebruiker bevindt zich in het Contoso-netwerk, maar probeert toegang te krijgen tot het Fabrikam-exemplaar van een gedeelde SaaS-toepassing, zoals Outlook Online. Als Fabrikam een niet-verzonden tenant is voor het Contoso-exemplaar, ziet de gebruiker een bericht over weigering van toegang. Het denial-bericht geeft aan dat u toegang probeert te krijgen tot een resource die deel uitmaakt van een organisatie die niet is goedgekeurd door uw IT-afdeling.

Beheerderservaring

Hoewel de configuratie van tenantbeperkingen wordt uitgevoerd op de infrastructuur van de bedrijfsproxy, hebben beheerders rechtstreeks toegang tot de rapporten met tenantbeperkingen in het Microsoft Entra-beheercentrum. De rapporten bekijken:

1. Meld u als globale lezer aan bij het Microsoft Entra-beheercentrum.
2. Blader naar tenantbeperkingen voor identiteitsoverzicht>>.

De beheerder voor de tenant die is opgegeven als de Restricted-Access-Context-tenant kan dit rapport gebruiken om aanmeldingen te zien die zijn geblokkeerd vanwege het beleid voor tenantbeperkingen, inclusief de identiteit die wordt gebruikt en de doelmap-id. Aanmeldingen worden opgenomen als de tenantinstelling de beperking is voor de gebruikerstenant of resourcetenant voor de aanmelding.

Het rapport kan beperkte informatie bevatten, zoals de doelmap-id, wanneer een gebruiker die zich in een andere tenant bevindt dan de tenant met beperkte toegang-context zich aanmeldt. In dit geval worden gebruikersidentificeerbare gegevens, zoals de naam en de principal-naam van de gebruiker, gemaskeerd om gebruikersgegevens in andere tenants te beveiligen (bijvoorbeeld "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 in plaats van gebruikersnamen en object-id's, indien van toepassing).

Net als andere rapporten in het Microsoft Entra-beheercentrum kunt u filters gebruiken om het bereik van uw rapport op te geven. U kunt filteren op een specifiek tijdsinterval, gebruiker, toepassing, client of status. Als u de knop Kolommen selecteert, kunt u ervoor kiezen om gegevens weer te geven met een combinatie van de volgende velden:

• Gebruiker : in dit veld kunnen persoonlijke gegevens worden verwijderd, waarbij de waarde is ingesteld op 00000000-0000-0000-0000-000000000000.
• Toepassing
• -Status
• Datum
• Datum (UTC) - waarbij UTC Coordinated Universal Time is
• IP-adres
• Client
• Gebruikersnaam : dit veld kan persoonlijke gegevens verwijderen, waarbij de waarde is ingesteld op {PII Removed}@domain.com
• Location
• Id van doeltenant

Microsoft 365-ondersteuning

Microsoft 365-toepassingen moeten voldoen aan twee criteria om tenantbeperkingen volledig te ondersteunen:

1. De gebruikte client ondersteunt moderne verificatie.
2. Moderne verificatie is ingeschakeld als het standaardverificatieprotocol voor de cloudservice.

Zie Bijgewerkte moderne office 365-verificatie voor de meest recente informatie over welke Office-clients momenteel moderne verificatie ondersteunen. Deze pagina bevat ook links naar instructies voor het inschakelen van moderne verificatie voor specifieke Exchange Online- en Skype voor Bedrijven Online-tenants. In SharePoint Online is moderne verificatie al standaard ingeschakeld. Teams biedt alleen ondersteuning voor moderne verificatie en biedt geen ondersteuning voor verouderde verificatie, dus dit probleem is niet van toepassing op Teams.

Microsoft 365-browsertoepassingen (zoals de Office-portal, Yammer, SharePoint-sites en Outlook op het web).) bieden momenteel ondersteuning voor tenantbeperkingen. 'Thick' clients (Outlook, Skype voor Bedrijven, Word, Excel, PowerPoint en meer) kunnen tenantbeperkingen alleen afdwingen bij het gebruik van moderne verificatie.

Outlook- en Skype voor Bedrijven-clients die moderne verificatie ondersteunen, kunnen mogelijk nog steeds verouderde protocollen gebruiken voor tenants waarvoor moderne verificatie niet is ingeschakeld, waardoor tenantbeperkingen effectief worden overgeslagen. Tenantbeperkingen kunnen toepassingen die gebruikmaken van verouderde protocollen blokkeren als ze contact opnemen met login.microsoftonline.com, login.microsoft.comof login.windows.net tijdens verificatie.

Voor Outlook in Windows kunnen klanten ervoor kiezen om beperkingen te implementeren waardoor eindgebruikers niet-goedgekeurde e-mailaccounts aan hun profielen kunnen toevoegen. Zie bijvoorbeeld de groepsbeleidsinstelling Voorkomen dat niet-standaard Exchange-accounts worden toegevoegd.

Incompatibiliteit van Azure RMS- en Office-berichtversleuteling

De functies Azure Rights Management Service (RMS) en Office Message Encryption zijn niet compatibel met tenantbeperkingen. Deze functies zijn afhankelijk van het aanmelden van uw gebruikers bij andere tenants om ontsleutelingssleutels voor de versleutelde documenten op te halen. Omdat tenantbeperkingen de toegang tot andere tenants blokkeren, zijn versleutelde e-mail en documenten die naar uw gebruikers worden verzonden vanuit niet-vertrouwde tenants niet toegankelijk.

Testen

Als u tenantbeperkingen wilt uitproberen voordat u deze implementeert voor uw hele organisatie, hebt u twee opties: een benadering op basis van een host met behulp van een hulpprogramma zoals Fiddler of een gefaseerde implementatie van proxy-instellingen.

Fiddler voor een benadering op basis van een host

Fiddler is een gratis webfoutopsporingsproxy die kan worden gebruikt om HTTP/HTTPS-verkeer vast te leggen en te wijzigen. Het bevat het invoegen van HTTP-headers. Voer de volgende stappen uit om Fiddler te configureren om tenantbeperkingen te testen:

1. Fiddler downloaden en installeren.

2. Configureer Fiddler om HTTPS-verkeer te ontsleutelen volgens de Help-documentatie van Fiddler.

3. Configureer Fiddler om de headers Restrict-Access-To-Tenants en Restrict-Access-Context in te voegen met behulp van aangepaste regels:

   1. Selecteer in het hulpprogramma Fiddler Web Debugger het menu Regels en selecteer Regels aanpassen... om het bestand CustomRules te openen.

   2. Voeg de volgende regels toe binnen de OnBeforeRequest functie. Vervang de <Lijst met tenant-id's> door een domein dat is geregistreerd bij uw tenant (bijvoorbeeld contoso.onmicrosoft.com). Vervang <de map-id> door de Microsoft Entra GUID-id van uw tenant. U moet de juiste GUID-id opnemen om de logboeken in uw tenant weer te geven.

    // Allows access to the listed tenants.
      if (
          oSession.HostnameIs("login.microsoftonline.com") ||
          oSession.HostnameIs("login.microsoft.com") ||
          oSession.HostnameIs("login.windows.net")
      )
      {
          oSession.oRequest["Restrict-Access-To-Tenants"] = "<List of tenant identifiers>";
          oSession.oRequest["Restrict-Access-Context"] = "<Your directory ID>";
      }
   
    // Blocks access to consumer apps
      if (
          oSession.HostnameIs("login.live.com")
      )
      {
          oSession.oRequest["sec-Restrict-Tenant-Access-Policy"] = "restrict-msa";
      }
   

   Als u meerdere tenants wilt toestaan, gebruikt u een komma om de tenantnamen te scheiden. Voorbeeld:

   oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";

4. Sla het bestand CustomRules op en sluit het.

Nadat u Fiddler hebt geconfigureerd, kunt u verkeer vastleggen door naar het menu Bestand te gaan en Verkeer vastleggen te selecteren.

Gefaseerde implementatie van proxy-instellingen

Afhankelijk van de mogelijkheden van uw proxy-infrastructuur, kunt u mogelijk de implementatie van instellingen voor uw gebruikers faseerken. Zie de volgende algemene opties voor overweging:

1. Gebruik PAC-bestanden om testgebruikers te verwijzen naar een testproxy-infrastructuur, terwijl normale gebruikers de productieproxy-infrastructuur blijven gebruiken.
2. Sommige proxyservers ondersteunen mogelijk verschillende configuraties met behulp van groepen.

Raadpleeg de documentatie van uw proxyserver voor specifieke informatie.

Consumententoepassingen blokkeren

Toepassingen van Microsoft die zowel consumentenaccounts als organisatieaccounts zoals OneDrive ondersteunen, kunnen soms worden gehost op dezelfde URL. Dit betekent dat gebruikers die toegang moeten hebben tot die URL voor werkdoeleinden, ook toegang hebben tot deze URL voor persoonlijk gebruik. Deze optie is mogelijk niet toegestaan volgens uw bedrijfsrichtlijnen.

Sommige organisaties proberen dit probleem op te lossen door te blokkeren login.live.com om te voorkomen dat persoonlijke accounts worden geverifieerd. Deze oplossing heeft verschillende nadelen:

1. Het blokkeren van login.live.com blokkeert het gebruik van persoonlijke accounts in B2B-gastscenario's, wat bezoekers en samenwerking kan verstoren.
2. Autopilot vereist het gebruik van login.live.com om te implementeren. Intune en Autopilot-scenario's kunnen mislukken wanneer login.live.com wordt geblokkeerd.
3. Organisatorische telemetrie en Windows-updates die afhankelijk zijn van de login.live.com-service voor apparaat-id's werken niet meer.

Configuratie voor consumenten-apps

Hoewel de Restrict-Access-To-Tenants-header fungeert als een acceptatielijst, werkt het MSA-blok (Microsoft-account) als een weigeringssignaal, dat het Microsoft-accountplatform vertelt dat gebruikers zich niet mogen aanmelden bij consumententoepassingen. Om dit signaal te verzenden, wordt de sec-Restrict-Tenant-Access-Policy header geïnjecteerd in het verkeer dat login.live.com gebruikmaakt van dezelfde bedrijfsproxy of firewall zoals vermeld in de sectie proxyconfiguratie en vereisten van dit artikel. De waarde van de header moet restrict-msa zijn. Wanneer de header aanwezig is en een consumenten-app probeert zich rechtstreeks aan te melden bij een gebruiker, wordt die aanmelding geblokkeerd.

Op dit moment wordt verificatie voor consumententoepassingen niet weergegeven in de beheerlogboeken, omdat login.live.com afzonderlijk van Microsoft Entra-id wordt gehost.

Wat de koptekst doet en niet blokkeert

Het restrict-msa-beleid blokkeert het gebruik van consumententoepassingen, maar staat verschillende andere typen verkeer en verificatie toe:

1. Gebruikerloos verkeer voor apparaten. Deze optie omvat verkeer voor Autopilot, Windows Update en organisatietelemetrie.
2. B2B-verificatie van consumentenaccounts. Gebruikers met Microsoft-accounts die worden uitgenodigd om samen te werken met een tenant worden geverifieerd bij login.live.com om toegang te krijgen tot een resourcetenant.
   1. Deze toegang wordt beheerd met behulp van de Restrict-Access-To-Tenants-header om toegang tot die resourcetenant toe te staan of te weigeren.
3. Passthrough-verificatie, gebruikt door veel Azure-apps en Office.com, waarbij apps Microsoft Entra-id gebruiken om consumentengebruikers aan te melden in een consumentencontext.
   1. Deze toegang wordt ook beheerd met behulp van de Restrict-Access-To-Tenants-header om toegang tot de speciale 'passthrough'-tenant (f8cdef31-a31e-4b4a-93e4-5f571e91255a) toe te staan of te weigeren. Als deze tenant niet wordt weergegeven in uw Restrict-Access-To-Tenants lijst met toegestane domeinen, blokkeert Microsoft Entra ID dat consumentenaccounts zich kunnen aanmelden bij deze apps.

Platforms die geen ondersteuning bieden voor TLS-onderbrekingen en -inspectie

Tenantbeperkingen zijn afhankelijk van de injectie van een lijst met toegestane tenants in de HTTPS-header. Voor deze afhankelijkheid is TLSI (Transport Layer Security Inspection) vereist om verkeer te onderbreken en te inspecteren. Voor omgevingen waar de clientzijde geen onderbrekingen kan maken en het verkeer kan inspecteren om headers toe te voegen, werken tenantbeperkingen niet.

Neem het voorbeeld van Android 7.0 en hoger. Android heeft de manier gewijzigd waarop vertrouwde certificeringsinstanties (CA's) worden verwerkt om veiligere standaardinstellingen te bieden voor veilig app-verkeer. Zie Wijzigingen in vertrouwde certificeringsinstanties in Android Nougat voor meer informatie.

Na de aanbeveling van Google negeren Microsoft-client-apps standaard gebruikerscertificaten. Met dit beleid kunnen dergelijke apps niet werken met tenantbeperkingen, omdat de certificaten die door de netwerkproxy worden gebruikt, worden geïnstalleerd in het certificaatarchief van de gebruiker, die client-apps niet vertrouwen.

Voor dergelijke omgevingen die geen verkeer kunnen onderbreken en inspecteren om de parameters voor tenantbeperkingen toe te voegen aan de header, kunnen andere functies van Microsoft Entra ID beveiliging bieden. De volgende lijst bevat meer informatie over dergelijke Functies van Microsoft Entra.

• Voorwaardelijke toegang: alleen het gebruik van beheerde/compatibele apparaten toestaan
• Voorwaardelijke toegang: toegang beheren voor gast-/externe gebruikers
• B2B-samenwerking: uitgaande regels beperken door toegang tussen tenants voor dezelfde tenants die worden vermeld in de parameter 'Restrict-Access-To-Tenants'
• B2B-samenwerking: uitnodigingen voor B2B-gebruikers beperken tot dezelfde domeinen die worden vermeld in de parameter 'Toegang tot tenants beperken'
• Toepassingsbeheer: beperken hoe gebruikers toestemming geven voor toepassingen
• Intune: Pas app-beleid toe via Intune om het gebruik van beheerde apps te beperken tot alleen de UPN van het account dat het apparaat heeft geregistreerd. Controleer de sectie onder Alleen geconfigureerde organisatieaccounts toestaan in subkoppen van apps .

Sommige specifieke scenario's kunnen echter alleen worden gedekt met behulp van tenantbeperkingen.

Volgende stappen

• Meer informatie over Moderne verificatie van bijgewerkte Office 365
• Bekijk de URL's en IP-adresbereiken voor Office 365