Legacy-MFA (benutzerspezifisch) und ihre Auswirkungen auf Sicherheitsstandards, PIM, Bedingter Zugriff-Richtlinien und Azure AD Identity Protection

Problem:

  • Du bereitest dich auf die AZ-500 oder MS-500 (Sicherheitszertifikate) vor und das Zusammenspiel zwischen den Einstellungen des Legacy-Portals (benutzerspezifisch) für die Multi-Faktor-Authentifizierung (MFA) und allen anderen Sicherheitsfunktionen von Microsoft Entra / Azure AD ist verwirrend oder nicht
  • Oder du ärgerst dich über die Microsoft/Pearson-Trickfragen mit falsch konfigurierten MFA- und Conditional Access (CA)-Richtlinien in den Beispielfragen, bei denen du dich fragst, warum irgendjemand MFA so verkehrt konfigurieren würde
  • Oder vielleicht bist du einfach nur daran interessiert, mehr über die oben genannten Interaktionen zu erfahren, denn Microsoft dokumentiert sie nicht besonders gut, außer dass es heißt: „Mach mal keine Legacy (benutzerspezifisch) MFA!“

Lösung:

A screenshot of the risk-based Condtional Access policy configuration options
TL; DR: Wenn du eine MFA-Eingabeaufforderung für einen Endbenutzer testest oder auswertest, solltest du wissen, dass Legacy MFA von Sicherheitsstandards, PIM und Bedingter Zugriff-Richtlinien außer Kraft gesetzt / ignoriert wird, es sei denn, es handelt sich um eine risikobasierte Bedingter Zugriff-Richtlinie und der Benutzer hat sich für MFA gemäß den Legacy-Einstellungen (benutzerspezifisch) angemeldet.

Details:

Ok, der letzte Satz von Aufzählungspunkten war komplex und ich werde hier erklären, erstens, wie ich diesen kleinen Info-chen gelernt habe und zweitens werde ich auf diese spezifische Interaktion in Azure AD etwas genauer eingehen.

Wenn du mit dem AZ-500 oder MS-500 vertraut bist, weißt du, dass sich dieses Zertifikat auf die Sicherheit der Microsoft Cloud-Angebote konzentriert und dass die Sicherheitsrichtlinien von Azure AD (oder heißt es schon Entra ID?) einen großen Teil davon ausmachen. Außerdem weiß jeder, der Erfahrung mit den Microsoft-Zertifizierungstests hat, dass diese gerne Trickfragen enthalten. Microsoft erstellt nämlich gerne Szenarien mit – wie ich finde – falsch konfigurierten Systemen und fragt dich dann, wie sie sich in einem bestimmten Szenario verhalten würden.

Dir werden zum Beispiel einige Richtlinien für den bedingten Zugriff und einige Nutzer angezeigt, die sich bei Microsoft 365 oder Azure anmelden, und die Informationen über die Nutzer enthalten ihren MFA-Status. Dieser MFA-Status bezieht sich auf das Legacy-MFA-Portal (pro Benutzer), das du laut Microsoft nicht mehr verwenden solltest. Außer die CA-Richtlinien, wie oben erwähnt, kannst du diese Einstellungen ignorieren. Der Test versucht, dich auszutricksen. Aber auch diese Informationen sind, soweit ich das beurteilen kann, von Microsoft nicht eindeutig dokumentiert wurde. Ich habe nur einige Forenbeiträge mit möglichen Antworten gefunden, und ich musste meine eigenen Tests durchführen, um dies zu bestätigen.

Animated gif of a cute doggy being tricked

Wie du siehst, können diese verschiedenen Portale, Einstellungen und Methoden zur Verwaltung von MFA schnell sehr verwirrend werden, besonders in einer Produktionsumgebung. So habe ich von diesen Auswirkungen und warum etwas gelernt, aber die zweite Frage bleibt: Was genau wird zwischen Legacy MFA und den anderen Sicherheitseinstellungen bewertet?

Hier ist eine ausführlichere Erklärung, wie mehrere Sicherheitsfunktionen in Azure AD tatsächlich NICHT mit Legacy MFA interagieren:

  • Wenn du die Sicherheitsstandards aktivierst, wirst du feststellen, dass deine Benutzer MFA durchführen müssen und deren Status im Legacy-Portal höchstwahrscheinlich „deaktiviert“ ist
  • PIM-Richtlinien, die für ein privilegiertes Konto MFA bei der Aktivierung erfordern, ignorieren die Legacy-Einstellung/den Legacy-Status (benutzerspezifisch), und nicht registrierte Benutzer werden aufgefordert, sich bei MFA zu registrieren
  • Nochmal: bei der Richtlinien für den bedingten Zugriff ignorieren die Legacy-Einstellung/den Status (benutzerspezfisch), und nicht angemeldete Benutzer werden aufgefordert, sich bei MFA anzumelden.
    • Es gibt jedoch eine ganz bestimmte Ausnahme von den CA-Richtlinien, die Legacy-MFA (pro Benutzer) ignorieren
    • Wenn die risikobasierten Bedingter Zugriff-Richtlinien, die durch die Azure AD P2-Lizenzfunktion namens Azure AD Identity Protection, aktiviert sind
    • UND MFA ist erforderlich, um in der Bedingter Zugriff-Richtlinie „Zugang zu gewähren“ (Grant)
    • UND der Benutzer, der von der Bedingter Zugrff-Richtlinie bewertet wird, hat sich noch nicht für MFA angemeldet, entweder im Legacy-Portal oder über eine andere Methode, wie z. B. die drei oben aufgeführten Sicherheitsfunktionen
      • In diesem tollen Beitrag von activedirectorypro.com wird erklärt, wie du per PowerShell-Skript feststellen kannst, ob sich der Benutzer für MFA angemeldet hat, sei es über das Legacy-Portal oder auf andere Weise
    • Dann wird der Anmeldeversuch des Benutzers blockiert und der Benutzer wird NICHT aufgefordert, sich bei MFA anzumelden.

Fazit:

Nach der Logik des oben beschriebenen Falles, in dem eine risikobasierte CA-Richtlinie vom Legacy MFA-Status des Nutzers beeinflusst wird, macht es Sinn, dass Microsoft dies tut. Wenn ein Benutzer oder seine Anmeldung von Azure AD Identity Protection als riskant eingestuft wird UND der Benutzer sich bereits für MFA angemeldet hat, dann soll dieser riskante Anmeldeversuch nicht für MFA registriert werden können. Da der Anmeldeversuch als riskant eingestuft wird, könnten die Anmeldedaten des Nutzers kompromittiert werden und du willst nicht, dass ein Angreifer die MFA-Registrierung für sein Opfer durchführt.

Ich hoffe, dieser Beitrag hilft allen, die versuchen, all diese verschiedenen Einstellungen zu verstehen und Microsofts liebenswerte Tendenz, IT-Administratoren 15 Möglichkeiten zu geben, die gleiche Katze zu häuten, aber nicht genau zu erklären, wie sie mit anderen zusammenspielen oder nicht.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert