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.

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
    

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: