Begränsa åtkomsten 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 fungerar inte i en värld där saaS-appar (programvara som en tjänst) finns i ett offentligt moln och körs på delade domännamn som outlook.office.com och login.microsoftonline.com. Om du blockerar dessa adresser kan användarna inte komma åt Outlook på webben helt, i stället för att bara begränsa dem till godkända identiteter och resurser.

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

Med klientbegränsningar kan organisationer ange en lista över klienter som deras användare har behörighet att komma åt. Azure AD beviljar sedan endast åtkomst till dessa tillåtna klienter.

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

Dessutom stöder funktionen för klientbegränsningar nu blockera användningen av alla Microsoft-konsumentprogram (MSA-appar), till exempel OneDrive, Hotmail och Xbox.com. Detta använder ett separat sidhuvud login.live.com till slutpunkten och beskrivs i slutet av dokumentet.

Så här fungerar det

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

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

2. Infrastruktur för lokal proxyserver: Den här infrastrukturen är en proxyenhet som kan Transport Layer Security (TLS)-kontroll. Du måste konfigurera proxyn så att den infogar huvudet som innehåller listan över tillåtna klienter i trafik till Azure AD.

3. Klientprogramvara: För att stödja klientbegränsningar måste klientprogramvaran begära token direkt från Azure AD, så att proxyinfrastrukturen kan fånga upp trafik. Webbläsarbaserade program Microsoft 365 för närvarande klientbegränsningar, vilket även Office använder modern autentisering (t.ex. 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-tjänster att använda moderna autentiseringsprotokoll som standard. Den senaste informationen om hur Microsoft 365 för modern autentisering finns i Uppdaterade Office 365 modern autentisering.

Följande diagram illustrerar trafikflödet på hög nivå. Klientbegränsningar kräver TLS-kontroll endast för trafik till Azure AD, inte Microsoft 365 molntjänster. Den här skillnaden är viktig eftersom trafikvolymen för autentisering till Azure AD 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 klienterna kan ansluta till rätt adresser. Konfigurera sedan proxyinfrastrukturen.

URL:er och IP-adresser

Om du vill använda klientbegränsningar måste klienterna kunna ansluta till följande Azure AD-URL:er för att autentisera: login.microsoftonline.com, login.microsoft.com och login.windows.net. För att få åtkomst till Office 365 måste dina klienter dessutom kunna ansluta till fullständigt kvalificerade domännamn (FQDN), URL:er och IP-adresser som definierats i Office 365-URL:er och IP-adressintervall.

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, INfogning av HTTP-huvud och filtermå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 utfärdande rotcertifikatutfärdarecertifikatet vara betrott.

• Azure AD Premium 1 licenser krävs för användning av klientbegränsningar.

Konfiguration

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

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

• För Restrict-Access-To-Tenants(Begränsa åtkomst till klienter) använder du värdet , som är en kommaavgränsad lista över klienter som du vill ge <permitted tenant list> användare åtkomst till. Alla domäner som är registrerade i en klientorganisation kan användas för att identifiera klientorganisationen i den här listan, samt själva katalog-ID:t. Ett exempel på alla tre sätt att beskriva en klientorganisation på ser namn/värde-paret ut så att Contoso, Fabrikam och Microsoft kan se ut så här: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,72f988bf-86f1-41af-91ab-2d7cd011db47

• För Restrict-Access-Context använder du ett värde för ett enskilt katalog-ID och deklarerar vilken klientorganisation som anger klientbegränsningarna. För att till exempel deklarera Contoso som den klientorganisation som anger principen för klientbegränsningar ser namn/värde-paret ut så här: Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d . 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, och all personlig information tas bort. Mer information finns i Administratörsupplevelse.

För att förhindra att användare infogar sina egna HTTP-huvuden med icke-godkända klienter måste proxyn ersätta rubriken Restrict-Access-To-Tenants om den redan finns i den inkommande begäran.

Klienter måste tvingas att använda proxyn för alla begäranden till login.microsoftonline.com, login.microsoft.com och login.windows.net. Om PAC-filer till exempel används för att dirigera klienter att använda proxyn, ska slutanvändare 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-tillåten klientorganisation för Contoso-instansen ser användaren ett meddelande om nekad åtkomst, som säger att du försöker komma åt en resurs som tillhör en organisation som inte är godkänd av IT-avdelningen.

Administratörsupplevelse

Konfiguration av klientbegränsningar görs i företagets proxyinfrastruktur, men administratörer kan komma åt rapporterna om klientbegränsningar i Azure Portal direkt. Så här visar du rapporterna:

1. Logga in på Azure Active Directory portalen. Instrumentpanelen Azure Active Directory administrationscenter visas.

2. Välj Azure Active Directory i den vänstra rutan. Sidan Azure Active Directory översikt visas.

3. På sidan Översikt väljer du Klientorganisationsbegränsningar.

Administratören för den klientorganisation som anges som klientorganisationen Restricted-Access-Context kan använda den här rapporten för att se inloggningar som blockerats på grund av principen för klientbegränsningar, inklusive den identitet som används och målkatalog-ID: t. Inloggningar ingår om klientinställningen begränsningen är antingen 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 klient än klientorganisationen Restricted-Access-Context loggar in. I det här fallet maskeras användaridentifierad information, till exempel namn och användarens huvudnamn, för att skydda användardata i andra klienter ("{PII Removed} @domain.com " eller 000000000-0000-0000-0000-000000000000 i stället för användarnamn och objekt-ID:t efter behov).

Precis som i andra Azure Portal kan du använda filter för att ange rapportens omfång. Du kan filtrera efter ett specifikt 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 de anges till 00000000-0000-0000-0000-000000000000 .
• Program
• Status
• Datum
• Datum (UTC) – där UTC är Coordinated Universal Time
• IP-adress
• Client
• Användarnamn – det här fältet kan ta bort personliga data, där det anges till {PII Removed}@domain.com
• Plats
• Målklient-ID

Microsoft 365-support

Microsoft 365 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.

Se Uppdaterad information Office 365 modern autentisering för den senaste informationen om vilka Office klienter för närvarande stöder modern autentisering. Den sidan innehåller även länkar till instruktioner för att aktivera modern autentisering på specifika Exchange Online och Skype för företag 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örbikopplingen gäller inte för Teams.

Microsoft 365 webbläsarbaserade program (Office Portal, Yammer, SharePoint-webbplatser, Outlook på webben med mera) stöder för närvarande klientbegränsningar. Tjocka klienter (Outlook, Skype för företag, Word, Excel, PowerPoint med mera) kan endast framtvinga klientbegränsningar när du använder modern autentisering.

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

För Outlook på 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 andra konton Exchange standardkonton.

Testning

Om du vill prova klientbegränsningar innan du implementerar det för hela organisationen har du två alternativ: en värdbaserad metod med hjälp av ett verktyg som Fiddler eller en mellanägd implementering 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, inklusive att infoga HTTP-huvuden. Utför följande steg för att konfigurera Fiddler för att testa klientbegränsningar:

1. Ladda ned och installera Fiddler.

2. Konfigurera Fiddler för att dekryptera HTTPS-trafik enligt Fiddlers 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 fiddler-verktyget Web Debugger väljer du menyn Regler och sedan Anpassa regler... för att öppna CustomRules-filen.

   2. Lägg till följande rader i början av OnBeforeRequest funktionen. Ersätt <List of tenant identifiers> med en domän registrerad med din klientorganisation (till exempel contoso.onmicrosoft.com ). Ersätt <directory ID> med klientens Azure AD 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 avgränsa 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.

Mellanstaderad utrullning av proxyinställningar

Beroende på funktionerna i proxyinfrastrukturen kan du mellan olika inställningar mellan olika användare. Här är några avancerade alternativ att överväga:

1. Använd PAC-filer för att peka testanvändare till en testproxyinfrastruktur, medan vanliga användare fortsätter att använda infrastrukturen för produktionsproxy.
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, till exempel OneDrive eller Microsoft Learn, kan ibland finnas på samma URL. Det innebär att användare som måste ha åtkomst till url:en i arbetet också har åtkomst till den för personligt bruk, vilket kanske inte tillåts enligt dina riktlinjer för användning.

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

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

Konfiguration för konsumentappar

Även om huvudet fungerar som en lista över tillåtna fungerar Microsoft-konto-blocket (MSA) som en neka-signal, vilket talar om för Microsoft-konto-plattformen att inte tillåta användare att logga in på Restrict-Access-To-Tenants konsumentprogram. För att skicka den här signalen sec-Restrict-Tenant-Access-Policy matas -huvudet in i trafik som besöker med login.live.com samma företagsproxy eller brandvägg som ovan. Värdet för rubriken måste vara restrict-msa . När rubriken finns och en konsumentapp försöker logga in en användare direkt blockeras den inloggningen.

För stunden visas inte autentisering till konsumentprogram i administratörsloggarna eftersomlogin.live.com värdbaserad separat från Azure AD.

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ändar mindre trafik för enheter. Detta inkluderar trafik för Autopilot, Windows Update och organisatorisk telemetri.
2. B2B-autentisering av konsumentkonton. Användare med Microsoft-konton som uppmanas att samarbeta med en klientorganisation autentiserar login.live.com för att få åtkomst till en resursklientorganisation.
   1. Den här åtkomsten styrs med Restrict-Access-To-Tenants hjälp av -huvudet för att tillåta eller neka åtkomst till den resursklientorganisationen.
3. "Genomströmningsautentisering" som används av många Azure-appar samt Office.com, där appar använder Azure AD för att logga in konsumentanvändare i en konsumentkontext.
   1. Den här åtkomsten styrs också med hjälp av -huvudet för att tillåta Restrict-Access-To-Tenants eller neka åtkomst till den särskilda "genomströmningsklienten" ( f8cdef31-a31e-4b4a-93e4-5f571e91255a ). Om den här klientorganisationen inte visas i listan över tillåtna domäner blockeras konsumentkonton av Azure AD från Restrict-Access-To-Tenants att logga in på dessa appar.

Nästa steg

• Läs mer om Office 365 modern autentisering
• Granska Office 365 URL:er och IP-adressintervall