Man lernt immer wieder Neues über das interne Zusammenspiel in der Microsoft Entra-Welt.
Das Problem
In einer Kundenumgebung wurde die VPN-Anmeldung für Cisco AnyConnect auf eine Entra ID-Multi-Faktor-Authentifizierung für ausgewählte interne Benutzerkonten und B2B-Gastkonten umgestellt.
Der AnyConnect-Client öffnet die Authentifizierung in einem dedizierten Fenster und nutzt den konfigurierten Standardbrowser. Dies bietet eine bequeme Single-Sign-On-Erfahrung bei der Anmeldung mit einem B2B-Gastkonto, wenn man in einer regulären Browser-Sitzung bereits für den eigene Entra ID-Mandanten authentifiziert ist. So die Idee.
Leider gab es keine SSO-Erfahrung, sondern eine Aufforderung zur Eingabe des Kennwortes. Dies ist dem Umstand geschuldet, dass eine Conditional Access-Richtlinie die vollwertige Authentifizierung bei jeder Anmeldung erfordert. Leider folgte auf die Eingabe des Kennwortes nicht die erwarteten MFA-Aufforderung, sondern der Hinweis, dass die eigene Organisation noch weitere Informationen benötige. Dies endete in folgender Fehlermeldung.
Dies war umso verwunderlicher als das Konto bereits über eine vollständige MFA-Registrierung im Heimatmandanten verfügte. Andere B2B-Gastkonten konnten sich nach Anpassung der Gruppenmitgliedschaft problemlos authentifizieren und das VPN nutzen.
Wo lag also das Problem?
Nach den Durchsicht diverser Konfigurationspunkte in Entra ID, u.a. den Anmeldenprotokollen des betroffenen Kontos, warf ich einen Blick in die Konfiguration für externe Identitäten und die mandantenübergreifenden Zugriffseinstellungen. Mit einiger Überraschung sahen wir dort vier konfigurierte Organisationen, die niemand konfiguriert hatte. Eine davon war mein Heimatmandant. Woher kamen also diese Einträge?
Quelle dieser Einstellungen in Entra ID sind die Partnerbeziehungen zwischen dem Kundenmandanten und den Mandanten von Microsoft Partner Unternehmen, die als CSP oder Berater registriert und zugelassen sind, wie der folgende Screenshot des Microsoft 365 Admin Centers zeigt.
Im Rahmen der Umstellung auf eine granulare Berechtigungsmatrix für Unternehmen mit einer aktiven Partnerbeziehung zu einem Microsoft 365 Mandanten, erfolgt eine automatischen Synchronisation zur externen Identitätskonfiguration in Entra ID, zu sehen im folgenden Screenshot.
Wie man deutlich erkennt, erben alle Organisationen die Standardeinstellungen des Entra ID Mandanten. In Fall der nicht funktionierenden MFA-Authentifizierung für die VPN-Einwahl, galt es nun, die Einstellungen für den eingehenden Datenverkehr anzupassen.
Die Lösung
Mit den Standardeinstellungen vertraut Entra ID der im B2B-Gastmandanten ausgeführten MFA-Authentifizierung nicht. Dies muss explizit erlaubt werden, wie im nächsten Screenhot dargestellt.
Nach der Speicherung wird die Option für den Zugriff auf eigehenden Datenverkehr als konfiguriert angezeigt. Erst mit der Aktivierung der o.g. Option vertraut der Mandant der MFA-Prüfung im Quellmandanten.
Mit dieser Option ist eine MFA-Authentifizierung und eine Nutzung von Cisco AnyConnect möglich.
Hinweis
Die in diesem Beitrag beschriebene Situation für B2B-Gastkonten trifft auf Konten zu, deren Heimatmandant in einer Partnerbeziehung zum eigentlichen Entra ID-Mandanten steht.
Update
Inzwischen ist auch die Option aktiviert, dass nur konformen Geräten vertraut wird.
Links
Viel Spaß mit Entra und MFA.
Sie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen
