Legacy Authentication kontrolliert abschalten - Die ersten 90%
Artikelübersicht
Dies ist Teil vier der sechsteiligen Serie zum Thema “Legacy Authentication kontrolliert abschalten”.
- Vorwort
- Modern Authentication aktivieren
- Voraussetzungen schaffen
- Einblicke gewinnen
- Die ersten 90%
- Die nächsten 9%
- Abschaltung
Wiederholung
In den ersten drei Teilen der Serie wurden die Voraussetzungen (1/2) für die Abschaltung geschaffen und anhand von Entra ID (Azure AD) Workbooks und Kusto-Abfragen die ersten Benutzer identifiziert.
AAD Gruppe mit Leben füllen
Um direkt durchstarten zu können muss die Entra ID (Azure AD) Gruppe CAPolicy-Include-Block-Legacy-Authentication
mit den Benutzern aus der letzten Abfrage befüllen. /
So wird verhindert, dass diese Benutzer in den nächsten Wochen mit der Nutzung von Legacy Authentication Protokollen beginnen.
Wer besonders vorsichtig seien möchte, kann den Zeitraum in der Abfrage auf z.B. 30 Tage erhöhen.
|
|
Das Ergebnis der Abfrage kann als CSV exportiert werden.
Sollte der Anteil der Benutzer ohne Nutzung von Legacy Authentication bei über 90% liegen kann auch direkt mit Phase 2 weitergemacht werden.
Dieser Artikel erscheint voraussichtlich am 06.03.2021.
Bis dieser veröffentlicht ist, bietet es sich an einfach weiter mitzumachen.
Das folgende Skript fügt alle Benutzer aus der heruntergeladenen CSV Datei query_data.csv
in die Entra ID (Azure AD) Gruppe CAPolicy-Include-Block-Legacy-Authentication
.
|
|
Nach dieser Aktion können sich all diese Benutzer nicht mehr mittels Legacy Authentication anmelden. Die Conditional Access Policy Temporary Policy: Block legacy authentication Rollout
blockt diese Verbindungen. Da diese Benutzer in den letzten 7 Tagen Legacy Authentication nicht eingesetzt hatten, ist nicht mit einer negativen Auswirkung für den Endanwender zu rechnen.
Sollte die Gruppe im on-Prem AD angelegt worden sein und dort gepflegt werden, muss berücksichtigt werden das Änderungen erst nach dem nächsten erfolgreichen AAD Connect Sync wirksam werden.
Den Sync Vorgang kann man mit folgendem cmdlet in einer elevated PowerShell direkt starten.
Start-ADSyncSyncCycle -PolicyType Delta
Rollenspiel - Was passiert beim Anwender?
Eigentlich wäre die Arbeiten für diesen Schritt hiermit erledigt. Ein großer Anteil der Benutzer ist jetzt gegen Attacken wie Password Spray oder Credential Stuffing besser geschützt. MFA ist ja schon aktiviert, oder?
Aber um die Auswirkungen der Änderung besser zu verstehen, werfen wir einen Blick auf die andere Seite.
- Wie wirkt sich die Abschaltung für den Anwender aus?
- Mit welchen Auswirkungen muss man rechnen?
- Wo kann man jetzt schon etwas vorbereiten oder umstellen?
Exchange ActiveSync
Wie schon in Teil 3 erwähnt, geht vor Exchange ActiveSync Dienst sehr speziell mit der Deaktivierung um.
Denn anstatt die Verbindung sofort abzulehnen und dem Benutzer eine nicht weiter definierte Fehlermeldung vom Mailclient auszusetzen, hat sich Microsoft entschieden die Anmeldung weiterhin zuzulassen. Nautrlich nur wenn das korrekte Kennwort genutzt wird.
In den entsprechenden SignIn Logs wird dies wie folgt angezeigt:
Was auf den ersten Blick wie ein erfolgreicher Login aussieht ist aber keiner. Die Spalte Conditional access
zeigt korrekterweise “Failure”.
Im Tab “Conditional Access” wird dann auch deutlich, dass die Temporary Policy: Block legacy authentication Rollout
den Zugriff blockiert hat.
Die Auflösung, weshalb es zu diesem etwas komisch anmutenden Szenario kommt zeigt der Blick aufs Smartphone des Benutzers.
Anstatt alle E-Mails angezeigt zu bekommen, wird dem Anwender nur eine einzige E-Mail angezeigt. Diese trägt den Titel “Your email access has been blocked”.
Der Inhalt der Nachricht enthält eine etwas ausführlichere, wenn auch nicht immer hilfreichere Nachricht an den Benutzer.
You are receiving this message because your IT department has blocked your email access. This could be due to temporary conditions, like your network location.
Contact your IT department with any questions or concerns about this mail. This email was automatically generated by Microsoft Exchange.
POP3, IMAP und SMTP Clients
Der Zugriff mittels POP3 oder IMAP wird mit einem entsprechenden Fehler quittiert. Thunderbird z.B. lässt den Anwendern nicht ganz im Regen stehen und weist darauf hin, dass die gewählte Konfiguration eventuell vom Administrator deaktiviert wurde.
Je nach verwendetem E-Mail Client sehen die Ergebnisse natürlich sehr unterschiedlich aus.
Für SMTP Clients ist die Abschaltung noch problematischer. Gerade in gewachsenen IT Umgebungen senden MFP Geräte und Appliances per SMTP E-Mails an die eigenen Benutzer oder externe Partner. Wenn es sich nicht um einen Hybrid Exchange Setup handelt, bei dem der lokale Exchange Server noch SMTP Relay spielt, ist nach dem Abschalten von Legacy Authentication Schluss mit E-Mails.
Microsoft arbeitet an einer Lösung: OAuth 2.0 Support für IMAP und SMTP AUTH. Realistisch gesehen wird diese Lösung aber nicht mehr in die alte Drucker Firmware oder die UPS Software im Keller implementiert werden.
Eine Alternative bietet daher der unauthentifizierte Versand der Nachrichten direkt an den Firmen MX Endpunkt (bader-cloud.mail.protection.outlook.com) und dem Pflegen des SPF Records für die absendende IP-Adresse.
Oder, wenn auch externer Mailversand möglich sein muss, das zusätzliche Einrichten eines Exchange Connectors.
Eine Übersicht über die Vor- und Nachteile dieser Lösungen hat Microsoft hier aufgelistet.
Teams Rooms
Teams Rooms Systeme unterstützten Modern Authentication seit Version 4.4.25.0 (31.03.2020).
In einer kleineren Umgebung kann dies, manuell an jedem Gerät geändert werden. Bei größeren Umgebungen kann über ein Client Management Tool oder ein Skript eine SkypeSettings.xml
Datei in den Ordner C:\Users\Skype\AppData\Local\Packages\Microsoft.SkypeRoomSystem_8wekyb3d8bbwe\LocalState
auf den Geräten kopiert werden.
<SkypeSettings>
<UserAccount>
<ModernAuthEnabled>true</ModernAuthEnabled>
</UserAccount>
</SkypeSettings>
Diese XML Datei ändert den Standardwert von False
auf True
und verhindert ein Fallback auf Legacy Authentication.
PowerShell Module
Sollten immer noch alte PowerShell Module für das Management der Microsoft 365 Umgebung genutzt werden, ist es an der Zeit die entsprechenden Administratoren über die neueren Alternativen zu informieren.
- Azure Active Directory PowerShell for Graph
- Microsoft Azure Active Directory Module for Windows PowerShell
- Skype for Business Online Abgelöst durch das Microsoft Teams PowerShell Module
- Exchange Online & Security & Compliance Center
- Microsoft Teams
Die Fehlermeldung, die der Anwender hier angezeigt bekommt, ist schlichtweg ein AccessDenied
.
Andere Clients
Fast alle anderen Clients werden dem Benutzer ebenfalls nur ein Access Denied anzeigen und keine weiteren Informationen zur Ursache liefern können.
Daher ist es unverzichtbar den Support entsprechend zu informieren, damit dieser entsprechend reagieren kann und nicht nach einem deaktivieren Benutzer oder einem falschen Kennwort als Ursache sucht. Es bietet sich zusätzlich an dem Support Zugriff auf die Entra ID (Azure AD) SignIn Logs für die Analyse zu geben. Dieser kann über die Mitgliedschaft in der Rolle Reports reader
aktiviert werden.
Nächste Schritte
Im nächsten Teil der Serie werden die betroffnen Benutzer identifiziert und auf Basis des heute gelernten Zielgruppen gerecht informiert.