Azure Security Defaults

Die Anmeldung mittels Benutzername und Kennwort ist nur solange sicher, wie Anwender ihre Zugangsdaten nicht "verlieren", sei es durch zu einfache Kennworte, Keylogger o.ä. Ein wirksames Mittel dagegen ist eine Anmeldung mit einem zweiten Faktor. Aus dem Bereich des Homebanking kennen wir diese Anforderung schon lange mit den zusätzlichen TANs, PushMails o.ä. beim Überweisen und mittlerweile sogar beim Anmelden. Die "Security Defaults" im Tenant sind eine Funktion, damit auch Microsoft 365 Kunden ohne "AzureAD Plan1" einen besseren Schutz bekommen.

Vorgeschichte

Schon immer ist eine zusätzliche Absicherung für die Anmeldung an der Cloud ratsam. Aber anfangs war sie nicht erforderlich oder nur über einen Aufpreis zu erhalten. Das entsprechende Lizenzpaket zur granularen Kontrolle der Anmeldung nach Gerät, Standort, Anmelderisiko, Compliance, zweitem Faktor, Application und Service nennt sich Conditional Access und ist Bestandteil des "Azure AD Plan 1", der auch in EMS E3 oder Microsoft 365 E3 oder Microsoft 365 Business Premium und den F1/F3-Paketen enthalten ist.


Quelle: https://m365maps.com/matrix.htm#000001110001001001001

Wer eine dieser Lizenzen für seine Anwender hat, muss die folgenden Abschnitte nicht im Details verstehen. Er kann "Security Defaults" natürlich nutzen oder einfach abschalten und viel leistungsfähigeren Conditional Access Regeln nutzen.

Allerdings schaltet Microsoft die "Security Defaults" nicht alleine ab, nur weil sie AzureAD-P1 lizenziert haben. Das wird ihnen als Administrator überlassen, wenn Sie Conditional Access nach ihren Wünschen konfiguriert haben.

Basic MFA

Bei den meisten Tenants sind die Security Defaults vermutlich noch abgeschaltet. Sie können dennoch zumindest eine MFA-Anmeldung fordern. Diese Funktion gibt es schon relativ lange aber ich habe einen Link dazu nur beim Benutzer im Microsoft Admin Portal gefunden:

Der Link verweist dann auf das etwas altbacken wirkende Portal auf https://account.activedirectory.windowsazure.com/UserManagement/MultifactorVerification.aspx

Hier konnte ich schon immer einen Benutzer einen "MFA-Zwang" auferlegen. Allerdings musste ich das als Administrator hier für jeden neuen Benutzer manuell machen, denn es ganz lange Zeit kein "globales AN". Das ist natürlich nur bedingt sicher.

Aktivierung durch Microsoft

Bis zum 30.9.2022 konnten sie selbst entscheiden, wann Sie die Funktion "Security Defaults" und "Self Service Passwort-Reset (SSPR)" einschalten wollen. Ihre bis dahin aktuelle Einstellung war vom Zeitpunkt der Neuanlage ihres Tenants abhängig.

Datum Default-Einstellung

Vor dem 15. Aug 2020

Die Funktion war per Default auf "off" und konnte manuell eingeschaltet werden

15. Aug 2020 bis 30.Sep 2022

Default war ON aber sie konnten diese abschalten

Ab 1. Okt. 2022

Alle Tenants mit einem "off" werden reaktiviert.

 Die Administratoren konnten dies auch im MFA-Portal lesen:

Ab dem 30. September 2022 werden alle Mandanten für die kombinierte Registrierung von MFA und SSPR aktiviert. Aktivieren Sie sie jetzt. Hinweis: Nur Benutzer, die für die Verwendung von Microsoft Online Services lizenziert sind, sind zur Multi-Factor Authentication berechtigt.
Quelle: https://account.activedirectory.windowsazure.com/UserManagement/MultifactorVerification.aspx

Die Links in dem Text verweisen auf die folgenden Seiten:

Wer sein Microsoft 365 Message Center regelmäßig liest, hat dies aber schon Ende März 2022 unter der ID "MC348869" lesen können.

Die Links auf dieser Seite verweisen auf:

Wenn Sie diesen Artikel lesen, dann ist schon der 1. Oktober oder später und ihre Tenant ist schon umgestellt oder wird in naher Zukunft umgestellt. Wenn Sie sich als Administrator anmelden, dann sehen Sie eine entsprechende Information:

Spätestens jetzt sollten Sie für die anstehende Änderung sensibilisiert werden, ihre Anwender informieren.

Aktivierung durch Admin

Natürlich können Sie die "Security Defaults" auch als Administrator zu jeder Zeit einschalten. Das geht etwas versteckt im Azure Portal unter der folgenden URL:

 https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties

Sie müssen dann nur noch unten auf den Link "Manage Security default" klicken.

Wenn Sie diese Einstellung deaktivieren wollen, dann werden Sie zu einem Feedback aufgefordert, warum Sie nicht diese Defaults nutzen wollen.

Sie können die Security Defaults natürlich unabhängig von ihrem Feedback abschalten. Letztlich ist es ihre Entscheidung als Administrator des Tenants. Aus Sicherheitsgründen würde ich aber nicht auf Dauer mit "Benutzername + Kennwort" arbeiten wollen.

Security Default und SMTP

Mittlerweile ist der 1. Okt 2022 vorbei und Microsoft hat alle Tenants auf "Modern Auth" umgestellt. Den Prozess habe ich auf Exchange Online Authentifizierung beschrieben und auf BasicAuth Ende mit POP3/IMAP4 umgehen auch die Wege gezeigt, damit umzugehen. Allerdings hat Greg Taylor immer gesagt, dass SMTP-Auth davon nicht betroffen sein sollte.


Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-email-applications-stopped-signing-in-or-keep/ba-p/3641943

Zudem könnte es natürlich sein, dass beim dem Exchange Benutzer noch "BasicAuth" unterbunden ist. Das kann einmal "Global" als auch pro Mailbox konfiguriert werden

# Global kann die BasicAuth abgeschaltet sein
PS C:\> (get-TransportConfig).SmtpClientAuthenticationDisabled
True

# eine individuelle Einstellung pro Client überstimmt dies aber
PS C:\> (Get-CASMailbox user1@uclabor.de).SmtpClientAuthenticationDisabled

# Die Defaulteinstellung bei der CASMailbox ist "$null", so dass die globalen Defaults wirken

Allerdings steht das im Wiederspruch zu folgender Aussage:


Quelle:https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365#option-1-authenticate-your-device-or-application-directly-with-a-microsoft-365-or-office-365-mailbox-and-send-mail-using-smtp-auth-client-submission

Im Office 365 Admin Center gibt es eine eigene Einstellung zu "Modern Authentication"


https://admin.microsoft.com/#/Settings/Services
Quelle: https://admin.microsoft.com/#/Settings/Services/:/Settings/L1/AdoptionScore

Hier sehen Sie auch noch einmal die Information, dass auf diesem Tenant schon "Security Defaults" aktiviert sind und daher SMTP AUTH und alle anderen "Basic Auth"-Anmeldungen geblockt sind.

Wenn Sie Security Defaults aktiviert haben, können Sie auch nicht per SMTP mit BasicAuth Mails als Postfach versenden.

Sie können aber Security Defaults im Azure Portal (https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties ) abschalten und im Office Portal dann Modern Auth für alle Protokolle außer SMTP AUTH aktvieren.

DAs ist aber noch nicht alles, denn auch auf dem Exchange Level können Sie SMTPAuth auf dem Exchange Online Tenant deaktivieren und auch pro Benutzer können Sie SMTPAuth steuern. Das beschreibt Microsoft auch auf:

Achtung Authentifizierung (AuthN) und Authorization (AuthZ):
Es gibt einen Unterschied zwischen Authentifizierung (AuthN) und Authorization (AuthZ). Security Defaults und Conditional Access wirken auf AuthN-Level, d.h. ein Angreifer bekommt nur ein Authentication Failed".  Die Exchange-Konfiguration wirkt erst nach erfolgreicher Authentifizierung. Ein Angreifer bekommt dann einen anderen Fehler, der ihm aber verrät, dass die Kombination aus Benutzer und Kennwort schon richtig war und nur BasicAuth nicht erlaubt war

Ein Abbruch der Verbindung auf dem AuthN-Level liefert ein

The IMAP server responded with an error status "2 NO LOGIN failed.".

Wenn hingegen die AuthN erfolgreich ist und der Anwender dann auf der AuthZ-Level durch eine Set-CASMailbox-Einstellung kein POP/IMAP/SMTP nutzen darf, dann kommt eine andere Fehlermeldung:

The IMAP server responded with an error status "3 BAD User is authenticated but not connected.".

Ein Angreifer weiß dann aber, dass er gültige Anmeldedaten vorliegen hat und nutzt dann andere Zugangswege, z.B. EWS etc.

Wenn ich dann Conditional Access, Security Defaults, ModernAuth und Exchange Policies zusammenbringe, dann leite ich folgendes Diagramm für den Versand per "SMTP AUTH" her (ohne Gewähr).

Für den Abruf von Mails per POP/IMAP gelten natürlich die Einstellungen von "SMTPClientAuthenticationDisabled" auf dem Transport (Global) oder der CASMailbox nicht. Der Zugriff per POP3/IMAP4 mit "BasicAuth" bleibt nach dem 31.12.2022 abgeschaltet

Wenn Sie aber nun Exchange Clients haben, die per SMTP-Auth eine Mail als Postfachbenutzer ohne ModernAuth/OAUTH senden müssen. dann bleibt ihnen nichts anderes übrig, als die Security Defaults abzuschalten. Ohne eine AzureAD-P1-Lizenz können Sie nur manuell pro Benutzer die MFA-Anforderungen konfigurieren.

Use Authentication Policies to Fight Password Spray Attacks
https://techcommunity.microsoft.com/t5/exchange-team-blog/use-authentication-policies-to-fight-password-spray-attacks/ba-p/3643487

New-AuthenticationPolicy
https://learn.microsoft.com/en-us/powershell/module/exchange/new-authenticationpolicy?view=exchange-ps

Azure AD Sign-In Logs

Da Microsoft im Herbst 2022 sowohl die "Security Defaults" aktiviert als auch BasicAuth in Exchange abschaltet, hat es natürlich auch einen SMTP-Sender in einen meiner Tenants erwischt, welcher per SMTP AUTH eine Mail versenden wollte. Ein Blick im Azure-Portal (https://portal.azure.com) zeigt beim Benutzerkonto in den "Sign-on logs" die fehlerhaften Anmeldungen. Sollten Sie keine fehlerhaften Anmeldungen bei dem Benutzer sehen, dann konnte das AzureAD den Benutzernamen nicht ermitteln.

In den Details finden wir bei "Conditional Access" dann die Security Defaults. Dieser Tenant hat keine AzureAD 1 Lizenz.

Die "Security Defaults" sind im Grunde auch nur eine "Conditional Access Policy", deren Entscheidung ich sogar direkt auswerten kann.

Wenn ich hier aber auf "Security Defaults" klicke, dann bekomme ich einen Fehler (Stand 18. Okt 2022)

Das dürfte daran liegen, dass dieser Tenant keine Azure AD P1/P2 Lizenz für Conditional Access hat. Dennoch helfen die AzureAD Sign-In-Logs auch bei der Analyse von Anmeldeproblemen mit "Security Defaults"

Weitere Links