Azure AD: Bevorzugte Methode für Multi-Faktor-Authentifizierung festlegen


    Tags: , ,

    Azure Active Directory (Azure AD, AAD)Azure AD fordert Benutzer mit der neuen MFA-Richt­linie auf, sich mit der sichersten Methode anzu­­melden, wenn sie mehrere Ver­fahren regi­striert haben. Admins können damit die Anmelde­sicherheit für Office 365 oder Azure ver­bessern, indem Sie die Nutzung weniger sicherer Anmelde­­methoden wie SMS unter­binden.

    Azure Active Directory unterstützt mehrere Verfahren zur Authentifizierung und kann diese zusätzlich durch einen zweiten Faktor absichern. Auch dafür stehen mehrere Optionen zur Verfügung.

    Im Prinzip lässt sich Multi-Faktor-Authentifizierung (MFA) auf drei Arten durchsetzen:

    1. Aktivieren der Sicherheitsstandards (Standardschutz)
    2. MFA-Aktivierung über eine Richtlinie für den bedingten Zugriff (erfordert mindestens eine Lizenz vom Typ Azure AD Premium P1)
    3. Legacy-MFA auf Benutzerbasis

    Die Methoden 1) und 3) stehen in allen Office 365-Plänen zur Verfügung und damit auch kleinen Unternehmen, während 2) einen Plan wie Business Premium oder Enterprise E3 erfordert.

    Haben Sie zusätzlich P2 (zum Beispiel in O365/ M365 Enterprise E5), dann können Sie in einer Richtlinie für den bedingten Zugriff ("Conditional Access") auch das ermittelte Benutzer- oder Anmelderisiko (Azure AD Identity Protection) mit einbeziehen.

    Die alte Funktion MFA pro Benutzer (Legacy MFA) wird von Microsoft nicht mehr empfohlen.

    In vielen Unternehmen bieten die Sicherheits­standards ausreichende Anmelde­sicherheit. Wenn Sie einen Azure-AD-Mandanten neu anlegen, dann sind die Sicherheits­standards seit August 2017 bereits automatisch aktiviert.

    Die Sicherheitsstandards sind seit Sommer 2017 bei jedem neuen Tenant aktiviert.

    Den bedingten Zugriff empfiehlt Microsoft für größere Unternehmen, die spezifische Anforderungen an die Anmelde­sicherheit haben. Diese erhalten dann mehr Kontrolle und können Richtlinien definieren, die etwa auf Anmeldeereignisse reagieren oder weitere Aktionen anfordern, bevor ein Benutzer Zugriff auf IT-Ressourcen erhält.

    Möchten Sie Richtlinien für den bedingten Zugriff verwenden, dann müssen Sie sowohl MFA auf Benutzerbasis als auch die Sicherheitsstandards deaktivieren, denn Methode 1 und 2 schließen einander aus.

    Sicherheits-Features standardmäßig aktivieren

    Bei einer Richtlinie für den bedingten Zugriff können Nutzer die sekundäre Authentifizierungs­methode bei der Registrierung bestimmen, während es bei den Sicherheitsstandards per Default immer die Authenticator App ist, was uns zum eigentlichen Thema führt.

    Was passiert beim Standardschutz, wenn Microsoft neue Sicherheits­funktionen veröffentlicht? Es gibt grundsätzlich zwei Möglichkeiten, diese standardmäßig zu aktivieren:

    • von Microsoft verwaltet, oder
    • mit Hilfe der Graph-API

    Ein Beispiel für ein neues Sicherheitsfeature wäre etwa ein besserer Schutz vor MFA-Ermüdungs­angriffen, die einen User dazu verleiten, versehentlich MFA-Genehmigungen zu erteilen.

    Diesem Zweck dienen die noch als Vorschau eingestufte Authenti­fizierungs­richtlinie Nummern­abgleich in MFA-Benachrichtigungen.

    Ist ein Schutz von Microsoft verwaltet, dann bedeutet es, dass ihn Azure AD gemäß der jeweils aktuellen Sicherheits­bedrohungen von sich aus aktivieren oder deaktivieren kann. Sie als Kunde können aber entscheiden, ob Microsoft den Schutz verwalten darf, indem sie ihn über die Graph-API auf aktiviert oder deaktiviert setzen.

    Sie können aber auch jederzeit, nachdem Microsoft ein neues Sicherheits-Feature veröffentlicht hat, dieses mit Hilfe der Graph-API nach ihrem eigenen Zeitplan testen und schrittweise einführen.

    Ist aber von Microsoft verwaltet eingestellt, dann erhalten ab einem bestimmten Datum alle Mandanten standardmäßig die neue Sicherheits­funktion zur Verteidigung gegen neue Angriffsvektoren, und zwar ohne Option zur Deaktivierung. Sie können sich als Kunde somit nicht gegen den Schutz entscheiden, wenn Microsoft dieses standardmäßig einplant.

    Vom System bevorzugte MFA

    Im Rahmen des Standardschutzes gibt es seit einiger Zeit eine neue Richtlinie für Authentifizierungs­methoden, die auf den Namen vom System bevorzugte Multi-Faktor-Authentifizierung hört.

    Sie fordert die Nutzer automatisch auf, sich mit der jeweils sichersten registrierten Methode anzumelden, für die sie sich registriert haben. Hat ein Benutzer zum Beispiel sowohl SMS als auch Microsoft Authenticator-Push-Benachrichtigungen aktiviert, dann wird ihn MFA dazu anhalten, sich per Push-Nachricht anzumelden.

    Damit gehört auch vom System bevorzugte MFA zu den standardmäßig von Microsoft verwalteten Einstellungen. Die Richtlinie kennt drei Zustände: disabled, enabled und default.

    Im Rahmen der Vorschauphase ist disabled voreingestellt. Erst nach der allgemeinen Verfügbarkeit ändert sich der Standardwert für den von Microsoft verwalteten Status auf enabled, um die vom System bevorzugte MFA zu aktivieren. Mit default kann Azure AD die Funktion für die ausgewählte Gruppe aktivieren.

    Um das Feature schon jetzt zu testen, müssen Sie also die Graph-API bemühen. Sind Sie kein Entwickler oder fühlen sich generell mit der Kommandozeile unwohl, dann greifen Sie am besten zum Graph Explorer. Damit können Sie die APIs im Standard-Beispielmandanten testen.

    Der Graph Explorer mit dem Beispiel-Mandanten

    Möchten Sie wie in unserem Fall konkrete Einstellungen in Ihrem Mandanten abfragen oder setzen, müssen Sie sich natürlich mit einem ausreichend berechtigten Nutzer anmelden, etwa dem globalen Administrator, und die angeforderten Berechtigungen bestätigen.

    Suchen Sie dann im Tab Resources im Knoten Policies nach authentiationMethodPolicy und klicken auf die GET-Methode und dann auf Run Query, um den aktuellen Status zu ermitteln. Sie können leicht sehen, dass der state bei registrationEnforcement in meinem Fall default ist.

    HTTP-Get mit dem Graph Explorer ausführen

    Entsprechend könnten Sie die Einstellung mit der Patch-Methode ändern, zum Beispiel für eine spezifische Gruppe mit der angegebenen Group-ID. Hier der zugehörige HTTP-Request:

    Weitere Beispiele für JavaScript, Java, PHP oder PowerShell finden Sie in der Dokumentation.

    Erhalten Sie beim ersten Mal die Meldung

    Forbidden - 403 - 300ms. Either the signed-in user does not have sufficient privileges, or you need to consent to one of the permissions on the Modify permissions tab

    und Sie sind mit einem ausreichend berechtigten Nutzer angemeldet, liegt es an den Einwilligungen (Consent). Klicken Sie dann auf den Tab Modify permission und erteilen die Einwilligung für Policy.ReadWrite.AuthentionMethod.

    Sie müssen den angeforderten Berechtigungen zustimmen, um den HTTP-Request absetzen zu können.

    Zusammenfassung

    Die neue Richtlinie für Authentifizierungs­methoden mit der Bezeichnung vom System bevorzugte Multi-Faktor-Authentifizierung bewirkt, dass sich Benutzer mit dem sichersten jener Verfahren anmelden müssen, die sie für MFA registriert haben.

    Sie steht im Rahmen des Standardschutzes und somit in allen M365-Plänen zur Verfügung. Aktuell befindet sich das Feature im Preview-Modus und ist per Voreinstellung deaktiviert. Unternehmen können diesen Status mit Hilfe des Graph-API ändern und so die Richtlinie vorab testen.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Thomas Drilling

    Thomas Drilling arbeitet seit mehr als 20 Jahren selb­ständig als Redakteur und Autor für viele ehe­malige und aktuelle IT-Magazine sowie Blogs. Thomas ist zudem Buch­autor und IT-Consultant.

    Seit 5 Jahren ist Thomas neben seiner journa­listischen Tätig­keit haupt­beruflicher, selb­ständiger IT-Trainer für VMware und Microsoft.

    Seine Themen­schwer­punkte sind Virtua­lisierung und Cloud Com­puting, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zerti­fi­zierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas ist außerdem zertifi­zierter AWS Solu­tions Archi­tect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Admini­strator.

    Thomas führt aktuell jeden zwei­ten Mon­tag einen 4-tägigen Grund­lagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Infor­mationen und Anmel­dung über sein AWS-Blog.

    Ähnliche Beiträge

    Weitere Links