Hybridmessaginginfrastruktur mit verbesserter Sicherheit (mobiler Zugriff)

Microsoft Entra ID
Microsoft 365
Office 365

Der Artikel zeigt, wie Sie die Multi-Faktor-Authentifizierung für mobile Outlook-Clients implementieren, die auf Microsoft Exchange zugreifen. Es gibt zwei verschiedenen Architekturen, die den zwei Möglichkeiten von Microsoft Exchange entsprechen, in dem das Benutzerpostfach vorhanden ist:

Architektur (Exchange Online)

Diagramm, das eine Architektur für verbesserte Sicherheit in einem Szenario mit mobilem Zugriff auf Outlook zeigt. Das Postfach des Benutzers befindet sich in Exchange Online.

In diesem Szenario müssen Benutzer*innen einen mobilen Client verwenden, der die moderne Authentifizierung unterstützt. Es wird empfohlen, die von Microsoft unterstützte Outlook Mobile-Anwendung (Outlook für iOS/Outlook für Android) zu verwenden. Im folgenden Workflow wird Outlook Mobile verwendet.

Visio-Datei mit allen Diagrammen aus diesem Artikel herunterladen

Workflow (Exchange Online)

  1. Der oder die Benutzer*in startet die Outlook-Profilkonfiguration mit der Eingabe einer E-Mail-Adresse. Outlook Mobile stellt eine Verbindung mit dem AutoDetect-Dienst her.
  2. Der AutoDetect-Dienst stellt eine anonyme AutoDiscover v2-Anforderung an Exchange Online, um das Postfach abzurufen. Exchange Online gibt die Umleitungsantwort „302 Redirect“ zurück, die die ActiveSync-URL für das Postfach enthält und auf Exchange Online verweist. Hier finden Sie ein Beispiel für eine solche Anforderung.
  3. Da der AutoDetect-Dienst nun über Informationen zum Endpunkt des Postfachinhalts verfügt, kann er ActiveSync ohne Authentifizierung aufrufen.
  4. Exchange antwortet wie in diesem Verbindungsflow beschrieben mit der Fehlermeldung 401. Diese enthält eine Autorisierungs-URL, die den Microsoft Entra-Endpunkt identifiziert, den der Client zum Abrufen eines Zugriffstokens verwenden muss.
  5. Der AutoDetect-Dienst gibt den Microsoft Entra-Autorisierungsendpunkt an den Client zurück.
  6. Der Client stellt eine Verbindung mit Microsoft Entra ID her, um die Authentifizierung abzuschließen und Anmeldeinformationen (E-Mail-Adresse) einzugeben.
  7. Falls eine Verbunddomäne verwendet wird, wird die Anforderung an den Webanwendungsproxy umgeleitet.
  8. Der Webanwendungsproxy leitet die Authentifizierungsanforderung an AD FS weiter. Dem oder der Benutzer*in wird eine Anmeldeseite angezeigt.
  9. Der oder die Benutzer*in gibt Anmeldeinformationen ein, um die Authentifizierung abzuschließen.
  10. Die Benutzer*innen werden wieder zu Microsoft Entra ID umgeleitet.
  11. Microsoft Entra ID wendet eine Azure-Richtlinie für bedingten Zugriff an.
  12. Die Richtlinie kann Folgendes erzwingen: Einschränkungen basierend auf dem Gerätestatus der Benutzer*innen, wenn das Gerät bei Microsoft Endpoint Manager registriert ist, Anwendungsschutzrichtlinien und/oder die Multi-Faktor-Authentifizierung. Ein ausführliches Beispiel für eine solche Richtlinie finden Sie in den hier beschriebenen Implementierungsschritten.
  13. Die Benutzer*inne implementieren alle Richtlinienanforderungen und erfüllen die MFA-Anforderung.
  14. Microsoft Entra ID gibt Zugriffs- und Aktualisierungstoken an den Client zurück.
  15. Der Client verwendet das Zugriffstoken, um eine Verbindung mit Exchange Online herzustellen und den Postfachinhalt abzurufen.

Konfiguration (Exchange Online)

