Authentifizierung und bedingter Zugriff für External Identities

Wenn ein externer Benutzer auf Ressourcen in Ihrer Organisation zugreift, wird der Authentifizierungsablauf durch die Zusammenarbeitsmethode (B2B-Zusammenarbeit oder direkte B2B-Verbindung), durch den Identitätsanbieter des Benutzers (ein externer Azure AD-Mandant, ein soziales Netzwerk als Identitätsanbieter oder Ähnliches), durch Richtlinien für bedingten Zugriff und durch die mandantenübergreifenden Zugriffseinstellungen bestimmt, die sowohl im Basismandanten des Benutzers als auch in den Hostingressourcen des Mandanten konfiguriert sind.

In diesem Artikel wird der Authentifizierungsablauf für externe Benutzer beschrieben, die auf Ressourcen in Ihrer Organisation zugreifen. Organisationen können mehrere Richtlinien für bedingten Zugriff für ihre externen Benutzer erzwingen. Diese Richtlinien können auf Mandanten-, App- oder Einzelbenutzerebene und auf die gleiche Weise erzwungen werden wie für Vollzeitmitarbeiter und Mitglieder der Organisation.

Authentifizierungsablauf für externe Azure AD-Benutzer

Das folgende Diagramm veranschaulicht den Authentifizierungsablauf für den Fall, dass eine Azure AD-Organisation Ressourcen für Benutzer aus anderen Azure AD-Organisationen freigibt. Dieses Diagramm zeigt, wie mithilfe von mandantenübergreifenden Zugriffseinstellungen und Richtlinien für bedingten Zugriff – beispielsweise Multi-Faktor-Authentifizierung (MFA) – bestimmt wird, ob ein Benutzer auf Ressourcen zugreifen kann. Dieser Flow gilt sowohl für die B2B-Zusammenarbeit als auch für eine direkte B2B-Verbindung, außer wie in Schritt 6 erwähnt.

Diagramm zur Darstellung des mandantenübergreifenden Authentifizierungsprozesses.

Schritt Beschreibung
1 Ein Benutzer aus Fabrikam (Basismandant des Benutzers) initiiert die Anmeldung bei einer Ressource in Contoso (Ressourcenmandant).
2 Im Rahmen der Anmeldung wertet der Azure AD-Sicherheitstokendienst (Security Token Service, STS) die Richtlinien für bedingten Zugriff von Contoso aus. Außerdem werden mandantenübergreifende Zugriffseinstellungen (Einstellungen für ausgehenden Zugriff von Fabrikam und Einstellungen für eingehenden Zugriff von Contoso) ausgewertet, um zu überprüfen, ob der Fabrikam-Benutzer Zugriff erhält.
3 Azure AD überprüft die Einstellungen für eingehende Vertrauensstellungen von Contoso, um zu ermitteln, ob Contoso MFA- und Geräteansprüchen (Gerätekonformität, Status der Einbindung als Hybridgerät in Azure AD) von Fabrikam vertraut. Falls nicht, geht es direkt zu Schritt 6.
4 Wenn Contoso MFA- und Geräteansprüchen von Fabrikam vertraut, überprüft Azure AD die Authentifizierungssitzung des Benutzers darauf, ob der Benutzer die MFA abgeschlossen hat. Wenn Contoso Geräteinformationen von Fabrikam vertraut, sucht Azure AD in der Authentifizierungssitzung nach einem Anspruch, der den Gerätestatus angibt (konform oder hybrid, in Azure AD eingebunden).
5 Wenn die MFA erforderlich ist, aber nicht abgeschlossen wurde, oder kein Geräteanspruch bereitgestellt wird, werden von Azure AD nach Bedarf MFA- und Geräteaufforderung im Basismandanten des Benutzers ausgegeben. Sind die MFA- und Geräteabfragen in Fabrikam erfolgreich, erhält der Benutzer Zugriff auf die Ressource in Contoso. Sind die Überprüfungen nicht erfolgreich, wird der Zugriff blockiert.
6 Wenn keine Vertrauenseinstellungen konfiguriert sind und MFA erforderlich ist, erhalten B2B-Zusammenarbeitsbenutzer eine MFA-Aufforderung, die im Ressourcenmandanten erfolgreich sein muss. Der Zugriff wird für Benutzer mit direkter B2B-Verbindung blockiert. Wenn eine Gerätekonformität erforderlich ist, aber nicht ausgewertet werden kann, wird der Zugriff sowohl für B2B-Zusammenarbeit als auch für Benutzer mit direkter B2B-Verbindung blockiert.

Weitere Informationen finden Sie im Abschnitt Bedingter Zugriff für externe Benutzer.

Authentifizierungsablauf für externe Benutzer ohne Azure AD

Wenn eine Azure AD-Organisation Ressourcen für externe Benutzer freigibt, die nicht Azure AD als Identitätsanbieter verwenden, hängt der Authentifizierungsablauf davon ab, ob sich der Benutzer mit einem Identitätsanbieter oder per E-Mail-Einmal-Passcode authentifiziert. In beiden Fällen identifiziert der Ressourcenmandant die zu verwendende Authentifizierungsmethode und leitet den Benutzer dann entweder zu dessen Identitätsanbieter um oder gibt einen Einmal-Passcode aus.

Beispiel 1: Authentifizierungsablauf und Token für einen externen Benutzer ohne Azure AD

Das folgende Diagramm veranschaulicht den Authentifizierungsablauf für den Fall, dass sich ein externer Benutzer mit einem Konto von einem Azure AD-fremden Identitätsanbieter wie Google oder Facebook oder von einem SAML-/WS-Fed-Verbundidentitätsanbieter anmeldet:

Diagramm des Authentifizierungsflusses für B2B-Gastbenutzer aus einem externen Verzeichnis.)

Schritt Beschreibung
1 Der B2B-Gastbenutzer fordert Zugriff auf eine Ressource an. Die Ressource leitet den Benutzer an ihren Ressourcenmandanten (vertrauenswürdiger IdP) weiter.
2 Der Ressourcenmandant identifiziert den Benutzer als „Extern“ und leitet ihn an den IdP des B2B-Gastbenutzers um. Der Benutzer führt die primäre Authentifizierung über den IdP durch.
3 Autorisierungsrichtlinien werden im IdP des B2B-Gastbenutzers ausgewertet. Wenn der Benutzer diese Richtlinien erfüllt, gibt der IdP des B2B-Gastbenutzers ein Token für den Benutzer aus. Der Benutzer wird mit dem Token zurück an den Ressourcenmandanten geleitet. Der Ressourcenmandant überprüft das Token und führt dann die Bewertung des Benutzers anhand der Richtlinien für bedingten Zugriff durch. Beispielsweise kann der Ressourcenmandant vorgeben, dass der Benutzer die MFA über Azure Active Directory (AD) durchführen muss.
4 Mandantenübergreifende Einstellungen für den eingehenden Zugriff sowie Richtlinien für bedingten Zugriff werden ausgewertet. Wenn alle Richtlinien erfüllt wurden, erstellt der Ressourcenmandant ein eigenes Token und leitet den Benutzer zur zugehörigen Ressource um.

Beispiel 2: Authentifizierungsablauf und Token für Benutzer mit Einmal-Passcode

Das folgende Diagramm veranschaulicht den Ablauf für den Fall, dass die Authentifizierung mit E-Mail-Einmal-Passcode aktiviert ist und der externe Benutzer nicht auf andere Weise – etwa per Azure AD, Microsoft-Konto (MSA) oder soziales Netzwerk als Identitätsanbieter – authentifiziert wird:

Diagramm des Authentifizierungsflusses für B2B-Gastbenutzer mit Einmal-Passcode.

Schritt Beschreibung
1 Der Benutzer fordert den Zugriff auf eine Ressource auf einem anderen Mandanten an. Die Ressource leitet den Benutzer an ihren Ressourcenmandanten (vertrauenswürdiger IdP) weiter.
2 Der Ressourcenmandant identifiziert den Benutzer als externen Benutzer mit Einmalkennung und sendet eine E-Mail mit der Einmalkennung an den Benutzer.
3 Der Benutzer ruft die Einmalkennung ab und übermittelt den Code. Der Ressourcenmandant führt die Bewertung des Benutzers anhand der Richtlinien für bedingten Zugriff durch.
4 Wenn alle Richtlinien für bedingten Zugriff erfüllt wurden, erstellt der Ressourcenmandant ein Token und leitet den Benutzer zur zugehörigen Ressource um.

Bedingter Zugriff für externe Benutzer

Organisationen können Richtlinien für den bedingten Zugriff für externe B2B-Zusammenarbeitsbenutzer und Benutzer einer direkten B2B-Verbindung auf die gleiche Weise durchsetzen wie für Vollzeitmitarbeiter und Mitglieder der Organisation. Mit der Einführung von mandantenübergreifenen Zugriffseinstellungen können Sie auch MFA- und Geräteansprüchen aus externen Azure AD-Organisationen vertrauen. In diesem Abschnitt werden wichtige Überlegungen zum Anwenden des bedingten Zugriffs auf Benutzer außerhalb Ihrer Organisation beschrieben.

Zuweisen von Richtlinien für den bedingten Zugriff an externe Benutzertypen (Vorschau)

Hinweis

In diesem Abschnitt wird eine Previewfunktion von Azure Active Directory beschrieben. Weitere Informationen zu Vorschauversionen finden Sie unter Zusätzliche Nutzungsbestimmungen für Microsoft Azure-Vorschauen.

Beim Konfigurieren einer Richtlinie für den bedingten Zugriff können Sie genau festlegen, auf welche Arten von externen Benutzern Sie die Richtlinie anwenden möchten. Externe Benutzer werden basierend auf der Art ihrer Authentifizierung (intern oder extern) und ihrer Beziehung zu Ihrer Organisation (Gast oder Mitglied) kategorisiert.

  • Gastbenutzer für die B2B-Zusammenarbeit: Die meisten Benutzer, die gemeinhin als Gäste betrachtet werden, fallen in diese Kategorie. Dieser Benutzer für die B2B-Zusammenarbeit verfügt über ein Konto in einer externen Azure AD-Organisation oder bei einem externen Identitätsanbieter (z. B. ein soziales Netzwerk als Identitätsanbieter) und verfügt in Ihrer Organisation über Berechtigungen auf Gastebene. Das in Ihrem Azure AD-Verzeichnis erstellte Benutzerobjekt weist für die Eigenschaft „UserType“ den Wert „Guest“ auf. Zu dieser Kategorie gehören Benutzer für die B2B-Zusammenarbeit, die eingeladen wurden und sich per Self-Service angemeldet haben.
  • Externer Mitgliedsbenutzer für die B2B-Zusammenarbeit: Dieser Benutzer für die B2B-Zusammenarbeit verfügt über ein Konto in einer externen Azure AD-Organisation oder bei einem externen Identitätsanbieter (z. B. ein soziales Netzwerk als Identitätsanbieter) und kann auf Gastebene auf die Ressourcen in Ihrer Organisation zugreifen. Dieses Szenario gibt es häufig in aus mehreren Mandanten bestehenden Organisationen, bei denen Benutzer als Teil der größeren Organisation betrachtet werden und Zugriff auf Mitgliedsebene benötigen, um auf Ressourcen in den anderen Mandanten der Organisation zugreifen zu können. Bei dem in der Ressource „Azure AD-Verzeichnis“ erstellten Benutzerobjekt lautet der Wert für die Eigenschaft „UserType“ gleich „Mitglied“.
  • Benutzer mit direkter B2B-Verbindung: Externe Benutzer, die über eine direkte B2B-Verbindung auf Ihre Ressourcen zugreifen können. Dabei handelt es sich um eine wechselseitige, bidirektionale Verbindung mit einer anderen Azure AD-Organisation, die den SSO-Zugriff auf bestimmte Microsoft-Anwendungen ermöglicht (derzeit über Microsoft Teams Connect freigegebene Kanäle). Benutzer mit direkter B2B-Verbindung werden nicht durch ein Objekt in Ihrer Azure AD-Organisation repräsentiert, sondern stattdessen von der Anwendung aus verwaltet (z. B. durch den Besitzer des freigegebenen Teams-Kanals).
  • Lokale Gastbenutzer: Lokale Gastbenutzer verfügen über Anmeldeinformationen, die in Ihrem Verzeichnis verwaltet werden. Bevor die Azure AD B2B-Zusammenarbeit zur Verfügung stand, war es üblich, für die Zusammenarbeit mit Vertragshändlern, Lieferanten, Anbietern usw. interne Anmeldeinformationen einzurichten und sie als Gastbenutzer einzurichten, indem das Benutzerobjekt „UserType“ auf „Guest“ festgelegt wurde.
  • Dienstanbieterbenutzer: Organisationen, die als Cloud-Dienstanbieter für Ihre Organisation dienen (die Eigenschaft „isServiceProvider“ in der partnerspezifischen Microsoft Graph-Konfiguration ist auf TRUE festgelegt).
  • Andere externe Benutzer: Alle Benutzer, die nicht in eine der oben genannten Kategorien fallen, aber auch nicht als interne Mitglieder Ihrer Organisation gelten, d. h. sie werden nicht intern über Azure AD authentifiziert und für das in der Azure AD-Verzeichnisressource erstellte Benutzerobjekt ist „UserType“ nicht auf „Member“ festgelegt.

