Legacy Authentication kontrolliert abschalten - Abschaltung
Artikelübersicht
Dies der letzte Teil der Serie zum Thema “Legacy Authentication kontrolliert abschalten”.
Den Anfang verpasst? Dann lieber beim Vorwort anfangen.
- Vorwort
- Modern Authentication aktivieren
- Voraussetzungen schaffen
- Einblicke gewinnen
- Die ersten 90%
- Die nächsten 9%
- Abschaltung
Wiederholung
Eine gute Stück arbeit liegt hinter die wenn du hier angekommen bist. Beginnend mit den notwendigen Vorarbeiten, den erforderlichen Anpassungen, über das Reporting und Ausnahmelisten pflegen.
Die größte Hürde für den nächsten Schritt war aber sicherlich die letzten 9%. Jede Sonderlocke zu finden und zu entfernen ist aufwändig und zeitaufreibend. Je nach Umgebung kann dieser letzte Schritt von wenigen Tagen, bis hin zu einem halben Jahr dauern.
Jetzt gilt es die letzten Schlupflöcher zu schließen und nach der letzten Kontrolle nicht mehr benötigte Ressourcen zu entfernen.
Letzte Kontrollen
Ausnahmegruppe
Die Gruppe CAPolicy-Exclude-Block-Legacy-Authentication sollte keine Mitglieder mehr haben. Nur wer in dieser Gruppe war, konnte nach dem letzten Artikel noch die Sperre umgehen.
Workbook
Im Entra ID (Azure AD) Workbook “Sign-ins using Legacy Auth” dürfen keine erfolgreichen Anmeldungen registriert werden.
Der aufmerksame Leser fragt sich jetzt weshalb ich “Keine erfolgreiche Anmeldungen” schreibe, obwohl das Workbook doch ganz klar 69 erfolgreiche Anmeldungen anzeigt.
Hier trifft wieder das Phänomen Exchange ActiveSync zu. Alle erfolgreichen Anmeldungen haben mit diesem Protokoll stattgefunden und wenn alle Schritte sauber bearbeitet wurden, haben alle Benutzer hier auftauchen nur eine einzige E-Mail in Ihrem Postfach. Und diese E-Mail hat den Betreff “Your email access has been blocked”.
Was genau hier passiert ist in Teil vier im Kapitel Rollenspiele näher erläutert.
Die oder der Benutzer wird wohl nach der Umstellung auf Outlook für iOS oder Android das ActiveSync Konto nicht manuell entfernt haben. Wen das stört, der muss auf diese Benutzer zugehen. Anmelden kann sich aber mit diesem Protokoll keiner mehr.
Und ein Bild wie dieses, werden aber wohl die wenigsten sehen.
Wer sich mittlerweile mit Kusto angefreundet hat kann auch diese angepasste Abfrage nutzen
|
|
SharePoint Online und B2B Gast Benutzer
Um Legacy Authentication für B2B Gastbenutzer komplett zu deaktivieren, muss das Protokol in SharePoint deaktiviert werden.
# Install SharePoint PowerShell module
Install-Module -Name Microsoft.Online.SharePoint.PowerShell -Scope CurrentUser
# Connect to your tenant
Connect-SPOService -Url https://YOURTENANT-admin.sharepoint.com
# Disable legacy authentication
Set-SPOTenant -LegacyAuthProtocolsEnabled $false
Exchange Online
Update 08.03.2022
Auf Twitter hat David Caddick mir eine interessante Anmerkung zukommen lassen und am selben Tag hat Nate Hut einen guten Blog Post dazu veröffentlicht weshalb man Legacy Auth zusätzlich deaktivieren sollte, auch wenn es diese Logins schon mittels Conditional Access Policy blockiert werden.
Für Exchange Online ist das sehr einfach.
# Install Exchange Online Module
Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser
# Connect to your tenant
Connect-ExchangeOnline
# Create a authentication policy, defaults to blocking all legacy protocols
New-AuthenticationPolicy -Name "Block Legacy Auth"
# Activate the authentication policy for the Exchange organization
Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Legacy Auth"
Der größte Vorteil dieser Methode ist, dass du keine fehlgeschlagenen Anmeldungen mehr in den Sign-In Logs sehen werden.
Clients, die OAuth als Alternative unterstützen, wie die iOS Mail App, wechseln automatisch das Protokoll. In den Logs können also immer noch Fehlermeldungen auftauchen, solange der Benutzer keine Multi-Faktor-Authentifizierung durchführt.
Conditional Access Policies
Common Policy: Block legacy authentication
Es ist an der Zeit Ausnahmen nicht mehr zuzulassen und die bisher im Report-Only Modus laufende Policy scharf zu schalten.
Dabei ist es wieder wichtig beim speichern, den eigenen Benutzer nicht von der Policy auszuschließen.
Temporäre Policies löschen
Je nachdem welchen Weg man bei der Deaktivierung von Exchange ActiveSync gewählt hat, gibt es jetzt noch ein bzw. zwei Policies die nicht mehr benötigt werden.
- Temporary Policy: Block legacy authentication Rollout
- Temporary Policy: Block ActiveSync clients
Beide können, nach der Aktivierung der allgemeinen “Block legacy authentication” Policy, gelöscht werden. Die erste Richtlinie sorgt zuverlässig dafür, dass nur noch Modern Authentication genutzt werden kann.
Gruppen löschen
Die beiden Ausnahmegruppen werden evenfalls nicht mehr benötigt und können gelöscht werden.
- CAPolicy-Include-Block-Legacy-Authentication
- CAPolicy-Exclude-Block-Legacy-Authentication
Abgeschaltet
Du hast es geschafft. Keine Benutzer in deiner Umgebung nutzt mehr Legacy Authentication.
Das ist ein großer Gewinn an Sicherheit und erlaubt es in Zukunft viele neue Funktionen wie Conditional Access authentication context einzusetzen.
Und sollte es doch nochmal ein Benutzer, wie hier Alice versuchen, wird er abgewiesen.
Fragen, Anregungen, Korrekturen?
Wenn dir die Blogreihe gefallen hat dann folge mit auf Twitter und abonniere diesen Blog. Oder wenn es die besonders gut gefallen hat, gib mir ein Bier 🍺 aus.
Du hast einen Fehler entdeckt oder hast Fragen? Dann schreib mir auf Twitter oder per E-Mail.