Sie können Zugriffsversuche auf Exchange Online ActiveSync über die Legacyauthentifizierung (rot gestrichelte Linie im Diagramm) blockieren, indem Sie eine Authentifizierungsrichtlinie erstellen, die die Legacyauthentifizierung für die von Outlook Mobile verwendeten Protokolle deaktiviert. Insbesondere müssen Sie AutoDiscover, ActiveSync und OutlookService deaktivieren. Hier sehen Sie die entsprechende Konfiguration der Authentifizierungsrichtlinie:

AllowBasicAuthAutodiscover : False

AllowBasicAuthActiveSync : False

AllowBasicAuthOutlookService : False

Nachdem Sie die Authentifizierungsrichtlinie erstellt haben, können Sie sie einer Pilotbenutzergruppe zuweisen. Nach Abschluss der Tests können Sie die Richtlinie auf alle Benutzer*innen erweitern. Um die Richtlinie auf Organisationsebene anzuwenden, verwenden Sie den Befehl Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy>. Sie müssen Exchange Online PowerShell für diese Konfiguration verwenden.

Für Verbunddomänen können Sie Active Directory-Verbunddienste (AD FS) so konfigurieren, dass die Multi-Faktor-Authentifizierung anstelle einer Richtlinie für bedingten Zugriff ausgelöst wird. Es wird jedoch empfohlen, die Verbindung zu kontrollieren und Einschränkungen für die Richtlinie für bedingten Zugriff anzuwenden.

Architektur (Exchange lokal)

Diagramm, das eine Architektur für verbesserte Sicherheit in einem Szenario mit mobilem Zugriff auf Outlook zeigt. Das Postfach des Benutzers befindet sich lokal in Exchange.

Visio-Datei mit allen Diagrammen aus diesem Artikel herunterladen

In diesem Szenario müssen Benutzer*innen einen mobilen Client verwenden, der die moderne Authentifizierung unterstützt. Diese Vorgehensweise wird unter Verwenden der modernen Hybridauthentifizierung. Es wird empfohlen, die von Microsoft unterstützte Outlook Mobile-Anwendung (Outlook für iOS/Outlook für Android) zu verwenden. Im folgenden Workflow wird Outlook Mobile verwendet.

Workflow (Exchange lokal)

  1. Der oder die Benutzer*in startet die Outlook-Profilkonfiguration mit der Eingabe einer E-Mail-Adresse. Outlook Mobile stellt eine Verbindung mit dem AutoDetect-Dienst her.
  2. Der AutoDetect-Dienst stellt eine anonyme AutoDiscover v2-Anforderung an Exchange Online, um das Postfach abzurufen.
  3. Da es sich um ein lokales Postfach handelt, gibt Exchange Online die Antwort „302 Redirect“ zurück. Diese enthält eine lokale AutoDiscover-URL, die AutoDetect zum Abrufen der ActiveSync-URL für das Postfach verwenden kann.
  4. AutoDetect verwendet die im vorherigen Schritt empfangene lokale URL, um eine anonyme AutoDiscover v2-Anforderung an eine lokale Exchange-Instanz zu stellen, um das Postfach abzurufen. Die lokale Exchange-Instanz gibt eine ActiveSync-URL für das Postfach zurück, die auf die lokale Exchange-Instanz verweist. Hier finden Sie ein Beispiel für eine solche Anforderung.
  5. Da der AutoDetect-Dienst nun über Informationen zum Endpunkt des Postfachinhalts verfügt, kann er den lokalen ActiveSync-Endpunkt ohne Authentifizierung aufrufen. Exchange antwortet wie in diesem Verbindungsflow beschrieben mit der Fehlermeldung 401. Diese enthält eine Autorisierungs-URL, die den Microsoft Entra-Endpunkt identifiziert, den der Client zum Abrufen eines Zugriffstokens verwenden muss.
  6. Der AutoDetect-Dienst gibt den Microsoft Entra-Autorisierungsendpunkt an den Client zurück.
  7. Der Client stellt eine Verbindung mit Microsoft Entra ID her, um die Authentifizierung abzuschließen und Anmeldeinformationen (E-Mail-Adresse) einzugeben.
  8. Falls eine Verbunddomäne verwendet wird, wird die Anforderung an den Webanwendungsproxy umgeleitet.
  9. Der Webanwendungsproxy leitet die Authentifizierungsanforderung an AD FS weiter. Dem oder der Benutzer*in wird eine Anmeldeseite angezeigt.
  10. Der oder die Benutzer*in gibt Anmeldeinformationen ein, um die Authentifizierung abzuschließen.
  11. Die Benutzer*innen werden wieder zu Microsoft Entra ID umgeleitet.
  12. Microsoft Entra ID wendet eine Azure-Richtlinie für bedingten Zugriff an.
  13. Die Richtlinie kann Folgendes erzwingen: Einschränkungen basierend auf dem Gerätestatus der Benutzer*innen, wenn das Gerät bei Microsoft Endpoint Manager registriert ist, Anwendungsschutzrichtlinien und/oder die Multi-Faktor-Authentifizierung. Ein ausführliches Beispiel für eine solche Richtlinie finden Sie in den hier beschriebenen Implementierungsschritten.
  14. Die Benutzer*inne implementieren alle Richtlinienanforderungen und erfüllen die MFA-Anforderung.
  15. Microsoft Entra ID gibt Zugriffs- und Aktualisierungstoken an den Client zurück.
  16. Der Client verwendet das Zugriffstoken, um eine Verbindung mit Exchange Online herzustellen und den Inhalt des lokalen Postfachs abzurufen. Der Inhalt sollte wie hier beschrieben aus dem Cache bereitgestellt werden. Um das zu erreichen, gibt der Client eine Bereitstellungsanforderung aus, die das Zugriffstoken des Benutzers bzw. der Benutzerin und den lokalen ActiveSync-Endpunkt enthält.
  17. Die Bereitstellungs-API in Exchange Online akzeptiert das bereitgestellte Token als Eingabe. Die API ruft ein zweites Tokenpaar für Zugriff und Aktualisierung ab, um über einen On-Behalf-of-Aufruf von Active Directory auf das lokale Postfach zuzugreifen. Dieses zweite Zugriffstoken gilt für Exchange Online als Client und den lokalen ActiveSync-Namespaceendpunkt als Zielgruppe.
  18. Wenn das Postfach nicht bereitgestellt wird, erstellt die Bereitstellungs-API ein Postfach.
  19. Die Bereitstellungs-API stellt eine sichere Verbindung mit dem lokalen ActiveSync-Endpunkt her. Die API synchronisiert die Messagingdaten des Benutzers bzw. der Benutzerin mithilfe des zweiten Zugriffstokens als Authentifizierungsmechanismus. Das Aktualisierungstoken wird regelmäßig verwendet, um ein neues Zugriffstoken zu generieren, damit Daten ohne Benutzereingriff im Hintergrund synchronisiert werden können.
  20. Die Daten werden an den Client zurückgegeben.

Konfiguration (Exchange lokal)

Sie können Zugriffsversuche auf eine lokale Exchange ActiveSync-Instanz über die Legacyauthentifizierung (rot gestrichelte Linien im Diagramm) blockieren, indem Sie eine Authentifizierungsrichtlinie erstellen, die die Legacyauthentifizierung für die von Outlook Mobile verwendeten Protokolle deaktiviert. Insbesondere müssen Sie AutoDiscover und ActiveSync deaktivieren. Hier sehen Sie die entsprechende Konfiguration der Authentifizierungsrichtlinie:

BlockLegacyAuthAutodiscover: True

BlockLegacyAuthActiveSync: True

Hier sehen Sie einen Beispielbefehl zum Erstellen dieser Authentifizierungsrichtlinie:

New-AuthenticationPolicy -Name BlockLegacyActiveSyncAuth -BlockLegacyAuthActiveSync -BlockLegacyAuthAutodiscover

Nachdem Sie die Authentifizierungsrichtlinie erstellt haben, können Sie sie zunächst mit dem Befehl Set-User user01 -AuthenticationPolicy <name_of_policy> einer Pilotbenutzergruppe zuweisen. Nach Abschluss der Tests können Sie die Richtlinie auf alle Benutzer*innen erweitern. Um die Richtlinie auf Organisationsebene anzuwenden, verwenden Sie den Befehl Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy>. Sie müssen eine lokale Exchange PowerShell-Instanz für diese Konfiguration verwenden.

Sie müssen auch Maßnahmen ergreifen, um Konsistenz zu erzielen und den Zugriff ausschließlich über den Outlook-Client zuzulassen. Sie können Outlook Mobile als einzigen genehmigten Client für die Organisation festlegen, indem Sie Verbindungsversuche von anderen Clients als Outlook Mobile blockieren, die die moderne Authentifizierung unterstützen. Befolgen Sie diese Schritte, um solche Versuche für eine lokale Exchange-Instanz zu blockieren:

  • Andere Clients für mobile Geräte blockieren:

    Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Block

  • Verbindung von Exchange Online mit einer lokalen Umgebung zulassen:

    If ((Get-ActiveSyncOrganizationSettings).DefaultAccessLevel -ne "Allow") {New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "OutlookService" -AccessLevel Allow}

  • Standardauthentifizierung für Outlook für iOS und Outlook für Android blockieren:

    New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Block

Weitere Informationen zu diesen Schritten finden Sie unter Verwenden der modernen Hybridauthentifizierung mit Outlook für iOS und Outlook für Android.

Für Verbunddomänen können Sie Active Directory-Verbunddienste (AD FS) so konfigurieren, dass die Multi-Faktor-Authentifizierung anstelle einer Richtlinie für bedingten Zugriff ausgelöst wird. Es wird jedoch empfohlen, die Verbindung zu kontrollieren und Einschränkungen für die Richtlinie für bedingten Zugriff anzuwenden.

Komponenten

  • Microsoft Entra ID. Microsoft Entra ID ist ein cloudbasierter Identitäts- und Zugriffsverwaltungsdienst von Microsoft. Er ermöglicht eine moderne Authentifizierung, die im Wesentlichen auf EvoSTS basiert (einem von Microsoft Entra ID verwendeten Sicherheitstokendienst). Er wird als Authentifizierungsserver für lokale Exchange Server-Instanzen verwendet.
  • Microsoft Entra-Multi-Faktor-Authentifizierung. Die Multi-Faktor-Authentifizierung ist ein Prozess, bei dem Benutzer*innen während des Anmeldevorgangs zur Durchführung eines weiteren Identifizierungsverfahrens aufgefordert werden, z. B. per Eingabe eines Codes auf dem Smartphone oder per Fingerabdruckscan.
  • Bedingter Microsoft Entra-Zugriff. Der bedingte Zugriff ist ein Feature, mit dem Microsoft Entra ID Organisationsrichtlinien wie die Multi-Faktor-Authentifizierung erzwingt.
  • AD FS: AD FS ermöglicht die Identitäts- und Zugriffsverwaltung im Verbund, indem digitale Identitäten und Berechtigungen auch jenseits von Sicherheits- und Unternehmensgrenzen mit verbesserter Sicherheit geteilt werden. In diesen Architekturen wird der Dienst eingesetzt, um die Anmeldung von Benutzer*innen mit Verbundidentitäten zu vereinfachen.
  • Webanwendungsproxy: Der Webanwendungsproxy authentifiziert den Zugriff auf Webanwendungen vorab mit AD FS. Sie fungiert auch als AD FS-Proxy.
  • Microsoft Intune. Intune ist unsere cloudbasierte einheitliche Endpunktverwaltungslösung, die Endpunkte für Windows-, Android-, Mac-, iOS- und Linux-Betriebssysteme verwaltet.
  • Exchange Server: Exchange Server hostet lokale Benutzerpostfächer. In diesen Architekturen werden Token verwendet, die Benutzer*innen von Microsoft Entra ID ausgestellt werden, um den Zugriff auf Postfächer zu autorisieren.
  • Active Directory-Dienste: Active Directory-Dienste speichern Informationen zu Mitgliedern einer Domäne, einschließlich Geräten und Benutzer*innen. In diesen Architekturen gehören Benutzerkonten zu Active Directory-Diensten und werden mit Microsoft Entra ID synchronisiert.

Alternativen

Sie können mobile Clients von Drittanbietern als Alternative zu Outlook verwenden, die die moderne Authentifizierung unterstützen. Wenn Sie sich für diese Alternative entscheiden, ist der Drittanbieter für den Client-Support verantwortlich.

Szenariodetails

Enterprise Messaging Infrastructure (EMI) ist ein wichtiger Dienst für Organisationen. Der Wechsel von älteren, weniger sicheren Authentifizierungs- und Autorisierungsmethoden zu einer modernen Authentifizierung ist ein wichtiger Schritt in einer Welt, in der Remotearbeit üblich ist. Die Implementierung von MFA-Voraussetzungen für den Zugriff auf Messagingdienste ist eine der effektivsten Methoden, um dieses Ziel zu erreichen.

In diesem Artikel werden zwei Architekturen vorgestellt, mit denen Sie die Sicherheit in einem Szenario für den mobilen Zugriff auf Outlook mithilfe der Microsoft Entra-Multi-Faktor-Authentifizierung erhöhen können.

In diesem Artikel werden die folgenden Szenarios erläutert:

  • Mobiler Zugriff auf Outlook, wenn sich das Benutzerpostfach in Exchange Online befindet
  • Mobiler Zugriff auf Outlook, wenn sich das Benutzerpostfach in einer lokalen Exchange-Instanz befindet

Beide Architekturen sind für Outlook für iOS und Outlook für Android geeignet.

Informationen zum Anwenden der Multi-Faktor-Authentifizierung in anderen Hybridmessagingszenarios finden Sie in den folgenden Artikeln:

Andere Protokolle wie IMAP oder POP werden in diesem Artikel nicht behandelt. In der Regel werden diese Protokolle in solchen Szenarios nicht verwendet.

Allgemeine Hinweise

  • Diese Architekturen verwenden das Verbundidentitätsmodell von Microsoft Entra. Die Logik und der Ablauf für die Kennwort-Hashsynchronisierung und die Passthrough-Authentifizierung sind identisch. Der einzige Unterschied besteht darin, dass Microsoft Entra ID die Authentifizierungsanforderung nicht an lokale Active Directory-Verbunddienste (Active Directory Federation Services, AD FS) umleitet.
  • In den Diagrammen stehen schwarze gestrichelte Linien für Standardinteraktionen zwischen dem lokalen Active Directory, Microsoft Entra Connect, Microsoft Entra ID, Active Directory-Verbunddienste (AD FS) und Webanwendungsproxy-Komponenten. Weitere Informationen zu diesen Interaktionen finden Sie unter Erforderliche Ports und Protokolle für Hybrididentitäten.
  • Mit lokale Exchange-Instanz ist Exchange 2019 mit den neuesten Updates und der Rolle „Postfach“ gemeint.
  • In einer realen Umgebung ist nicht nur ein Server vorhanden. Sie besitzen eine Reihe von Exchange-Servern mit Lastenausgleich, um Hochverfügbarkeit zu gewährleisten. Die hier beschriebenen Szenarios eignen sich für diese Konfiguration.

Mögliche Anwendungsfälle

Diese Architektur ist für die folgenden Szenarios relevant:

  • Verbesserung der EMI-Sicherheit
  • Einführung einer Zero-Trust-Sicherheitsstrategie
  • Anwendung hoher Sicherheitsstandards für Ihren lokalen Messagingdienst während des Übergangs zu Exchange Online oder bei parallelem Betrieb mit Exchange Online
  • Erzwingung von strengen Sicherheits- oder Complianceanforderungen in geschlossenen Organisationen oder Organisationen mit höchsten Sicherheitsvorschriften wie in der Finanzbranche

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Verfügbarkeit

Die allgemeine Verfügbarkeit hängt von der Verfügbarkeit der beteiligten Komponenten ab. Informationen zur Verfügbarkeit finden Sie in den folgenden Artikeln:

Die Verfügbarkeit lokaler Lösungskomponenten hängt vom implementierten Design, der Hardwareverfügbarkeit und den internen Betriebs- und Wartungsroutinen ab. Informationen zur Verfügbarkeit einiger dieser Komponenten finden Sie in den folgenden Artikeln:

Damit Sie die moderne Hybridauthentifizierung verwenden können, müssen alle Clients in Ihrem Netzwerk auf Microsoft Entra ID zugreifen können. Außerdem müssen Sie die Firewallports und geöffneten IP-Adressbereiche für Office 365 permanent verwalten.

Weitere Informationen zu Protokoll- und Portanforderungen für Exchange Server finden Sie im Abschnitt „Anforderungen für Exchange-Clients und -Protokolle“ unter Moderne Hybridauthentifizierung: Übersicht und Voraussetzungen für die Verwendung mit lokalen Skype for Business- und Exchange-Servern.

Die IP-Adressbereiche und Ports für Office 365 finden Sie unter Office 365-URLs und -IP-Adressbereiche.

Weitere Informationen zur modernen Hybridauthentifizierung und mobilen Geräten finden Sie im Abschnitt zu AutoDetect-Endpunkten unter Andere nicht im IP-Adressbereich und URL-Webdienst für Office 365 enthaltene Endpunkte.

Resilienz

Weitere Informationen zur Resilienz der Komponenten in dieser Architektur finden Sie in den folgenden Artikeln:

Sicherheit

Allgemeine Informationen zur Sicherheit mobiler Geräte finden Sie unter Schützen von Daten und Geräten mit Microsoft Intune.

Weitere Informationen zu Sicherheit und zur modernen Hybridauthentifizierung finden Sie unter Ausführliche Erläuterung der Funktionsweise der Hybridauthentifizierung.

Geschlossene Organisationen, die den üblichen starken Perimeterschutz anwenden, müssen einige Sicherheitsbedenken zu klassischen Exchange-Hybridkonfigurationen beachten. Die moderne Exchange-Hybridkonfiguration unterstützt die moderne Hybridauthentifizierung nicht.

Informationen zu Microsoft Entra ID finden Sie unter Leitfaden für Microsoft Entra-SecOps.

Weitere Informationen zu Szenarios mit AD FS-Sicherheit finden Sie in den folgenden Artikeln:

Kostenoptimierung

Die Kosten für Ihre Implementierung hängen von Ihren Microsoft Entra ID- und Microsoft 365-Lizenzkosten ab. Die Gesamtkosten umfassen auch die Kosten für Software und Hardware für lokale Komponenten, den IT-Betrieb, Schulungen und Projektimplementierung.

Für diese Lösungen ist mindestens Microsoft Entra ID P1 erforderlich. Informationen zu den Preisen finden Sie unter Microsoft Entra-Preise.

Weitere Informationen zu den Preisen für AD FS und den Webanwendungsproxy finden Sie unter Preise und Lizenzierungsoptionen für Windows Server 2022.

Weitere Preisinformationen finden Sie in den folgenden Ressourcen:

Effiziente Leistung

Die Leistung hängt von der Leistung der beteiligten Komponenten und des Unternehmensnetzwerks ab. Weitere Informationen finden Sie unter Leistungsoptimierung für Office 365 mithilfe von Baselines und Leistungsverlauf.

Weitere Informationen zu lokalen Faktoren, die die Leistung in AD FS-Szenarios beeinflussen, finden Sie in den folgenden Artikeln:

Skalierbarkeit

Weitere Informationen zur Skalierbarkeit von AD FS finden Sie unter Planen der AD FS-Serverkapazität.

Weitere Informationen zur Skalierbarkeit von lokalen Exchange Server-Instanzen finden Sie unter Bevorzugte Architektur für Exchange 2019.

Bereitstellen dieses Szenarios

Befolgen Sie die Schritte in den folgenden Artikeln, um diese Infrastruktur zu implementieren. Die allgemeinen Schritte sind folgende:

  1. Schützen Sie den mobilen Zugriff auf Outlook wie in diesen Implementierungsschritten für die moderne Authentifizierung beschrieben.
  2. Blockieren Sie alle anderen Authentifizierungsversuche über Legacymethoden auf der Microsoft Entra ID-Ebene.
  3. Blockieren Sie Authentifizierungsversuche über Legacymethoden auf Messagingdienstebene, indem Sie Authentifizierungsrichtlinien anwenden.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte