MFA mit externen Benutzern in Entra ID: Warum Inbound Trust allein nicht reicht

–> Also available in english!

Wer mit externen Benutzern (Gästen) in Microsoft Entra ID arbeitet, kennt das Problem: Ein Gast möchte auf eine Ressource in deinem Tenant zugreifen, wird zur MFA aufgefordert und scheitert. Die Fehlermeldung ist kryptisch, der Benutzer frustriert. Was ist da los?

In diesem Artikel erkläre ich, warum externe Benutzer oft als Microsoft Account (MSA) behandelt werden, warum die Inbound Trust Settings dann nicht greifen und welche zusätzliche Falle bei Authentication Strengths in Conditional Access Policies lauert.

Das Problem: Externe Accounts werden als Microsoft Account behandelt

#

Wenn du einen externen Benutzer per B2B Collaboration in deinen Tenant einlädst, löst dieser die Einladung ein (“Redemption”). Dabei entscheidet Entra ID anhand einer Redemption Order, welcher Identity Provider verwendet wird. Die Standard-Reihenfolge ist:

1. Microsoft Entra ID (wenn der Gast einen Entra ID Account im Home-Tenant hat)
2. External Federation (SAML/WS-Fed)
3. Microsoft Account (MSA) als Fallback

Das Problem: Wenn Entra ID den Gast nicht einem Entra ID Tenant zuordnen kann, z.B. weil die E-Mail-Domain keinem Entra ID Tenant zugeordnet ist oder aus anderen Gründen, wird der Gast als MSA-Account (Microsoft Account) behandelt. Und genau hier beginnt das Dilemma:

• Inbound Trust Settings gelten nur für Microsoft Entra Tenants, nicht für MSA-Accounts
• Dein Tenant kann die MFA eines MSA-Accounts nicht vertrauen, selbst wenn du “Trust multifactor authentication from Microsoft Entra tenants” aktiviert hast
• Der Gast wird zur MFA-Registrierung in deinem Resource-Tenant aufgefordert, oder der Zugriff schlägt komplett fehl

Lösung Teil 1: MSA als Fallback deaktivieren

#

Der erste Schritt ist sicherzustellen, dass externe Benutzer nicht als MSA-Account ihre Einladung einlösen. Dazu deaktivierst du Microsoft Accounts als Fallback Identity Provider in den Cross-Tenant Access Settings.

So gehst du vor

#

1. Melde dich im Microsoft Entra Admin Center an (mindestens als Security Administrator)
2. Navigiere zu Entra ID → External Identities → Cross-tenant access settings
3. Wähle den Tab Default settings und klicke auf Edit inbound defaults
4. Wechsle zum Tab B2B collaboration → Redemption order
5. Unter Fallback identity providers: Deaktiviere Microsoft service account (MSA)
6. Klicke auf Save

Hinweis: Email One-Time Passcode (OTP) ist in allen Tenants standardmäßig aktiviert und übernimmt automatisch als Fallback, wenn MSA deaktiviert wird. Nur wenn jemand Email OTP bewusst deaktiviert hat, muss es unter External Identities → All identity providers wieder aktiviert werden.

Wichtig: Bestehende Gastbenutzer, die sich bereits mit einem MSA angemeldet haben, verwenden diesen weiterhin. Du musst deren Redemption-Status zurücksetzen, damit die neue Einstellung greift.

Mit dieser Konfiguration werden Gäste, die keinem Entra ID Tenant zugeordnet werden können, stattdessen per Email One-Time Passcode (OTP) authentifiziert, statt als MSA behandelt zu werden.

Warum MSA deaktivieren?

#

MSA im Default zu deaktivieren ist nicht nur ein Workaround, sondern generell empfehlenswert für Enterprise-Szenarien:

• MFA-Trust greift nicht für MSA: “Trust MFA from Microsoft Entra tenants” gilt ausschließlich für Entra ID-Tenants. Solange MSA als Fallback aktiv ist, landen manche Gäste in dieser Lücke.
• Keine organisatorische Kontrolle: MSA sind persönliche Accounts (@outlook.com, @hotmail.com etc.). Kein Admin verwaltet die. Du weißt nicht, ob MFA aktiviert ist, welche Passwort-Policies gelten oder ob der Account kompromittiert ist.
• Conditional Access greift besser: Für MSA-Gäste greifen CA Policies anders als für Entra ID-Gäste. Du kannst z.B. keine Device Compliance oder Hybrid Join-Claims vertrauen.
• Email OTP ist der bessere Fallback: Ein zeitlich begrenzter Einmal-Code per E-Mail ist sicherer und vorhersagbarer als ein unkontrollierter MSA-Login.

Mit MSA deaktiviert hast du zwei saubere Pfade: Entra ID (mit Trust) oder Email OTP (ohne Trust, aber kontrolliert). Kein unkontrollierter dritter Weg.

Hinweis: Für Gäste mit persönlichen Microsoft-Accounts (@outlook.com etc.) ändert sich die Anmelde-Erfahrung: Sie erhalten stattdessen einen Email-OTP-Code. In typischen B2B-Partner-Szenarien mit Unternehmensaccounts hat das keine Auswirkung.

Referenz: Prevent your B2B users from redeeming an invite using Microsoft accounts

Lösung Teil 2: Inbound Trust Settings konfigurieren

#

Für Gäste, die tatsächlich aus einem Microsoft Entra Tenant kommen, brauchst du zusätzlich die Inbound Trust Settings. Damit sagst du deinem Tenant, dass er MFA-Claims aus anderen Entra ID Tenants vertrauen soll.

1. Im Microsoft Entra Admin Center → External Identities → Cross-tenant access settings
2. Default settings → Edit inbound defaults → Tab Trust settings
3. Aktiviere Trust multifactor authentication from Microsoft Entra tenants
4. Save

Tipp: Du kannst diese Einstellung auch pro Organisation individuell konfigurieren, wenn du nicht allen externen Tenants pauschal vertrauen möchtest. Dazu legst du unter Organizational settings eine spezifische Konfiguration für den Partner-Tenant an.

Soweit, so gut. Für viele Szenarien reichen diese beiden Schritte. Aber nicht für alle.

Die Falle: Authentication Strength und externe Benutzer

#

Wenn du, wie von Microsoft empfohlen, deine Conditional Access Policies mit Authentication Strengths konfiguriert hast, können Gastbenutzer trotz aktivierter Inbound Trust Settings weiterhin scheitern. Der Grund ist allerdings differenzierter, als es auf den ersten Blick wirkt.

Was funktioniert – und was nicht

#

Authentication Strength und Inbound Trust sind nicht grundsätzlich inkompatibel. Entscheidend ist, welche Authentication Strength du forderst und welche MFA-Methode der Gast in seinem Home-Tenant verwendet hat:

• Built-in “Multifactor authentication” Strength (die schwächste der drei): Funktioniert mit Inbound Trust, solange der Gast im Home-Tenant eine der von Microsoft für Cross-Tenant akzeptierten Methoden verwendet hat (z.B. Microsoft Authenticator Push, FIDO2, Software OATH Token).
• “Passwordless MFA” oder “Phishing-resistant MFA” Strength: Hier wird es eng. Dein Resource-Tenant kann nicht zuverlässig validieren, welche konkrete Methode der Gast im Home-Tenant genutzt hat. Wenn du z.B. Phishing-Resistant forderst, der Gast aber im Home-Tenant per Authenticator Push (nicht Passwordless) authentifiziert wurde, schlägt die Validierung fehl.
• Custom Authentication Strengths: Gleiches Problem. Je spezifischer die Anforderung, desto wahrscheinlicher scheitern externe Benutzer.

Die zusätzliche Falle: External Authentication Methods

#

Nutzt der Home-Tenant des Gastes einen Drittanbieter als MFA-Provider über die External Authentication Methods (EAM) Integration, wird es definitiv problematisch.

⚠️ Warning: External authentication methods are currently incompatible with authentication strength. You should use the Require multifactor authentication grant control.

— Microsoft Learn: Require multifactor authentication for all users

Dieses Warning bezieht sich primär auf External Authentication Methods (EAM) – also Szenarien, in denen der Home-Tenant einen Drittanbieter (z.B. Duo, RSA SecurID) als MFA-Provider über die EAM-Schnittstelle integriert hat. In diesem Fall kann dein Resource-Tenant die MFA-Methode des Gastes über Authentication Strength nicht validieren, unabhängig davon welche Strength-Stufe du konfiguriert hast.

Warum das in der Praxis trotzdem fast alle trifft

#

Eine typische Baseline-Policy sieht so aus:

• Users: All users (inkl. Guests)
• Target resources: All resources
• Grant: Require authentication strength → Multifactor authentication

Das ist die von Microsoft empfohlene Baseline-Policy. Selbst mit der schwächsten Built-in Strength scheitern Gäste in der Praxis häufig, weil:

1. Du als Resource-Tenant nicht weisst, welchen MFA-Provider der Home-Tenant einsetzt (native Entra MFA oder EAM-Drittanbieter)
2. Du nicht kontrollieren kannst, welche MFA-Methode der Gast konkret verwendet
3. Die Fehlermeldung nicht klar auf Authentication Strength als Ursache hinweist
4. Alles für interne Benutzer einwandfrei funktioniert

Das macht den sicheren Fallback auf den klassischen “Require multifactor authentication” Grant Control für Gäste in den meisten Umgebungen zur pragmatischeren Wahl.

Trade-off: Mit dem klassischen MFA Grant Control verlierst du die Möglichkeit, für Gäste Phishing-Resistant MFA zu erzwingen. Wenn das für dein Sicherheitskonzept relevant ist (z.B. bei Zugriff auf sensitive Ressourcen), kannst du für spezifische Partner-Tenants über Organizational Settings eine engere Konfiguration fahren und dort Authentication Strength beibehalten. Voraussetzung: Du hast mit dem Partner abgeklärt, dass er native Entra MFA mit passenden Methoden nutzt.

Lösung Teil 3: Separate CA Policy für Gäste

#

Die pragmatischste Lösung: Eine eigene Conditional Access Policy für externe Benutzer mit dem klassischen Grant Control statt Authentication Strength.

CA Policy für Gäste erstellen

#

Erstelle eine neue Conditional Access Policy für externe Benutzer:

1. Users: Select users and groups → Guest or external users → B2B collaboration guest users
2. Target resources: All resources (oder die relevanten Apps)
3. Grant: Require multifactor authentication (nicht “Require authentication strength”!)

Gäste aus der bestehenden Policy ausschließen

#

In deiner bestehenden Policy für alle Benutzer (die Authentication Strength verwendet) schließt du die Gastbenutzer aus:

1. Unter Exclude → Guest or external users auswählen

So behältst du für interne Benutzer weiterhin Authentication Strength (z.B. phishing-resistente Methoden), während Gäste über die separate Policy mit dem klassischen MFA Grant Control abgedeckt werden.

Für regulierte Umgebungen: Wenn du für bestimmte Partner-Tenants Phishing-Resistant MFA erzwingen musst, kannst du zusätzlich eine dritte CA Policy erstellen, die auf eine spezifische Gruppe von bekannten Partner-Gästen scoped ist und Authentication Strength verwendet. Voraussetzung: Du hast mit dem Partner verifiziert, dass er native Entra MFA mit kompatiblen Methoden (FIDO2, Windows Hello for Business, Certificate-Based Auth) einsetzt, also keine Drittanbieter über EAM.

Zusammenfassung

#

Damit MFA für externe Benutzer / Gäste in deinem Entra ID Tenant funktioniert, brauchst du drei Dinge:

Quellen:

• Prevent your B2B users from redeeming an invite using Microsoft accounts
• Cross-tenant access settings: Inbound Trust Settings for MFA
• Require multifactor authentication for all users: Conditional Access Policy
• Require authentication strength for external users
• Authentication and Conditional Access for External ID: MFA method comparison
• External authentication method provider reference