Beschränken des Zugriffs auf einen Mandanten

Große Organisationen mit hohen Sicherheitsanforderungen, die Clouddienste wie etwa Microsoft 365 nutzen möchten, müssen sich darauf verlassen können, dass ihre Benutzer nur auf genehmigte Ressourcen zugreifen können. Zur Steuerung des Zugriffs schränken Unternehmen in der Regel Domänennamen oder IP-Adressen ein. Dieser Ansatz scheiter in einer Welt, in der Software-as-a-Service (oder SaaS)-Apps in einer öffentlichen Cloud gehostet und unter freigegebenen Domänennamen wie outlook.office.com oder login.microsoftonline.com ausgeführt werden. Die Blockierung der Adressen würde dazu führen, dass Benutzer gar nicht mehr über das Web auf Outlook zugreifen können, anstatt lediglich ihren Zugriff auf genehmigte Identitäten und Ressourcen zu beschränken.

Zur Lösung dieses Problems bietet Microsoft Entra ein Feature namens Mandanteneinschränkungen. Mithilfe von Mandanteneinschränkungen können Organisationen den Zugriff auf SaaS-Cloudanwendungen in Abhängigkeit von dem Microsoft Entra-Mandanten steuern, den die Anwendungen für einmaliges Anmelden verwenden. So können Sie beispielsweise den Zugriff auf die Microsoft 365-Anwendungen Ihrer Organisation ermöglichen und den Zugriff auf Instanzen der gleichen Anwendungen anderer Organisationen verhindern.

Mit Mandanteneinschränkungen können Organisationen eine Liste mit Mandanten angeben, auf die Benutzer in ihrem Netzwerk zugreifen dürfen. Microsoft Entra ID gewährt dann nur Zugriff auf diese zulässigen Mandanten. Alle anderen Mandanten werden blockiert, auch solche, in denen die Benutzer eventuell Gäste sind.

In diesem Artikel liegt der Schwerpunkt auf Mandanteneinschränkungen für Microsoft 365, aber das Feature schützt alle Apps, die den Benutzer zum einmaligen Anmelden an Microsoft Entra ID senden. Wenn Sie SaaS-Apps mit einem Microsoft Entra-Mandanten verwenden, der nicht dem von Microsoft 365 verwendeten Mandanten entspricht, müssen Sie sicherstellen, dass alle erforderlichen Mandanten zugelassen sind. (Zum Beispiel in B2B-Zusammenarbeitsszenarien). Weitere Informationen zu SaaS-Cloud-Apps finden Sie im Active Directory Marketplace.

Die Funktion für Mandanteneinschränkungen unterstützt auch das Blockieren der Verwendung aller Microsoft-Consumeranwendungen (MSA-Apps), wie z. B. OneDrive, Hotmail und Xbox.com. Diese Funktionalität verwendet einen separaten Header zum login.live.com-Endpunkt und wird am Ende dieses Artikels ausführlich erläutert.

Funktionsweise

Die Lösung umfasst folgende Komponenten:

1. Microsoft Entra ID: Wenn der Restrict-Access-To-Tenants: <permitted tenant list>-Header vorhanden ist, gibt Microsoft Entra nur Sicherheitstoken für die zulässigen Mandanten aus.

2. Lokale Proxyserver-Infrastruktur: Bei dieser Infrastruktur handelt es sich um ein Proxygerät, das zur TLS-Überprüfung (Transport Layer Security) geeignet ist. Sie müssen den Proxy so konfigurieren, dass er den Header mit der Liste der zulässigen Mandanten in den für Microsoft Entra ID bestimmten Datenverkehr einfügt.

3. Clientsoftware: Zur Unterstützung von Mandanteneinschränkungen muss Clientsoftware Token direkt von Microsoft Entra ID anfordern, damit Datenverkehr von der Proxyinfrastruktur abgefangen werden kann. Browserbasierte Microsoft 365-Anwendungen unterstützen derzeit Mandanteneinschränkungen, ebenso wie Office-Clients, die eine moderne Authentifizierung verwenden (wie OAuth 2.0).

4. Moderne Authentifizierung: Clouddienste müssen eine moderne Authentifizierung verwenden, um Mandanteneinschränkungen nutzen und den Zugriff auf nicht zugelassene Mandanten blockieren zu können. Microsoft 365-Clouddienste müssen so konfiguriert werden, dass sie standardmäßig moderne Authentifizierungsprotokolle verwenden. Aktuelle Informationen zur Unterstützung von moderner Authentifizierung in Microsoft 365 finden Sie unter Office 2013: Public Preview für moderne Authentifizierung angekündigt.

Das folgende Diagramm veranschaulicht den allgemeinen Datenverkehrsfluss. Mandanteneinschränkungen erfordern die TLS-Überprüfung nur bei Datenverkehr für Microsoft Entra ID, nicht bei Datenverkehr für die Microsoft 365-Clouddienste. Diese Unterscheidung ist wichtig, da der durch die Authentifizierung bedingte Datenverkehr für Microsoft Entra ID in der Regel erheblich geringer ausfällt als der Datenverkehr für SaaS-Anwendungen wie Exchange Online und SharePoint Online.

Einrichten von Mandanteneinschränkungen

Für die Verwendung von Mandanteneinschränkungen sind zunächst zwei Schritte erforderlich. Stellen Sie zunächst sicher, dass Ihre Clients eine Verbindung mit den richtigen Adressen herstellen können. Konfigurieren Sie dann Ihre Proxyinfrastruktur.

URLs und IP-Adressen

Um Mandanteneinschränkungen zu verwenden, müssen Ihre Clients eine Verbindung mit den folgenden Microsoft Entra-URLs herstellen können, um sich zu authentifizieren:

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

Für den Zugriff auf Office 365 müssen Ihre Clients außerdem eine Verbindung mit den unter URLs und IP-Adressbereiche von Office 365 definierten vollqualifizierten Domänennamen (FQDNs), URLs und IP-Adressen herstellen können.

Proxykonfiguration und Anforderungen

Die folgende Konfiguration ist erforderlich, um Mandanteneinschränkungen über Ihre Proxyinfrastruktur zu aktivieren. Hierbei handelt es sich um einen allgemeinen Leitfaden. Spezifische Implementierungsschritte finden Sie in der Dokumentation Ihres Proxyanbieters.

Voraussetzungen

• Der Proxy muss TLS abfangen, HTTP-Header einfügen und Ziele unter Verwendung von FQDNs/URLs filtern können.

• Clients müssen der Zertifikatkette vertrauen, die vom Proxy für die TLS-Kommunikation präsentiert wird. Wenn also z. B. Zertifikate einer internen PKI (Public Key-Infrastruktur) verwendet werden, muss dem Zertifikat der internen ausstellenden Stammzertifizierungsstelle vertraut werden.

• Microsoft Entra ID P1- oder P2 -Lizenzen sind für die Verwendung von Mandanteneinschränkungen erforderlich.

Konfiguration

Fügen Sie für jede ausgehende Anforderung für login.microsoftonline.com, login.microsoft.com und login.windows.net zwei HTTP.Header ein: Restrict-Access-To-Tenants und Restrict-Access-Context.

Hinweis

Fügen Sie in der Proxykonfiguration unter *.login.microsoftonline.com keine Unterdomänen ein. Dies wird device.login.microsoftonline.com einschließen und die Client-Zertifikatsauthentifizierung beeinträchtigen, die in Szenarien mit Geräteregistrierung und gerätebasiertem bedingtem Zugriff verwendet wird. Konfigurieren Sie Ihren Proxyserver, um device.login.microsoftonline.com und enterpriseregistration.windows.net von TLSI (TLS break-and-inspect) und der Headerinjektion auszuschließen.

Die Header müssen folgende Elemente enthalten:

• Restrict-Access-To-Tenants: Verwenden Sie einen Wert für <Liste mit zugelassenen Mandanten>. Hierbei handelt es sich um eine kommagetrennte Liste mit Mandanten, auf die Benutzer zugreifen können sollen. Jede Domäne, die für einen Mandanten registriert ist, kann zur Identifizierung des Mandanten in dieser Liste und der Verzeichnis-ID selbst verwendet werden. In einem Beispiel aller drei Möglichkeiten, einen Mandanten zu beschreiben, sieht das Name-Wert-Paar, um Contoso, Fabrikam und Microsoft zuzulassen, folgendermaßen aus: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,aaaabbbb-0000-cccc-1111-dddd2222eeee.

• Restrict-Access-Context: Verwenden Sie einen Wert für eine einzelne Verzeichnis-ID, um zu deklarieren, welcher Mandant die Mandanteneinschränkungen festlegt. Wenn Sie z. B. Contoso als den Mandanten deklarieren möchten, der die Mandanteneinschränkungsrichtlinie festlegt, sieht das Name-Wert-Paar wie folgt aus: Restrict-Access-Context: bbbbcccc-1111-dddd-2222-eeee3333ffff. Sie müssen hier Ihre eigene Verzeichnis-ID verwenden, um Protokolle für diese Authentifizierungen abzurufen. Wenn Sie eine andere Verzeichnis-ID als Ihre eigene verwenden, werden die Anmeldeprotokolle im Mandanten einer anderen Person angezeigt, wobei alle persönlichen Informationen entfernt werden. Weitere Informationen finden Sie unter Administratorerfahrung.

So suchen Sie Ihre Verzeichnis-ID:

1. Melden Sie sich beim Microsoft Entra Admin Center mindestens als ein Globaler Leser an.
2. Browsen Sie zu Identität>Übersicht>Übersicht.
3. Kopieren Sie den Wert der Mandanten-ID.

Zur Überprüfung, ob eine Verzeichnis-ID oder ein Domänenname sich auf denselben Mandanten beziehen, verwenden Sie diese ID oder Domäne anstelle von <tenant> in der folgenden URL: https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration. Wenn die Ergebnisse mit der Domäne und der ID identisch sind, beziehen sie sich auf denselben Mandanten.

Um zu verhindern, dass Benutzer ihre eigenen HTTP-Header mit nicht genehmigten Mandanten einfügen, muss der Proxy den Restrict-Access-To-Tenants-Header ersetzen, falls er in der eingehenden Anforderung bereits vorhanden ist.

Clients müssen gezwungen werden, den Proxy für alle Anforderungen an login.microsoftonline.com, login.microsoft.com und login.windows.net zu verwenden. Wenn Clients also z. B. mithilfe von PAC-Dateien zur Verwendung des Proxys angewiesen werden, sollten Endbenutzer die PAC-Dateien nicht bearbeiten oder deaktivieren können.

Die Benutzererfahrung

In diesem Abschnitt wird die Erfahrung für Endbenutzer und Administratoren erläutert.

Endbenutzererfahrung

Ein Beispielbenutzer im Netzwerk von Contoso versucht, online auf die Fabrikam-Instanz einer freigegebenen SaaS-Anwendung wie Outlook zuzugreifen. Wenn Fabrikam für die Contoso-Instanz nicht als Mandant zugelassen wurde, wird dem Benutzer eine Meldung zur Zugriffsverweigerung angezeigt. Dies Meldung zur Zugriffsverweigerung besagt, dass Sie versuchen, auf eine Ressource zuzugreifen, die zu einer Organisation gehört, die von Ihrer IT-Abteilung nicht genehmigt wurde.

Administratorerfahrung

Die Konfiguration der Mandanteneinschränkungen erfolgt zwar in der Proxyinfrastruktur des Unternehmens, Administratoren können jedoch über das Microsoft Entra Admin Center direkt auf die Mandanteneinschränkungsberichte zugreifen. So zeigen Sie die Berichte an

1. Melden Sie sich beim Microsoft Entra Admin Center mindestens als ein Globaler Leser an.
2. Browsen Sie zu Identität>Übersicht>Mandanteneinschränkungen.

Der Administrator für den Mandanten, der als Restricted-Access-Context-Mandant angegeben ist, kann sich anhand dieses Berichts über Anmeldungen informieren, die aufgrund der Mandanteneinschränkungsrichtlinie blockiert wurden (einschließlich der jeweils verwendeten Identität und der Zielverzeichnis-ID). Anmeldungen sind enthalten, wenn es sich beim Mandanten, der die Einschränkung festlegt, entweder um den Benutzermandanten oder den Ressourcenmandanten für die Anmeldung handelt.

Der Bericht enthält möglicherweise eingeschränkte Informationen (z. B. die Zielverzeichnis-ID), wenn sich ein Benutzer anmeldet, der sich in einem anderen Mandanten als dem Restricted-Access-Context-Mandanten befindet. In diesem Fall werden Benutzer identifizierende Informationen wie Name und Benutzerprinzipalname maskiert, um Benutzerdaten in anderen Mandanten zu schützen (Beispiel: "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 anstelle von Benutzernamen oder Objekt-IDs, falls erforderlich).

Genau wie bei anderen Berichten im Microsoft Entra Admin Center können Sie auch hier mithilfe von Filtern den gewünschten Umfang des Berichts angeben. Der Bericht kann nach einem bestimmten Zeitintervall, einem Benutzer, einer Anwendung, einem Client oder einem Status gefiltert werden. Wenn Sie die Schaltfläche Spalten auswählen, können Sie Daten mit einer beliebigen Kombination der folgenden Felder anzeigen:

• Benutzer – in diesem Feld können persönliche Daten entfernt werden, wenn der Wert auf 00000000-0000-0000-0000-000000000000 festgelegt ist.
• Anwendung
• Status
• Date
• Datum (UTC) (UTC bedeutet Coordinated Universal Time)
• IP-Adresse
• Client
• Benutzername – In diesem Feld können persönliche Daten entfernt werden, wenn der Wert auf {PII Removed}@domain.com festgelegt ist
• Location
• Zielmandanten-ID

Microsoft 365-Support

Zur vollständigen Unterstützung von Mandanteneinschränkungen müssen Microsoft 365-Anwendungen zwei Kriterien erfüllen:

1. Der verwendete Client muss die moderne Authentifizierung unterstützen.
2. Die moderne Authentifizierung muss als Standardauthentifizierungsprotokoll für den Clouddienst aktiviert sein.

Aktuelle Informationen zu den Office-Clients, welche die moderne Authentifizierung unterstützen, finden Sie unter Aktualisierte moderne Authentifizierung für Office 365. Diese Seite enthält außerdem Links zu Schritten, mit denen Sie die moderne Authentifizierung für bestimmte Exchange Online- und Skype for Business Online-Mandanten aktivieren können. SharePoint Online ermöglicht bereits standardmäßig die moderne Authentifizierung. Teams unterstützt nur die moderne Autorisierung, nicht aber die Legacy-Autorisierung, sodass dieses Problem der Umgehung für Teams nicht zutrifft.

Browserbasierte Microsoft 365-Anwendungen (z. B. das Office-Portal, Yammer, SharePoint-Websites, Outlook im Web) unterstützen derzeit Mandanteneinschränkungen. Thick Clients (Outlook, Skype for Business, Word, Excel, PowerPoint und andere) können Mandanteneinschränkungen nur bei Verwendung moderner Authentifizierung erzwingen.

Outlook- und Skype for Business-Clients, welche die moderne Authentifizierung unterstützen, könnten für Mandanten, bei denen die moderne Authentifizierung nicht aktiviert ist, unter Umständen weiterhin Legacy-Protokolle verwenden und dadurch die Mandanteneinschränkungen umgehen. Mandanteneinschränkungen könnten Anwendungen blockieren, die Legacy-Protokolle verwenden, wenn sie während der Authentifizierung login.microsoftonline.com, login.microsoft.com oder login.windows.net kontaktieren.

Bei Outlook unter Windows könnten Kunden ggf. Einschränkungen implementieren, die verhindern, dass Endbenutzer ihren Profilen nicht genehmigte E-Mail-Konten hinzufügen. Informationen hierzu finden Sie beispielsweise unter der Gruppenrichtlinieneinstellung Das Hinzufügen nicht standardmäßiger Exchange-Konten verhindern.

Inkompatibilität von Azure RMS und Office-Nachrichtenverschlüsselung

Die Features Azure Rights Management Service (Azure RMS) und Office-Nachrichtenverschlüsselung sind nicht mit Mandanteneinschränkungen kompatibel. Bei diesen Features müssen sich Benutzer bei anderen Mandanten anmelden, um Entschlüsselungsschlüssel für die verschlüsselten Dokumente zu erhalten. Da Mandanteneinschränkungen den Zugriff auf andere Mandanten blockieren, ist kein Zugriff auf verschlüsselte E-Mails und Dokumente möglich, die von nicht vertrauenswürdigen Mandanten an Ihre Benutzer gesendet wurden.

Testen

Wenn Sie die Mandanteneinschränkungen ausprobieren möchten, bevor Sie sie für Ihre gesamte Organisation implementieren, können Sie entweder einen hostbasierten Ansatz mit einem Tool wie Fiddler oder einen gestaffelten Rollout von Proxyeinstellungen verwenden.

Fiddler für einen hostbasierten Ansatz

Fiddler ist ein kostenloser Web-Debuggen-Proxy, mit dem Sie HTTP/HTTPS-Datenverkehr erfassen und ändern können, einschließlich des Einfügens von HTTP-Headern. Gehen Sie wie folgt vor, um Fiddler zum Testen von Mandanteneinschränkungen zu konfigurieren:

1. Laden Sie Fiddler herunter, und installieren Sie es.

2. Konfigurieren Sie Fiddler wie in dessen Hilfedokumentation beschrieben für die Entschlüsselung von HTTPS-Datenverkehr.

3. Konfigurieren Sie Fiddler mithilfe von benutzerdefinierten Regeln so, dass die Header Restrict-Access-To-Tenants und Restrict-Access-Context eingefügt werden:

   1. Wählen Sie im Fiddler Web Debugger-Tool das Menü Rules (Regeln) und anschließend Customize Rules... (Regeln anpassen...) aus, um die CustomRules-Datei zu öffnen.

   2. Fügen Sie die folgenden Zeilen zur OnBeforeRequest-Funktion hinzu. Ersetzen Sie <List of tenant identifiers> durch eine bei Ihrem Mandanten registrierte Domäne (z. B. contoso.onmicrosoft.com). Ersetzen Sie <directory ID> durch den Microsoft Entra-GUID Ihres Mandanten. Sie müssen den richtigen GUID-Bezeichner einschließen, damit die Protokolle in Ihrem Mandanten angezeigt werden.

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

   Falls Sie mehrere Mandanten zulassen möchten, trennen Sie die einzelnen Mandantennamen jeweils durch ein Komma. Beispiel:

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

4. Speichern und schließen Sie die Datei „CustomRules“.

Nachdem Sie Fiddler konfiguriert haben, können Sie Datenverkehr erfassen, indem Sie im Menü File (Datei) die Option Capture Traffic (Datenverkehr erfassen) auswählen.

Gestaffelter Rollout von Proxyeinstellungen

Abhängig von den Funktionen Ihrer Proxyinfrastruktur könnten Sie unter Umständen einen gestaffelten Rollout der Einstellungen für Ihre Benutzer durchführen. Die folgenden grundsätzlichen Optionen sollten in Betracht gezogen werden:

1. Verwenden Sie PAC-Dateien, um Testbenutzer an eine Testproxyinfrastruktur weiterzuleiten, während normale Benutzer weiterhin die Produktionsproxyinfrastruktur verwenden.
2. Einige Proxyserver unterstützen möglicherweise verschiedene Konfigurationen mit Gruppen.

Spezifische Details finden Sie in der Dokumentation Ihres Proxyservers.

Blockieren von Consumer-Anwendungen

Anwendungen von Microsoft, die sowohl Verbraucherkonten als auch Unternehmenskonten wie OneDrive unterstützen, können manchmal unter derselben URL gehostet werden. Dies bedeutet, dass Benutzer, die für Arbeitszwecke auf diese URL zugreifen müssen, auch für den persönlichen Gebrauch darauf zugreifen können. Diese Option ist nach Ihren Betriebsrichtlinien möglicherweise nicht zulässig.

Einige Organisationen versuchen, dieses Problem zu beheben, indem sie login.live.com blockieren, um persönliche Konten für die Authentifizierung zu blockieren. Diese Problembehebung hat mehrere Nachteile:

1. Durch die Blockierung von login.live.com wird die Verwendung persönlicher Konten in B2B-Gastszenarien blockiert, was für Besucher und die Zusammenarbeit nachteilig sein kann.
2. Autopilot erfordert die Verwendung von login.live.com zur Bereitstellung. Bei Intune- und Autopilot-Szenarien können Fehler auftreten, wenn login.live.com blockiert ist.
3. Organisationstelemetrie und Windows-Updates, die vom login.live.com-Dienst für Geräte-IDs abhängig sind, funktionieren nicht mehr.

Konfiguration für Consumer-Apps

Während der Restrict-Access-To-TenantsHeader als Positivliste fungiert, weist die Blockierung des Microsoft-Kontos (MSA) die Microsoft-Kontoplattform an, die Anmeldung von Benutzern bei Consumeranwendungen zu verweigern. Um dieses Signal zu senden, wird der sec-Restrict-Tenant-Access-Policy-Header über denselben Unternehmensproxy oder dieselbe Firewall wie im Abschnitt Proxykonfiguration und Anforderungen dieses Artikels beschrieben in den Datenverkehr zu login.live.com eingefügt. Der Wert des Headers muss restrict-msa sein. Wenn der Header vorhanden ist und eine Consumer-App versucht, einen Benutzer direkt anzumelden, wird diese Anmeldung blockiert.

Derzeit wird die Authentifizierung bei Consumeranwendungen nicht in den Administratorprotokollen angezeigt, da login.live.com separat von Microsoft Entra ID gehostet wird.

Was der Header blockiert und was nicht

Die restrict-msa-Richtlinie blockiert die Verwendung von Consumeranwendungen, lässt jedoch verschiedene andere Arten von Datenverkehr und Authentifizierung zu:

1. Benutzerloser Datenverkehr für Geräte. Diese Option schließt den Datenverkehr für Autopilot, Windows Update und Organisationstelemetrie ein.
2. B2B-Authentifizierung von Consumerkonten. Benutzer mit Microsoft-Konten, die zur Zusammenarbeit mit einem Mandanten eingeladen werden, authentifizieren sich bei „login.live.com“, um auf einen Ressourcenmandanten zuzugreifen.
   1. Dieser Zugriff wird mithilfe des Restrict-Access-To-Tenants-Headers gesteuert, um den Zugriff auf diesen Ressourcenmandanten zuzulassen oder zu verweigern.
3. „Passthrough“-Authentifizierung, die von vielen Azure-Apps und Office.com verwendet wird, wobei Apps Microsoft Entra ID zum Anmelden von Consumerbenutzern in einem Consumerkontext verwenden.
   1. Dieser Zugriff wird auch mit dem Restrict-Access-To-Tenants-Header gesteuert, um den Zugriff auf den speziellen „Pass-through“-Mandanten zuzulassen oder zu verweigern (f8cdef31-a31e-4b4a-93e4-5f571e91255a). Wenn dieser Mandant nicht in Ihrer Restrict-Access-To-Tenants-Liste der zulässigen Domänen angezeigt wird, blockiert Microsoft Entra ID die Anmeldung von Consumerkonten bei diesen Apps.

Plattformen, die TLSI (TLS break-and-inspect) nicht unterstützen

Mandanteneinschränkungen hängen von der Injektion einer Liste zulässiger Mandanten in den HTTPS-Header ab. Für diese Abhängigkeit ist die Transport Layer Security Inspection (TLSI) erforderlich, um den Datenverkehr zu unterbrechen und zu prüfen. In Umgebungen, in denen die Clientseite nicht in der Lage ist, den Datenverkehr zum Hinzufügen von Headern zu unterbrechen und zu untersuchen, funktionieren Mandanteneinschränkungen nicht.

Nehmen Sie das Beispiel von Android 7.0 und höher. Android hat die Handhabung vertrauenswürdiger Zertifizierungsstellen (ZS) geändert, um sicherere Standardwerte für den sicheren App-Datenverkehr bereitzustellen. Weitere Informationen finden Sie unter Änderungen an vertrauenswürdigen Zertifizierungsstellen in Android Nougat.

Gemäß der Empfehlung von Google ignorieren Microsoft-Client-Apps standardmäßig Benutzerzertifikate. Aufgrund dieser Richtlinie können solche Apps nicht mit Mandanteneinschränkungen arbeiten, da die vom Netzwerkproxy verwendeten Zertifikate im Benutzerzertifikatspeicher installiert sind, dem Client-Apps nicht vertrauen.

Für solche Umgebungen, die den Datenverkehr nicht unterbrechen und untersuchen können, um dem Header die Parameter für Mandanteneinschränkungen hinzuzufügen, können andere Features von Microsoft Entra ID Schutz bieten. Die folgende Liste enthält weitere Informationen zu solchen Microsoft Entra-Features.

• Bedingter Zugriff: Nur die Verwendung verwalteter/konformer Geräte zulassen
• Bedingter Zugriff: Verwalten des Zugriffs für Gastbenutzer/externe Benutzer
• B2B Collaboration: Einschränken von Ausgangsregeln durch mandantenübergreifenden Zugriff für dieselben Mandanten, die im Parameter „Restrict-Access-To-Tenants“ aufgeführt sind
• B2B Collaboration: Beschränken von Einladungen an B2B-Benutzer auf dieselben Domänen, die im Parameter „Restrict-Access-To-Tenants“ aufgeführt sind
• Anwendungsverwaltung: Einschränken, wie Benutzer Anwendungen zustimmen
• Intune: Anwenden der App-Richtlinie über Intune, um die Verwendung verwalteter Apps nur auf den UPN des Kontos zu beschränken, welches das Gerät registriert hat – Überprüfen Sie den Abschnitt in der Unterüberschrift Nur konfigurierte Organisationskonten in Apps zulassen.

Einige spezifische Szenarien können jedoch nur mithilfe von Mandanteneinschränkungen abgedeckt werden.

Nächste Schritte

• Lesen Sie Updated Office 365 modern authentication (Aktualisierte moderne Authentifizierung für Office 365).
• Informieren Sie sich über die URLs und IP-Adressbereiche von Office 365.