Erfahren Sie mehr über Benutzerzuweisungen für den bedingten Zugriff.

MFA für externe Benutzer von Azure AD

In einem Azure AD-mandantenübergreifenden Szenario kann die Ressourcenorganisation Richtlinien für bedingten Zugriff erstellen, die MFA- oder Gerätekonformität für alle Gastbenutzer und externen Benutzer erfordern. Im Allgemeinen muss ein B2B-Zusammenarbeitsbenutzer, der auf eine Ressource zugreift, seinen Azure AD MFA-Dienst mit dem Ressourcenmandanten einrichten. Azure AD bietet jedoch jetzt die Möglichkeit, MFA-Ansprüche aus anderen Azure AD-Mandanten zu vertrauen. Durch das Aktivieren der MFA-Vertrauensstellung mit einem anderen Mandanten wird der Anmeldevorgang für B2B-Zusammenarbeitsbenutzer optimiert und der Zugriff für Benutzer einer direkten B2B-Verbindung ermöglicht.

Wenn Sie die Einstellungen der Vertrauensstellung für eingehenden Datenverkehr so konfiguriert haben, dass MFA-Ansprüche vom Basismandanten eines B2B-Zusammenarbeitsbenutzers oder Benutzers einer direkten B2B-Verbindung akzeptiert werden, überprüft Azure AD die Authentifizierungssitzung des Benutzers. Wenn die Sitzung einen Anspruch enthält, der angibt, dass die MFA-Richtlinien im Basismandanten des Benutzers bereits erfüllt wurden, wird dem Benutzer eine nahtlose Anmeldung an Ihrer freigegebenen Ressource gewährt.

Wenn die MFA-Vertrauensstellung nicht aktiviert ist, unterscheidet sich die Benutzeroberfläche für B2B-Zusammenarbeitsbenutzer und Benutzer einer direkten B2B-Verbindung:

  • B2B-Zusammenarbeitsbenutzer: Wenn die Ressourcenorganisation die MFA-Vertrauensstellung nicht mit dem Basismandanten des Benutzers aktiviert hat, wird dem Benutzer eine MFA-Aufforderung aus der Ressourcenorganisation angezeigt. (Der Ablauf entspicht dem MFA-Ablauf für externe Benutzer ohne Azure AD.)

  • Benutzer einer direkten B2B-Verbindung: Wenn die Ressourcenorganisation die MFA-Vertrauensstellung nicht mit dem Basismandanten des Benutzers aktiviert hat, wird der Benutzer daran gehindert, auf Ressourcen zuzugreifen. Wenn Sie eine direkte B2B-Verbindung mit einer externen Organisation zulassen möchten und Ihre Richtlinien für bedingten Zugriff MFA vorschreiben, müssen Sie Ihre Vertrauenseinstellungen für eingehenden Datenverkehr so konfigurieren, dass MFA-Ansprüche von der externen Organisation akzeptiert werden.

Erfahren Sie mehr darüber, wie die Einstellungen der Vertrauenstellung für eingehenden Datenverkehr für MFA konfiguriert werden

MFA für externe Benutzer ohne Azure AD

Bei externen Benutzern ohne Azure AD ist immer der Ressourcenmandant für die MFA zuständig. Im Anschluss folgt ein Beispiel für einen typischen MFA-Ablauf. Dieses Szenario funktioniert für jede Identität – auch für Microsoft-Konten (MSA) und für IDs aus sozialen Netzwerken. Dieser Ablauf gilt auch für externe Azure AD-Benutzer, wenn Sie keine Vertrauenseinstellungen mit deren eigener Azure AD-Organisation konfiguriert haben.

  1. Ein Administrator oder Information-Worker des Unternehmens Fabrikam lädt einen Benutzer aus einem anderen Unternehmen (Contoso) zur Nutzung der App von Fabrikam ein.

  2. Die App von Fabrikam ist so konfiguriert, dass beim Zugriff Azure AD MFA erforderlich ist.

  3. Wenn der B2B-Zusammenarbeitsbenutzer von Contoso versucht, auf die App von Fabrikam zuzugreifen, wird er aufgefordert, die Azure AD MFA-Aufforderung abzuschließen.

  4. Der Gastbenutzer kann dann seinen Azure AD MFA-Dienst mit Fabrikam einrichten und die Optionen auswählen.

Fabrikam muss über genügend Azure AD-Premium-Lizenzen mit Azure AD MFA-Unterstützung verfügen. Der Contoso-Benutzer nutzt dann diese Lizenz von Fabrikam. Informationen zur B2B-Lizenzierung finden Sie unter Abrechnungsmodell für externe Identitäten in Azure AD.

Hinweis

Die MFA wird im Ressourcenmandanten abgeschlossen, um die Vorhersagbarkeit sicherzustellen. Wenn sich der Gastbenutzer anmeldet, wird im Hintergrund die Anmeldeseite des Ressourcenmandanten angezeigt, und im Vordergrund werden die Anmeldeseite für den eigenen Basismandanten und das Unternehmenslogo angezeigt.

Azure AD MFA-Zurücksetzung (Nachweis) für B2B-Zusammenarbeitsbenutzer

Folgende PowerShell-Cmdlets stehen zum Nachweisen oder zum Anfordern der MFA-Registrierung von B2B-Zusammenarbeitsbenutzern zur Verfügung:

  1. Stellen Sie eine Verbindung mit Azure AD her:

    $cred = Get-Credential
    Connect-MsolService -Credential $cred
    
  2. Rufen Sie alle Benutzer mit Nachweismethoden ab:

    Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
    

    Beispiel:

    Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
    
  3. Setzen Sie die Azure AD MFA-Methode für einen bestimmten Benutzer zurück, damit der Benutzer erneut Nachweismethoden festlegen muss. Beispiel:

    Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.onmicrosoft.com
    

Richtlinien zur Authentifizierungsstärke für externe Benutzer

Die Authentifizierungsstärke ist ein Element der bedingten Zugriffssteuerung, mit der Sie eine bestimmte Kombination von Multi-Faktor-Authentifizierungsmethoden (MFA) definieren können, die ein externer Benutzer durchlaufen muss, um auf Ihre Ressourcen zuzugreifen. Dieses Steuerelement ist besonders nützlich, um den externen Zugriff auf vertrauliche Apps in Ihrer Organisation einzuschränken, da Sie für externe Benutzer bestimmte Authentifizierungsmethoden erzwingen können, z. B. eine Methode zum Schutz vor Phishing.

Sie haben außerdem die Möglichkeit, die Authentifizierungsstärke auf die verschiedenen Arten von Gastbenutzern oder externen Benutzern anzuwenden, mit denen Sie zusammenarbeiten oder sich verbinden. Das bedeutet, dass Sie Anforderungen an die Authentifizierungsstärke durchsetzen können, die für Ihre B2B-Zusammenarbeit, direkte B2B-Verbindungen und andere externe Zugriffsszenarien gelten.

Azure AD bietet drei integrierte Authentifizierungsstärken:

  • Stärke für Multi-Faktor-Authentifizierung
  • Stärke für kennwortlose MFA
  • Stärke für Phishing-resistente MFA

Sie können eine dieser integrierten Stärken verwenden oder eine benutzerdefinierte Richtlinie zur Authentifizierungsstärke erstellen, die auf den von Ihnen benötigten Authentifizierungsmethoden basiert.

Hinweis

Derzeit können Sie Richtlinien zur Authentifizierungsstärke nur auf externe Benutzer anwenden, die sich mit Azure AD authentifizieren. Verwenden Sie bei der Authentifizierung von Benutzern mit Einmal-Passcode per E-Mail, SAML-/WS-Fed- und Google-Verbund die MFA-Zugriffsgewährung, um die Multi-Faktor-Authentifizierung zu erzwingen.

Wenn Sie eine Richtlinie zur Authentifizierungsstärke auf externe Azure AD-Benutzer anwenden, wirkt diese Richtlinie mit MFA-Vertrauenseinstellungen in Ihren mandantenübergreifenden Zugriffseinstellungen zusammen, um zu bestimmen, wo und wie der externe Benutzer eine Multi-Faktor-Authentifizierung durchführen muss. Ein Azure AD-Benutzer authentifiziert sich zunächst mit seinem eigenen Konto bei seinem Azure AD-Basismandanten. Wenn dieser Benutzer anschließend versucht, auf Ihre Ressource zuzugreifen, wendet Azure AD die Richtlinie zur Authentifizierungsstärke für den bedingten Zugriff an und überprüft, ob Sie die MFA-Vertrauensstellung aktiviert haben.

In Szenarien mit externen Benutzern variieren die Authentifizierungsmethoden, die zur Erfüllung der Authentifizierungsstärke zulässig sind. Dies hängt davon ab, ob der Benutzer die MFA in seinem Basismandanten oder im Ressourcenmandanten durchführt. In der folgenden Tabelle sind die zulässigen Methoden für jeden Mandanten angegeben. Wenn ein Ressourcenmandant so konfiguriert ist, dass Ansprüchen von externen Azure AD-Organisationen vertraut wird, werden nur in der nachstehenden Spalte „Basismandant“ aufgeführten Ansprüche für die MFA-Erfüllung akzeptiert. Wenn die MFA-Vertrauensstellung für den Ressourcenmandanten deaktiviert wurde, muss der externe Benutzer die MFA im Ressourcenmandanten mithilfe einer der in der Spalte „Ressourcenmandant“ aufgeführten Methoden ausführen.

Tabelle 1. MFA-Methoden zur Authentifizierungsstärke für externe Benutzer
Authentifizierungsmethode Basismandant Ressourcenmandant
SMS als zweiter Faktor
Anruf
Microsoft Authenticator-Pushbenachrichtigung
Telefonische Microsoft Authenticator-Anmeldung
OATH-Softwaretoken
OATH-Hardwaretoken
FIDO2-Sicherheitsschlüssel
Windows Hello for Business

Informationen zum Konfigurieren einer Richtlinie für bedingten Zugriff zum Anwenden einer Authentifizierungsstärke auf externe Benutzer oder Gäste finden Sie unter Bedingter Zugriff: Anfordern einer Authentifizierungsstärke für externe Benutzer.

Benutzeroberfläche für externe Azure AD-Benutzer

Richtlinien zur Authentifizierungsstärke wirken mit MFA-Vertrauenseinstellungen in Ihren mandantenübergreifenden Zugriffseinstellungen zusammen, um zu bestimmen, wo und wie der externe Benutzer eine Multi-Faktor-Authentifizierung durchführen muss.

Zunächst authentifiziert sich ein Azure AD-Benutzer mit seinem eigenen Konto bei seinem Basismandanten. Wenn dieser Benutzer anschließend versucht, auf Ihre Ressource zuzugreifen, wendet Azure AD die Richtlinie zur Authentifizierungsstärke für den bedingten Zugriff an und überprüft, ob Sie die MFA-Vertrauensstellung aktiviert haben.

  • Wenn die MFA-Vertrauensstellung aktiviert ist, überprüft Azure AD die Authentifizierungssitzung des Benutzers auf einen Anspruch, der angibt, dass die MFA im Basismandanten des Benutzers ausgeführt wurde. (Tabelle 1 zeigt die Authentifizierungsmethoden, die für die MFA-Erfüllung zulässig sind, wenn die Multi-Faktor-Authentifizierung im Basismandanten des externen Benutzers durchgeführt wurde.) Wenn die Sitzung einen Anspruch enthält, der angibt, dass die MFA-Richtlinien bereits im Basismandanten des Benutzers erfüllt wurden und die Methoden den Anforderungen an die Authentifizierungsstärke genügen, wird dem Benutzer Zugriff gewährt. Andernfalls wird der Benutzer durch Azure AD aufgefordert, im Basismandanten eine Multi-Faktor-Authentifizierung mit einer akzeptierten Authentifizierungsmethode durchzuführen. Die MFA-Methode muss im Basismandanten aktiviert sein, und der Benutzer muss sich für sie registrieren können.
  • Wenn die MFA-Vertrauensstellung deaktiviert ist, fordert Azure AD den Benutzer über eine Abfrage auf, die MFA im Ressourcenmandanten mit einer zulässigen Authentifizierungsmethode durchzuführen. (Authentifizierungsmethoden, die für die MFA-Erfüllung durch einen externen Benutzer zulässig sind, finden Sie in Tabelle 1.)

