Also – Sie haben begonnen, das Feature „Authentication Strength“ zu testen, wie von Microsoft vorgeschlagen. Aber erhalten Sie Berichte von Partnerorganisationen oder Gästen, die sich nicht in Ihren Mandanten einloggen können? Oder vielleicht sind Sie ein Teams-Administrator, der Meldungen erhält, dass Ihre Benutzer nicht mit einer bestimmten Organisation zusammenarbeiten können?
Aus der anderen Perspektive – Sie haben begonnen, passwortlose Authentifizierung durchzusetzen oder zu empfehlen, aber Ihre Benutzer informieren Sie, dass sie nicht mehr mit einigen externen Organisationen zusammenarbeiten können. Sie melden sich wie gewohnt mit einem FIDO2-Schlüssel oder Windows Hello for Business bei ihrem Konto an. Doch wenn Sie die Anmeldeprotokolle überprüfen, nachdem der Wechsel des Mandanten fehlgeschlagen ist, sehen Sie nur den Fehlercode 53003 – Blockiert durch Conditional Access
Im Nachhinein ist die Fehlermeldung eigentlich recht hilfreich. Leider wird zuerst das Single Sign-On (SSO) ausgelöst, und es gibt keine Möglichkeit, zu einer passwortbasierten Anmeldung zu wechseln.
Ich halte mich für einen guten Geschichtenerzähler, aber ich verstehe, wenn Sie einfach direkt zur Lösung springen möchten.
Hier ist eine mögliche Erklärung.
Meine Fehlersuche
Im Folgenden werde ich die korrekten Begriffe "Home Tenant" für den Tenant verwenden, von dem der Benutzer mit den Problemen stammt, und "Resource Tenant" für den Tenant, auf den er als Gast zugreifen möchte.
Da es sich um ein Problem zwischen Tenants handelt, besteht der erste und oft zeitaufwändigste Schritt darin, den Administrator des Resource Tenant zu erreichen. In diesem Fall hatte ich das Glück, über einen inoffiziellen Kanal Kontakt aufnehmen zu können, was den Prozess weniger schmerzhaft machte.
Sobald ich mit dem Tenantadministrator der Organisation, bei der mein Kunde Schwierigkeiten hatte, in Kontakt war, überprüften wir die Einstellungen für Cnditional Access, aber ich fand nichts, was für mich auf ein zugrunde liegendes Konfigurationsproblem hinwies.
Der Resource Tenant verwendete die standardmäßige „Authentication Strength“ „Multifaktor-Authentifizierung“ für Gäste, die die meisten verfügbaren Authentifizierungsmethoden umfasst. Besonders diejenigen, die in unserem Fall verwendet wurden – Windows Hello for Business und Microsoft Authenticator.
Als wir die Anmeldeprotokolle im Resource Tenant durchgesehen haben, stellten wir Folgendes fest:
Anmeldungen schlugen fehl
Trotz erfolgreicher MFA laut den Authentifizierungsdetails
Der Home Tenant enthält offensichtlich nur sehr rudimentäre Informationen, da die Auswertung von Conditional Access im Resource Tenant erfolgt.
Eintauchen in die Dokumentation
Da nichts offensichtlich war, habe ich alle relevanten Microsoft-Dokumentationen gründlich durchgesehen und mögliche Probleme in Betracht gezogen. Gleichzeitig habe ich einen Case eröffnet, um den üblichen Prozess der Informationssammlung mit Microsoft-Support-Ingenieuren zu starten.
Zunächst fand ich einen vielversprechenden Artikel über Authentication Strengths für externe Benutzer. Allerdings wurde dort nicht erwähnt, welche spezifischen Probleme solche Benutzer betreffen könnten.
Der Artikel empfiehlt, die MFA-Vertrauseinstellung "wie vorgesehen" zu konfigurieren, aber da wir nicht beabsichtigten, irgendwelchen MFA-Claims zu vertrauen, fuhr ich wir weiter.
Eine weitere Warnung aus dem Artikel, die ich nicht als relevant ansah: Da wir weder E-Mail-OTP, SAML/WS-FED noch Google-Authentifizierung verwenden, sollten wir nicht auf die "Require MFA"-Conditional Access (CA) Grant zurückgreifen müssen.
Als Nächstes folgte ich dem Verweis auf die Konfiguration der mandantenübergreifenden Zugriffseinstellungen für MFA-Vertrauensstellung.
Diese Seite wird auch in einer Admin Center Info-Box erwähnt, wenn man Authentication Strength in Conditional Access konfiguriert. Der Text ist für mich etwas unklar, aber jetzt, wo ich weiß, dass das Problem von der unmöglichkeit herrührt, die Erstfaktorauthentifizierung im Resource Tenant abzuschließen, sehe ich die Relevanz.
Diese Dokumentation bietet nur eine vage Beschreibung, wie Ihr Tenant MFA-Claims vom Entra-Tenant eines Benutzers akzeptieren würde. Ich konnte bereits die Diskussionen um das Wort "Vertrauen" vorhersehen. Ich war nicht begeistert davon, dies zu testen, zumal ich Fragen wie "Wie weit reicht dieses Vertrauen?" oder "Können wir immer noch Authentication Strength durchsetzen?" oder "Könnten Fehler in ihrem Mandanten verwendet werden, um unsere MFA zu umgehen?" nicht sofort beantworten konnte.
Zusätzlich wird keine Erwähnung von Einschränkungen gemacht, die auftreten könnten, wenn dieses Vertrauen nicht konfiguriert wird.
Zur schnellen Referenz wären meine Antworten jetzt:
- "Claims, die vom Home Tenant gestellt werden, werden als gleichwertig zu denen behandelt, die Ihr Tenant stellen würde."
- "Cross-Tenant-Vertrauen bedeutet, dass Benutzer, die sich bei Ihrem Tenant anmelden, die Authentifizierung nicht wiederholen müssen, wenn sie Ihre Anforderungen bereits erfüllen, aber Ihre Authentication Strength müssen weiterhin erfüllt werden."
- "Bis zu einem gewissen Grad — das Akzeptieren von föderierter MFA ist meiner Meinung nach besonders riskant, da Sie nicht nur ihrem Entra-Tenant vertrauen, sondern möglicherweise einem unbekannten Drittanbieter-IDP."
Ein weiterer Verweis aus meinem Ausgangspunkt erklärt, wie man eine Richtlinie zur Durchsetzung von Authentication Strength erstellt: In derselben Dokumentationsreihe gibt es einen dedizierten Abschnitt für externe Benutzer, einschließlich einer interessanten Tabelle, die die verfügbaren Authentifizierungsmethoden in einem Home- und Resource Tenant vergleicht. Da wir jedoch sehen können, dass die Authenticator-Aufforderung in unserem Fall erfolgreich abgeschlossen wird, sollte es auch hier kein Problem geben.
Die Dokumentation stellt ausdrücklich klar, dass das Vertrauen in MFA optional für die B2B-Zusammenarbeit ist.
Leider brachte auch der Abschnitt zur Fehlersuche keine neuen Erkenntnisse oder Ansätze zutage.
Persönlich sah ich keine vernünftige Quelle für die Probleme, die meine Benutzer hatten. Die Partnerorganisation zögerte, das "MFA-Vertrauen" zu konfigurieren, weil es ein gewisses Maß an Sicherheitsrisiken impliziert.
Der Support-Techniker, mit dem ich zusammenarbeitete, bestand darauf, dass das beobachtete Verhalten und die Lösung klar in der Dokumentation beschrieben sind, also lassen Sie mich wissen, wo ich mich blöd anstelle.
Die Lösung
Nach der Fehlersuche kamen wir zu einer Lösung, die sich jedoch suboptimal anfühlte. Bei den Tests hatten der Administrator des Resource Tenant und ich bereits festgestellt, dass wir MFA-Claims vertrauen müssen.
Ich konnte nicht glauben, dass die B2B-Zusammenarbeit davon abhängen würde, dass alle Organisationen das Mandantenvertrauen konfigurieren. Wir mussten auch auf die Genehmigung des Änderungsprozesses warten, und ich befürchtete, dass ich, da dies keine Änderung auf unserer Seite war, den Prozess möglicherweise mit anderen Organisationen wiederholen müsste.
Genau das hat Microsoft Support jedoch bestätigt: Wenn Sie Authentifizierungsstärken für B2B-Benutzer verwenden möchten, müssen Sie die externen Zugriffseinstellungen konfigurieren – wenn Sie die Organisationen, mit denen Sie zusammenarbeiten und die bereits auf passwortlose Authentifizierung umgestellt haben, nicht erheblich beeinträchtigen wollen.
Die Situation wurde mir wie folgt erklärt: Ohne MFA-Vertrauen wird der Resource Tenant die Benutzer auffordern, die zweite Faktor-Authentifizierung im Resource Tenant abzuschließen. Bei Verwendung von Authentifizierungsstärken wird jedoch die Gültigkeit des Passworts (erster Faktor) nicht bestätigt, wenn passwortlose Authentifizierungsmethoden verwendet werden – und es gibt keinen Mechanismus, um den Home Tenant dazu zu bringen, dies zu tun. Dies führt zu einer fehlgeschlagenen Authentifizierung.
Option 1: Weiterhin Authentifizierungsstärke verwenden
Um weiterhin Authentifizierungsstärken zu nutzen, konfigurieren Sie MFA-Vertrauen in den externen Zugriffseinstellungen des Entra-Portals:
Alternativ können Sie MFA-Vertrauen nur für bestimmte Organisationen konfigurieren, mit denen Sie zusammenarbeiten oder die von dem Problem betroffen sind. Ob Sie dies als Standard einstellen sollten, hängt davon ab, wie oft Sie die Konfiguration überprüfen möchten und wie viele Organisationen Sie dabei berücksichtigen müssen.
Gerade in der B2B-Zusammenarbeit könnte es sinnvoll sein, eine Authentifizierungsstärke zu schaffen, die weniger sichere Methoden wie SMS oder föderierte MFA ausschließt. Dies hängt jedoch von den Authentifizierungsmethoden der Organisationen ab, mit denen Sie zusammenarbeiten. Verwenden Sie Bericht-als-Only-Bedingter Zugriff Richtlinien, um Änderungen vor der vollständigen Bereitstellung zu bewerten.
Option 2: Zurück zur "Requrire MFA"-Checkbox
Diese Grant-Kontrolle ist von den besprochenen Problemen nicht betroffen. Obwohl die Benutzer die zweite Faktor-Authentifizierung im Resource Tenant abschließen müssen, funktioniert sie zuverlässig.
Wenn Sie von diesem Problem betroffen sind, senden Sie diesen Artikel an die Administratoren des Resource Tenant. Bis sie ihre Einstellungen anpassen, können Ihre Benutzer Windows Hello for Business und wahrscheinlich auch die MacOS-Plattform-Authentifizierung und FIDO2-Schlüssel nicht verwenden (obwohl ich diese nicht getestet habe, sollten sie logischerweise ähnlich betroffen sein). Benutzer müssen sich stattdessen mit einem Passwort anmelden, damit sie die MFA im Resource Tenant, auf den sie zugreifen möchten, abschließen können. Leider können Sie auf Ihrer Seite nichts tun, um das Problem zu beheben, außer die andere Organisation zu bitten, die notwendigen Änderungen vorzunehmen.
Man könnte meinen, dass dies ein Versäumnis ist, zumal der Resource Tenant sofort erkennen sollte, dass er die Authentifizierung nicht abschließen kann.
…
Abschließende Gedanken
Ich gebe zu — ich habe die Lösung erst vollständig verstanden, nachdem ich einen Fall bei Microsoft eröffnet hatte, und es scheint, dass dieses Problem intern bekannt ist. Rückblickend betrachtet scheint das eigentliche Problem in der Dokumentation etwas verschleiert gewesen zu sein.
Deshalb habe ich diesen Artikel geschrieben – in der Hoffnung, jemandem zu ersparen, die gleichen Probleme durchmachen zu müssen.
Diese Episode hat auch gezeigt, wie weit verbreitet passwortlose Authentifizierung wirklich ist. Die Organisation mit der "Fehlkonfiguration" hatte bereits mit vielen anderen zusammengearbeitet, und dies war das erste Mal, dass das Problem auftrat.
Hoffentlich wird es in Zukunft eine robustere Lösung geben, sei es durch eine ordnungsgemäße "Vertrauensbildung" oder eine Verbesserung der Authentifizierungsstärke, um passwortlose Methoden besser zu handhaben – ohne auf mandantenübergreifende Zugriffseinstellungen angewiesen zu sein. Mindestens eine klare Fehlermeldung oder Warnung wäre hilfreich. Wir werden sehen.
Kommentare