Azure AD: Neue Richtlinie für Authentifizierungsmethoden: „Vom System bevorzugte Multi-Faktor-Authentifizierung“

Mit der MFA-Richtlinie „vom System bevorzugte Multi-Faktor-Authentifizierung (MFA)“ fordert Azure AD Benutzer, die mehrere Sicherheitsmethoden registriert haben, auf sich mit der sichersten Methode anzumelden. Mit der noch als Vorschau eingestuften Funktion kannst du als Administrator die Anmeldesicherheit für Office 365 oder Azure verbessern, indem du die Nutzung weniger sicherer Anmeldemethoden wie SMS unterbindest.

Passende Schulungen

AZ-104 Microsoft Azure Administrator (AZ-104T00)

AZ-104 Microsoft Azure Administrator (AZ-104T00): Azure Administration fĂĽr Profis

AZ-500 – Microsoft Azure Security Technologies (AZ-500T00)

AZ-500 – Microsoft Azure Security Technologies (AZ-500T00): Kenntnisse zur Sicherung von Microsoft Azure-Umgebungen

Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!

Ich habe in diesem Artikel (Link) beschrieben, wie MFA funktioniert und welche Möglichkeiten du hast, MFA für Cloud- und Hybrid-Nutzer zu aktivieren. Im Prinzip führen drei Wege zum Ziel. Zur Erinnerung:

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

Methode 1 (und 3) steht also mit allen Office 365-Plänen zur VerfĂĽgung und damit auch kleinen Unternehmen, während Methode 2 einen Plan mit Azure AD Premium P1 erfordert wie z. B. Business Premium oder ab Enterprise E3. Du kannst auch Azure-AD-Lizenzen separat erwerben. Hast du zusätzlich P2 (z. B. in O365/ M365 Enterprise E5) kannst du in einer Richtlinie fĂĽr den bedingten Zugriff auch das ermittelte Benutzer- oder Anmelde-Risiko (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 Sicherheitsstandards ausreichend zusätzliche Anmeldesicherheit. Legst du deinen Azure AD Mandanten neu an, sind die Sicherheitsstandards ab August 2017 bereits automatisch aktiviert.

Du kannst die Einstellung prüfen oder bei Bedarf (wenn du z. B. Methode 2 verwenden möchtest) dich mit einem entsprechend berechtigten Konto im Microsoft Entra Admin Center anmelden, auf „Eigenschaften“ klicken und dann zum Abschnitt „Sicherheitsstandards“ scrollen.

Passende Schulungen

AZ-305 – Designing Microsoft Azure Infrastructure Solutions (AZ-305T00)

Verwendest du bereits Richtlinien für den bedingten Zugriff, müsstest du diese erst deaktivieren, um wieder zu den Sicherheitsstandards zu wechseln. Du findest die gleiche Einstellung auch im AAD-Portal und im Azure-Portal im Blade „Azure AD“.

Den bedingten Zugriff empfiehlt Microsoft für größere Unternehmen, die spezifischere Anforderungen an die Anmeldesicherheit haben. Diese erhalten dann mehr Kontrolle und können Richtlinien definieren, die z. B. auf Anmeldeereignisse reagieren oder weitere Aktionen anfordern, bevor ein Benutzer Zugriff auf eine Anwendung oder einen Dienst erhält. Möchtest du Richtlinien für den bedingten Zugriff verwenden, musst du sowohl “MFA auf Benutzerbasis” als auch die “Sicherheitsstandards” deaktivieren, denn Methode 1 und 2 schließen einander aus, wie folgende Tabelle von Microsoft zeigt.

Den Schutz eines Sicherheitsfeatures standardmäßig aktivieren

Bei einer Richtlinie für den bedingte Zugriff können Nutzer die sekundäre Authentifizierungsmethode übrigens bei der Registrierung bestimmen, während es bei den Sicherheitsstands per Default immer die Authenticator App ist, was uns zum eigentlichen Thema führt. Was passiert denn beim Standardschutz, wenn Microsoft neue Sicherheits-Funktionen veröffentlicht? Beim Standardschutz gibt es nämlich eigentlich zwei Möglichkeiten, den Schutz eines neues Sicherheitsfeatures standardmäßig zu aktivieren:

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

Ein Beispiel für ein neues Sicherheitsfeature wäre z. B. ein besserer Schutz vor MFA-Ermüdungsangriffen (einen Nutzer dazu verleiten, versehentliche MFA-Genehmigungen zu erteilen).

Das klappt mit Hilfe der noch als Vorschau eingestuften Authentifizierungsrichtlinie https://learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-mfa-number-match Nummernabgleich in MFA-Benachrichtigungen.

Wird der Schutz „von Microsoft verwaltet“ bedeutet das, dass Azure AD den Schutz gemäß der jeweils aktuellen Sicherheitsbedrohungslage von sich aus aktivieren oder deaktivieren kann. Als Kunde kannst du aber entscheiden, ob Microsoft den Schutz verwalten darf, indem du ihn ĂĽber die Graph-AP auf â€žAktiviert“ oder â€žDeaktiviert“ setzt. Du kannst aber auch jederzeit, nachdem Microsoft ein neues Sicherheitsfeature veröffentlicht hat, diese mit Hilfe der Graph-API in deinem eigenen Zeitplan testen und step-by-step einfĂĽhren. Ist aber „von Microsoft verwaltet“ eingestellt, wird Microsoft zwecks der Verteidigung gegen neue Angriffsvektoren das neue Sicherheitsfeatures ab einem bestimmten Datum standardmäßig fĂĽr alle Mandanten aktivieren ohne Option zur Deaktivierung. Du kannst dich als Kunde nicht gegen den Schutz entscheiden, wenn Microsoft den Schutz standardmäßig einplant.

Vom System bevorzugte Multi-Faktor-Authentifizierung 

Im Rahmen des Standardschutzes gibt es seit einiger Zeit eine neue Richtlinie für Authentifizierungsmethoden, die auf den Namen „vom System bevorzugte Multi-Faktor-Authentifizierung“ hört. Diese fordert den Nutzer automatisch auf, sich mit der jeweils sichersten seiner registrierten Methoden anzumelden, d. h. hat ein Benutzer gleichermaßen SMS, als auch Microsoft Authenticator-Push-Benachrichtigungen als Methoden für MFA registriert, wird ihn MFA auffordern, sich per Push-Benachrichtigungen 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 es jetzt schon zu testen, musst du die Graph-API bemĂĽhen. Bist du kein Entwickler oder fĂĽhlst dich generell mit der Kommandozeile unwohl, kannst du zum Graph Explorer greifen. Hierbei handelt es sich um ein  Entwickler-Werkzeug, mit dem du Erfahrungen mit der Microsoft Graph-APIs sammeln kannst, indem du z. B die APIs im Standard-Beispielmandanten testest.

Möchtest du wie in unserem Fall konkrete Einstellungen in deinem Mandanten abfragen oder setzen, musst du dich natürlich mit ausreichend berechtigten Nutzer anmelden, z. B. dem globalen Administrator. Dazu musst du in die angeforderten Berechtigungen einwilligen.

Suche dann im Tab „Resources“ im Knoten „policies“ nach „authentiationMethodPolicy (Du kannst auch die Volltextsuche verwenden) und klicke auf die „GET“-Methode und dann auf „Run Query“, um den aktuellen Status zu ermitteln. Du kannst leicht sehen, dass der „state“ bei „registrationEnforcement“ in meinem Fall „default“ ist.

Entsprechend kannst du die Einstellung mit der „Patch“-Methode ändern, z. B. für eine spezifische Gruppe mit der angegeben Group-ID. Hier der zugehörige HTTP-Request.

PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy
Content-Type: application/json
{
  "registrationEnforcement": {
    "authenticationMethodsRegistrationCampaign": {
        "snoozeDurationInDays": 1,
        "state": "enabled",
        "excludeTargets": [],
        "includeTargets": [
            {
                "id": "3ee3a9de-0a86-4e12-a287-9769accf1ba2",
                "targetType": "group",
                "targetedAuthenticationMethod": "microsoftAuthenticator"
            }
        ]
    }
  }
}

Weitere Beispiele fĂĽr JavaScript, Java, PHP oder Powershell findest du in der https://learn.microsoft.com/de-de/graph/api/authenticationmethodspolicy-update?view=graph-rest-1.0&tabs=http  Dokumentation:

Erhältst du 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 du bist mit einem ausreichend berechtigten Nutzer angemeldet, liegt es an den Einwilligungen (Consent). Klicke auf den Tab „Modify permission“ und erteile die Einwilligung fĂĽr „Policy.ReadWrite.AuthentionMethod:“