Wenn der Benutzer keine Multi-Faktor-Authentifizierung durchführen kann, oder wenn eine Richtlinie für bedingten Zugriff (z. B. eine Richtlinie zur Gerätekonformität) eine Registrierung verhindert, wird der Zugriff blockiert.

Gerätekompatibilität und hybride, in Azure AD eingebundene Geräterichtlinien

Organisationen können Richtlinien für den bedingten Zugriff verwenden, um zu verlangen, dass die Geräte der Benutzer von Microsoft Intune verwaltet werden. Solche Richtlinien können den Zugriff externer Benutzer blockieren, da ein externer Benutzer sein nicht verwaltetes Gerät nicht bei der Ressourcenorganisation registrieren kann. Geräte können nur vom Basismandanten eines Benutzers verwaltet werden.

Sie können jedoch Gerätevertrauenseinstellungen verwenden, um die Blockierung externer Benutzer aufzuheben, während weiterhin verwaltete Geräte verlangt werden. In den Einstellungen für den mandantenübergreifenden Zugriff können Sie festlegen, ob Sie den Angaben des Basismandanten eines externen Benutzers darüber, ob das Gerät des Benutzers den Richtlinien für die Gerätekonformität entspricht oder ob es sich um ein hybrides, in Azure AD eingebundenes Gerät handelt, vertrauen. Sie können Einstellungen für die Gerätevertrauensstellung für alle Azure AD-Organisationen oder einzelne Organisationen festlegen.

Wenn die Gerätevertrauenseinstellungen aktiviert sind, prüft Azure AD die Authentifizierungssitzung eines Benutzers auf einen Geräteanspruch. Wenn die Sitzung einen Geräteanspruch enthält, der angibt, dass die Richtlinien im Basismandanten des Benutzers bereits erfüllt wurden, wird dem externen Benutzer eine nahtlose Anmeldung an Ihrer freigegebenen Ressource gewährt.

Wichtig

  • Wenn Sie nicht bereit sind, Angaben in Bezug auf die Gerätekonformität oder den Status als hybrides, in Azure AD eingebundenes Gerät des Basismandanten eines externen Benutzers zu vertrauen, empfehlen wir nicht, Richtlinien für den bedingten Zugriff anzuwenden, die von externen Benutzern die Verwendung verwalteter Geräte verlangen.

Gerätefilter

Beim Erstellen von Richtlinien für bedingten Zugriff für externe Benutzer können Sie eine Richtlinie basierend auf den Geräteattributen eines registrierten Geräts in Azure AD prüfen. Mit der Bedingung Filter für Geräte können Sie mithilfe der unterstützten Operatoren und Eigenschaften sowie der anderen verfügbaren Zuweisungsbedingungen in Ihren Richtlinien für den bedingten Zugriff auf bestimmte Geräte abzielen.

Gerätefilter können zusammen mit mandantenübergreifenden Zugriffseinstellungen verwendet werden, um Richtlinien auf Geräte zu stützen, die in anderen Organisationen verwaltet werden. Angenommen, Sie möchten beispielsweise Geräte von einem externen Azure AD-Mandanten auf der Grundlage eines bestimmten Geräteattributs blockieren. Sie können eine auf Geräteattributen basierende Richtlinie wie folgt einrichten:

  • Konfigurieren Sie Ihre mandantenübergreifenden Zugriffseinstellungen so, dass Geräteansprüche von dieser Organisation als vertrauenswürdig eingestuft werden.
  • Weisen Sie das Geräteattribut, das Sie für die Filterung verwenden möchten, einem der unterstützten Geräteerweiterungsattribute zu.
  • Erstellen Sie eine Richtlinie für bedingten Zugriff mit einem Gerätefilter, der den Zugriff auf Geräte blockiert, die dieses Attribut enthalten.

Weitere Informationen zum Filtern für Geräte mit bedingtem Zugriff.

Verwaltungsrichtlinien für mobile Anwendungen

Es wird nicht empfohlen, für externe Benutzer eine App-Schutzrichtlinie zu erzwingen. Die Gewährungssteuerelemente für bedingten Zugriff wie Vorschreiben der Verwendung genehmigter Client-Apps und App-Schutzrichtlinie erforderlich setzen die Registrierung des Geräts beim Ressourcenmandanten voraus. Diese Steuerelemente können nur auf iOS- und Android-Geräte angewendet werden. Da das Gerät eines Benutzers nur von seinem Basismandanten verwaltet werden kann, können diese Steuerelemente nicht auf externe Gastbenutzer angewendet werden.

Standortbasierter bedingter Zugriff

Die standortbasierte Richtlinie auf Grundlage von IP-Adressbereichen kann erzwungen werden, wenn die einladende Organisation einen vertrauenswürdigen IP-Adressbereich erstellen kann, mit dem ihre Partnerorganisationen definiert werden.

Richtlinien können auch anhand von geografischen Standorten erzwungen werden.

Risikobasierter bedingter Zugriff

Die Anmelderisiko-Richtlinie wird durchgesetzt, wenn der externe Gastbenutzer die Anforderungen des Gewährungssteuerelements erfüllt. Beispielsweise kann eine Organisation bei einem mittleren oder hohen Anmelderisiko die mehrstufige Azure AD-Authentifizierung erzwingen. Falls sich ein Benutzer aber nicht bereits auf dem Ressourcenmandanten für die mehrstufige Azure AD-Authentifizierung registriert hat, wird er blockiert. Hierdurch soll verhindert werden, dass böswillige Benutzer ihre eigenen Anmeldeinformationen für die mehrstufige Azure AD-Authentifizierung registrieren können, wenn sie in den Besitz des Kennworts eines rechtmäßigen Benutzers gelangen.

Die Richtlinie zum Benutzerrisiko kann im Ressourcenmandanten aber nicht aufgelöst werden. Falls beispielsweise eine Kennwortänderung für externe Gastbenutzer mit hohem Risiko erzwungen wird, werden diese blockiert, weil Kennwörter im Ressourcenverzeichnis nicht zurückgesetzt werden können.

Bedingter Zugriff: Client-Apps-Bedingung

Client-Apps-Bedingungen verhalten sich für B2B-Gastbenutzer genauso wie für andere Arten von Benutzern. Sie können beispielsweise verhindern, dass Gastbenutzer Legacy-Authentifizierungsprotokolle verwenden.

Bedingter Zugriff: Sitzungssteuerelemente

Sitzungssteuerelemente verhalten sich für B2B-Gastbenutzer genauso wie für andere Arten von Benutzern.

Identitätsschutz und Benutzerrisikorichtlinien

Der Identitätsschutz erkennt kompromittierte Anmeldeinformationen für Azure AD-Benutzer und markiert Benutzerkonten, die möglicherweise kompromittiert sind, als „gefährdet“. Als Ressourcenmandant können Sie Benutzerrisikorichtlinien auf externe Benutzer anwenden, um riskante Anmeldungen zu blockieren. Für einen externen Benutzer wird das Benutzerrisiko in seinem Basisverzeichnis bewertet. Das Echtzeit-Anmelderisiko für diese Benutzer wird im Ressourcenverzeichnis ausgewertet, wenn sie versuchen, auf die Ressource zuzugreifen. Da die Identität eines externen Benutzers jedoch in seinem Basisverzeichnis existiert, gibt es folgende Einschränkungen:

  • Wenn ein externer Benutzer die Identitätsschutz-Benutzerrisikorichtlinie auslöst, um das Zurücksetzen des Kennworts zu erzwingen, wird er gesperrt, da er sein Kennwort in der Ressourcenorganisation nicht zurücksetzen kann.
  • Der Bericht der Ressourcenorganisation über risikobehaftete Benutzer spiegelt externe Benutzer nicht wider, da die Risikobewertung im Basisverzeichnis des externen Benutzers stattfindet.
  • Administratoren in der Ressourcenorganisation können einen risikobehafteten externen Benutzer nicht zurückweisen oder bereinigen, da sie keinen Zugriff auf das Basisverzeichnis des B2B-Benutzers haben.

Sie können verhindern, dass externe Benutzer von risikobasierten Richtlinien betroffen sind, indem Sie eine Gruppe in Azure AD erstellen, die alle externen Benutzer Ihrer Organisation enthält. Fügen Sie diese Gruppe dann als Ausschlusselement für Ihre integrierten Identity Protection-Benutzerrisiko- und -Anmelderisikorichtlinien sowie für alle Richtlinien für bedingten Zugriff hinzu, die das Anmelderisiko als Bedingung verwenden.

Weitere Informationen finden Sie unter Identity Protection und B2B-Benutzer.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Artikeln: