Begränsa åtkomst till en klientorganisation

Stora organisationer som betonar säkerhet vill flytta till molntjänster som Microsoft 365, men behöver veta att deras användare bara kan komma åt godkända resurser. Traditionellt begränsar företag domännamn eller IP-adresser när de vill hantera åtkomst. Den här metoden misslyckas i en värld där appar för programvara som en tjänst (eller SaaS) finns i ett offentligt moln och körs på delade domännamn som outlook.office.com och login.microsoftonline.com. Att blockera dessa adresser skulle hindra användare från att komma åt Outlook na vebu helt och hållet, i stället för att bara begränsa dem till godkända identiteter och resurser.

Microsoft Entra-lösningen på den här utmaningen är en funktion som kallas klientbegränsningar. Med klientbegränsningar kan organisationer styra åtkomsten till SaaS-molnprogram, baserat på Microsoft Entra-klientorganisationen som programmen använder för enkel inloggning. Du kanske till exempel vill tillåta åtkomst till din organisations Microsoft 365-program, samtidigt som du förhindrar åtkomst till andra organisationers instanser av samma program.

Med klientbegränsningar kan organisationer ange listan över klienter som användare i deras nätverk har behörighet att komma åt. Microsoft Entra-ID beviljar sedan endast åtkomst till dessa tillåtna klientorganisationer – alla andra klienter blockeras, även sådana som användarna kan vara gäster i.

Den här artikeln fokuserar på klientbegränsningar för Microsoft 365, men funktionen skyddar alla appar som skickar användaren till Microsoft Entra-ID för enkel inloggning. Om du använder SaaS-appar med en annan Microsoft Entra-klient från den klientorganisation som används av din Microsoft 365 kontrollerar du att alla nödvändiga klienter är tillåtna. (Till exempel i B2B-samarbetsscenarier). Mer information om SaaS-molnappar finns i Active Directory Marketplace.

Funktionen för klientbegränsningar stöder också blockering av alla Microsoft-konsumentprogram (MSA-appar ) som OneDrive, Hotmail och Xbox.com. Den här funktionen använder en separat rubrik till login.live.com slutpunkten och beskrivs i slutet av den här artikeln.

Hur det fungerar

Den övergripande lösningen består av följande komponenter:

1. Microsoft Entra-ID: Om Restrict-Access-To-Tenants: <permitted tenant list> rubriken finns utfärdar Microsoft Entra-endast säkerhetstoken för de tillåtna klienterna.

2. Lokal proxyserverinfrastruktur: Den här infrastrukturen är en proxyenhet som kan kontrolleras av TLS (Transport Layer Security). Du måste konfigurera proxyn för att infoga huvudet som innehåller listan över tillåtna klienter i trafik som är avsedd för Microsoft Entra-ID.

3. Klientprogramvara: För att stödja klientbegränsningar måste klientprogramvaran begära token direkt från Microsoft Entra-ID så att proxyinfrastrukturen kan avlyssna trafik. Webbläsarbaserade Microsoft 365-program stöder för närvarande klientbegränsningar, liksom Office-klienter som använder modern autentisering (till exempel OAuth 2.0).

4. Modern autentisering: Molntjänster måste använda modern autentisering för att använda klientbegränsningar och blockera åtkomst till alla icke-tillåtna klienter. Du måste konfigurera Microsoft 365-molntjänster att använda moderna autentiseringsprotokoll som standard. Den senaste informationen om Microsoft 365-stöd för modern autentisering finns i Uppdaterad modern Office 365-autentisering.

Följande diagram illustrerar trafikflödet på hög nivå. Klientbegränsningar kräver endast TLS-kontroll av trafik till Microsoft Entra-ID, inte till Microsoft 365-molntjänsterna. Den här skillnaden är viktig eftersom trafikvolymen för autentisering till Microsoft Entra-ID vanligtvis är mycket lägre än trafikvolymen till SaaS-program som Exchange Online och SharePoint Online.

Konfigurera klientbegränsningar

Det finns två steg för att komma igång med klientbegränsningar. Kontrollera först att dina klienter kan ansluta till rätt adresser. För det andra konfigurerar du proxyinfrastrukturen.

URL:er och IP-adresser

Om du vill använda klientbegränsningar måste dina klienter kunna ansluta till följande Microsoft Entra-URL:er för att autentisera:

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

För att få åtkomst till Office 365 måste dina klienter också kunna ansluta till de fullständigt kvalificerade domännamnen (FQDN), URL:er och IP-adresser som definierats i Url:er och IP-adressintervall för Office 365.

Proxykonfiguration och krav

Följande konfiguration krävs för att aktivera klientbegränsningar via proxyinfrastrukturen. Den här vägledningen är allmän, så du bör gå till proxyleverantörens dokumentation för specifika implementeringssteg.

Förutsättningar

• Proxyn måste kunna utföra TLS-avlyssning, HTTP-sidhuvudinfogning och filtrera mål med FQDN/URL:er.

• Klienter måste lita på certifikatkedjan som presenteras av proxyn för TLS-kommunikation. Om till exempel certifikat från en intern offentlig nyckelinfrastruktur (PKI) används måste det interna certifikatet för utfärdaren av rotcertifikatet vara betrott.

• Microsoft Entra ID P1- eller P2-licenser krävs för användning av klientbegränsningar.

Konfiguration

För varje utgående begäran till , och login.windows.net, infogar du två HTTP-huvuden: Restrict-Access-To-Tenants och Restrict-Access-Context. login.microsoft.comlogin.microsoftonline.com

Kommentar

Ta inte med underdomäner under *.login.microsoftonline.com i proxykonfigurationen. Om du gör det inkluderas device.login.microsoftonline.com och påverkas autentiseringen av klientcertifikatet, som används i scenarier med enhetsregistrering och enhetsbaserad villkorlig åtkomst. Konfigurera proxyservern så att den undantar device.login.microsoftonline.com och enterpriseregistration.windows.net från TLS-break-and-inspect och header injection.

Rubrikerna bör innehålla följande element:

• För Begränsa åtkomst till klientorganisationer använder du värdet <tillåten klientorganisationslista>, vilket är en kommaavgränsad lista över klienter som du vill tillåta användare att komma åt. Alla domäner som är registrerade med en klientorganisation kan användas för att identifiera klientorganisationen i den här listan och själva katalog-ID:t. För ett exempel på alla tre sätten att beskriva en klientorganisation ser namn/värde-paret ut så att Contoso, Fabrikam och Microsoft ser ut så här: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,aaaabbbb-0000-cccc-1111-dddd2222eeee

• För Begränsa åtkomstkontext använder du ett värde för ett enda katalog-ID och deklarerar vilken klientorganisation som anger klientbegränsningarna. Om du till exempel vill deklarera Contoso som den klientorganisation som anger principen för klientbegränsningar ser namn/värde-paret ut så här: Restrict-Access-Context: bbbbcccc-1111-dddd-2222-eeee3333ffff. Du måste använda ditt eget katalog-ID här för att hämta loggar för dessa autentiseringar. Om du använder något annat katalog-ID än ditt eget visas inloggningsloggarna *i någon annans klientorganisation, med all personlig information borttagen. Mer information finns i Administratörsupplevelse.

Så här hittar du ditt katalog-ID:

1. Logga in på administrationscentret för Microsoft Entra som minst global läsare.
2. Bläddra till Översikt över> identitet.>
3. Kopiera värdet för klientorganisations-ID.

Om du vill verifiera att ett katalog-ID eller domännamn refererar till samma klientorganisation använder du det ID:t eller domänen i stället för <klientorganisationen> i den här URL:en: https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration. Om resultatet med domänen och ID:t är desamma refererar de till samma klientorganisation.

För att förhindra att användare infogar ett eget HTTP-huvud med icke-godkända klienter måste proxyn ersätta huvudet Begränsa åtkomst till klientorganisationer om det redan finns i den inkommande begäran.

Klienter måste tvingas använda proxyn för alla begäranden till login.microsoftonline.com, login.microsoft.comoch login.windows.net. Om PAC-filer till exempel används för att dirigera klienter att använda proxyn bör slutanvändarna inte kunna redigera eller inaktivera PAC-filerna.

Användarupplevelsen

I det här avsnittet beskrivs upplevelsen för både slutanvändare och administratörer.

Slutanvändarens upplevelse

En exempelanvändare finns i Contoso-nätverket, men försöker komma åt Fabrikam-instansen av ett delat SaaS-program som Outlook online. Om Fabrikam är en icke-utelämnad klientorganisation för Contoso-instansen ser användaren ett meddelande om åtkomstnekelse. Avslagsmeddelandet säger att du försöker komma åt en resurs som tillhör en organisation som inte har godkänts av IT-avdelningen.

Administratörsupplevelse

Även om konfigurationen av klientbegränsningar utförs på företagets proxyinfrastruktur kan administratörer komma åt rapporterna om klientbegränsningar i administrationscentret för Microsoft Entra direkt. Så här visar du rapporterna:

1. Logga in på administrationscentret för Microsoft Entra som minst global läsare.
2. Bläddra till Begränsningar för identitetsöversikt>för>klientorganisation.

Administratören för klientorganisationen som anges som klientorganisation för begränsad åtkomstkontext kan använda den här rapporten för att se att inloggningar blockeras på grund av principen för klientbegränsningar, inklusive den identitet som används och målkatalog-ID:t. Inloggningar ingår om klientorganisationens inställning av begränsningen antingen är användarklientorganisationen eller resursklientorganisationen för inloggningen.

Rapporten kan innehålla begränsad information, till exempel målkatalog-ID, när en användare som är i en annan klientorganisation än klientorganisationen Restricted-Access-Context loggar in. I det här fallet maskeras användaridentifierbar information, till exempel namn och användarens huvudnamn, för att skydda användardata i andra klienter (till exempel "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 i stället för användarnamn och objekt-ID efter behov).

Precis som andra rapporter i administrationscentret för Microsoft Entra kan du använda filter för att ange rapportens omfattning. Du kan filtrera efter ett visst tidsintervall, användare, program, klient eller status. Om du väljer knappen Kolumner kan du välja att visa data med valfri kombination av följande fält:

• Användare – det här fältet kan ta bort personliga data, där värdet är inställt på 00000000-0000-0000-0000-000000000000.
• Program
• Status
• Datum
• Datum (UTC) – där UTC är samordnad universell tid
• IP-adress
• Client
• Användarnamn – det här fältet kan ta bort personliga data, där värdet är inställt på {PII Removed}@domain.com
• Plats
• Målklient-ID

Microsoft 365-support

Microsoft 365-program måste uppfylla två kriterier för att fullt ut stödja klientbegränsningar:

1. Klienten som används stöder modern autentisering.
2. Modern autentisering är aktiverat som standardautentiseringsprotokoll för molntjänsten.

Den senaste informationen om vilka Office-klienter som för närvarande stöder modern autentisering finns i Uppdaterad modern Office 365-autentisering. Den sidan innehåller även länkar till instruktioner för att aktivera modern autentisering på specifika Exchange Online- och Skype za posao Online-klienter. SharePoint Online aktiverar redan modern autentisering som standard. Teams stöder endast modern autentisering och stöder inte äldre autentisering, så den här förbikopplingsåtgärden gäller inte för Teams.

Microsoft 365 webbläsarbaserade program (till exempel Office-portalen, Yammer, SharePoint-webbplatser och Outlook på webben.) stöder för närvarande klientbegränsningar. Tjocka klienter (Outlook, Skype za posao, Word, Excel, PowerPoint med mera) kan endast tillämpa klientbegränsningar när modern autentisering används.

Outlook och Skype za posao klienter som stöder modern autentisering kanske fortfarande kan använda äldre protokoll mot klienter där modern autentisering inte är aktiverat, vilket i praktiken kringgår klientbegränsningar. Klientbegränsningar kan blockera program som använder äldre protokoll om de kontaktar login.microsoftonline.com, login.microsoft.comeller login.windows.net under autentiseringen.

För Outlook i Windows kan kunder välja att implementera begränsningar som hindrar slutanvändare från att lägga till icke-godkända e-postkonton i sina profiler. Se till exempel grupprincipinställningen Förhindra att du lägger till nondefault Exchange-konton .

Inkompatibilitet för Azure RMS och Office-meddelandekryptering

Funktionerna Azure Rights Management Service (Azure RMS) och Office Message Encryption är inte kompatibla med klientbegränsningar. Dessa funktioner förlitar sig på att logga in dina användare i andra klienter för att få dekrypteringsnycklar för de krypterade dokumenten. Eftersom klientbegränsningar blockerar åtkomsten till andra klienter är krypterad e-post och dokument som skickas till dina användare från ej betrodda klienter inte tillgängliga.

Testning

Om du vill prova klientbegränsningar innan du implementerar det för hela organisationen har du två alternativ: en värdbaserad metod med ett verktyg som Fiddler eller en stegvis distribution av proxyinställningar.

Fiddler för en värdbaserad metod

Fiddler är en kostnadsfri webbfelsökningsproxy som kan användas för att samla in och ändra HTTP/HTTPS-trafik, den innehåller infogning av HTTP-huvuden. Utför följande steg för att konfigurera Fiddler att testa klientbegränsningar:

1. Ladda ned och installera Fiddler.

2. Konfigurera Fiddler att dekryptera HTTPS-trafik enligt Fiddler hjälpdokumentation.

3. Konfigurera Fiddler för att infoga rubrikerna Restrict-Access-To-Tenants och Restrict-Access-Context med hjälp av anpassade regler:

   1. I verktyget Fiddler Web Debugger väljer du menyn Regler och väljer Anpassa regler... för att öppna Filen CustomRules.

   2. Lägg till följande rader i OnBeforeRequest funktionen. Ersätt <listan över klientidentifierare> med en domän som är registrerad hos din klientorganisation (till exempel contoso.onmicrosoft.com). Ersätt <katalog-ID> med klientorganisationens Microsoft Entra GUID-identifierare. Du måste inkludera rätt GUID-identifierare för att loggarna ska visas i din klientorganisation.

    // 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";
      }
   

   Om du behöver tillåta flera klienter använder du ett kommatecken för att separera klientnamnen. Till exempel:

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

4. Spara och stäng CustomRules-filen.

När du har konfigurerat Fiddler kan du samla in trafik genom att gå till menyn Arkiv och välja Avbilda trafik.

Stegvis distribution av proxyinställningar

Beroende på funktionerna i proxyinfrastrukturen kanske du kan mellanlagra distributionen av inställningarna till dina användare. Se följande alternativ på hög nivå för övervägande:

1. Använd PAC-filer för att peka testanvändare till en testproxyinfrastruktur, medan normala användare fortsätter att använda produktionsproxyinfrastrukturen.
2. Vissa proxyservrar kan ha stöd för olika konfigurationer med hjälp av grupper.

Mer information finns i dokumentationen för proxyservern.

Blockera konsumentprogram

Program från Microsoft som stöder både konsumentkonton och organisationskonton som OneDrive kan ibland finnas på samma URL. Det innebär att användare som måste komma åt webbadressen i arbetssyfte också har åtkomst till den för personligt bruk. Det här alternativet kanske inte är tillåtet enligt dina riktlinjer för drift.

Vissa organisationer försöker åtgärda problemet genom att blockera login.live.com för att blockera personliga konton från att autentisera. Den här korrigeringen har flera nackdelar:

1. Blockering login.live.com blockerar användningen av personliga konton i B2B-gästscenarier, vilket kan inkräkta på besökare och samarbete.
2. Autopilot kräver användning av login.live.com för att distribuera. Intune- och Autopilot-scenarier kan misslyckas när login.live.com blockeras.
3. Organisationstelemetri och Windows-uppdateringar som förlitar sig på login.live.com-tjänsten för enhets-ID: n upphör att fungera.

Konfiguration för konsumentappar

Restrict-Access-To-Tenants Även om rubriken fungerar som en tillåten lista fungerar Microsoft-kontoblocket (MSA) som en neka-signal och uppmanar Microsoft-kontoplattformen att inte tillåta användare att logga in på konsumentprogram. För att skicka den här signalen sec-Restrict-Tenant-Access-Policy matas rubriken in till trafik som besöker login.live.com med samma företagsproxy eller brandvägg som nämns i avsnittet proxykonfiguration och krav i den här artikeln. Värdet för rubriken måste vara restrict-msa. När huvudet finns och en konsumentapp försöker logga in en användare direkt blockeras inloggningen.

För närvarande visas inte autentisering till konsumentprogram i administratörsloggarna eftersom login.live.com finns separat från Microsoft Entra-ID.

Vad rubriken gör och inte blockerar

Principen restrict-msa blockerar användningen av konsumentprogram, men tillåter flera andra typer av trafik och autentisering:

1. Användarlös trafik för enheter. Det här alternativet omfattar trafik för Autopilot, Windows Update och organisationstelemetri.
2. B2B-autentisering av konsumentkonton. Användare med Microsoft-konton som bjuds in att samarbeta med en klientorganisation autentiseras för att login.live.com för att få åtkomst till en resursklient.
   1. Den här åtkomsten Restrict-Access-To-Tenants styrs med huvudet för att tillåta eller neka åtkomst till resursklientorganisationen.
3. "Direktautentisering", som används av många Azure-appar och Office.com, där appar använder Microsoft Entra-ID för att logga in konsumentanvändare i en konsumentkontext.
   1. Den här åtkomsten Restrict-Access-To-Tenants styrs också med huvudet för att tillåta eller neka åtkomst till den särskilda klientorganisationen för genomströmning (f8cdef31-a31e-4b4a-93e4-5f571e91255a). Om den här klientorganisationen inte visas i din Restrict-Access-To-Tenants lista över tillåtna domäner blockerar Microsoft Entra-ID konsumentkonton från att logga in på dessa appar.

Plattformar som inte stöder TLS-avbrott och inspektion

Klientbegränsningar beror på inmatning av en lista över tillåtna klienter i HTTPS-huvudet. Det här beroendet kräver TLSI (Transport Layer Security Inspection) för att bryta och inspektera trafiken. För miljöer där klientens sida inte kan bryta och inspektera trafiken för att lägga till rubriker fungerar inte klientbegränsningar.

Ta exemplet med Android 7.0 och senare. Android har ändrat hur de hanterar betrodda certifikatutfärdare (CA) för att tillhandahålla säkrare standardinställningar för säker apptrafik. Mer information finns i Ändringar av betrodda certifikatutfärdare i Android Nougat.

Efter rekommendationen från Google ignorerar Microsoft-klientappar användarcertifikat som standard. Den här principen gör att sådana appar inte kan fungera med klientbegränsningar eftersom de certifikat som används av nätverksproxyn är installerade i användarcertifikatarkivet, som klientappar inte litar på.

För sådana miljöer som inte kan bryta och inspektera trafik för att lägga till parametrar för klientbegränsningar i rubriken kan andra funktioner i Microsoft Entra-ID ge skydd. Följande lista innehåller mer information om sådana Microsoft Entra-funktioner.

• Villkorlig åtkomst: Tillåt endast användning av hanterade/kompatibla enheter
• Villkorlig åtkomst: Hantera åtkomst för gäst-/externa användare
• B2B-samarbete: Begränsa utgående regler efter åtkomst mellan klientorganisationer för samma klientorganisationer som anges i parametern "Begränsa åtkomst till klientorganisationer"
• B2B-samarbete: Begränsa inbjudningar till B2B-användare till samma domäner som anges i parametern "Begränsa åtkomst till klienter"
• Programhantering: Begränsa hur användarna godkänner program
• Intune: Använd appprincip via Intune för att begränsa användningen av hanterade appar till endast UPN för det konto som registrerade enheten – Kontrollera avsnittet under Tillåt endast konfigurerade organisationskonton i underrubriker för appar .

Vissa specifika scenarier kan dock bara omfattas med hjälp av klientbegränsningar.

Nästa steg

• Läs om uppdaterad modern Office 365-autentisering
• Granska URL:er och IP-adressintervall för Office 365