Legacy Authentication kontrolliert abschalten - Die nächsten 9%
Artikelübersicht
Dies ist Teil fünf 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
Nachdem wir im letzten Teil einen Großteil der Benutzer, die Legacy Authentication nicht nutzen, für die Nutzung deaktiviert haben, ist es nun an der Zeit mit den in Teil drei vorgestellten Methoden die noch betroffenen Benutzergruppen zu identifizieren.
Mit diesem Daten wird ein Aktionsplan für die Abschaltung von Legacy Authentication bei diesen Benutzergruppen erstellt. Zusätzlich werden die Daten genutzt um die Conditional Access Policy Temporary Policy: Block legacy authentication Rollout
in Phase 2 zu überführen.
Benutzergruppen
Outlook
Outlook unterstützt ab Outlook 2013 (Windows) bzw. Outlook 2016 für Mac Modern Authentication. Alle älteren Versionen unterstützen keine Modern Authentication und müssen aktualisiert werden.
Outlook 2010
Sollte noch Office 2010 in der Fläche genutzt werden, gilt es ein Migrationsprojekt zu starten und umzusetzen. Gerade beim Einsatz von Makros und Addons kann dies eine sehr umfangreiche Aufgabe sein. Ist eine Abschaltung von Legacy Authentication vor der Umstellung von Office notwendig kann Outlook im Web als Alternative genutzt werden.
Benutzer identifizieren
Die zu Verfügung gestellten Workbooks “Sign-ins using Legacy Auth” und “Conditional Access Insights and Reporting” helfen für die geplante Auswertung nur sehr begrenzt. Die wichtigste Information, der genutzte Client (UserAgent), fehlt in der Auswertung.
Daher nutzen wir wieder Kusto, um direkt die den Workbooks zugrundeliegenden Daten abzufragen.
Im Azure Portal “Azure Active Directory” auswählen und im Abschnitt Monitoring “Logs” auswählen und die folgende Abfrage einfügen und ausführen. Dabei unbedingt darauf achten, dass der Zeitraum der Abfrage auf “Set in query” eingestellt ist.
|
|
Die Abfrage gibt eine Liste mit allen Personen aus, die noch Outlook 2010 (interne Versionsnummer 14.0)
Sollte die Gefahr bestehen das noch ältere Versionen von Outlook im Einsatz sind kann die Versionsnummer in der Abfrage entsprechend angepasst werden.
|
|
Produktname | Versionsnummer |
---|---|
Outlook 2010 | 14.0 |
Outlook 2007 | 12.0 |
Outlook 2003 | 11.0 |
Aktionsplan
- Betroffene Benutzer in die Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” aufnehmen
- Rollout einer aktuellen Office Version veranlassen
- Alternativen prüfen: Outlook im Web
- Umgestellte Benutzer aus der Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” entfernen
Outlook 2013
Bei Outlook 2013 ist Modern Authentication nicht der Standard und muss per Registry Key aktiviert werden.
Wenn möglich sollte eine entsprechende Gruppenrichtlinie erstellt und an die betroffenen Benutzer verteilt werden. Da es sich hierbei nicht um eine Standardeinstellung in den Gruppenrichtlinien handelt, müssen die beiden Registry Keys manuell hinzugefügt werden.
Alternativ können die Werte auf per Skript gesetzt werden.
$RegistryPath = "HKCU:\Software\Microsoft\Office\15.0\Common\Identity"
if ( -not ( Get-Item $RegistryPath -ErrorAction SilentlyContinue) ) {
New-Item $RegistryPath -Force | Out-Null
}
New-ItemProperty $RegistryPath -Name Version -PropertyType DWORD -Value 1 -Force | Out-Null
New-ItemProperty $RegistryPath -Name EnableADAL -PropertyType DWORD -Value 1 -Force | Out-Null
Benutzer identifizieren
|
|
Aktionsplan
- Betroffene Benutzer in die Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” aufnehmen
- Rollout der Gruppenrichtlineneinstellungen
- Nach einer Woche prüfen ob die Gruppenrichtlinien den gewünschten Erfolg zeigen
- Umgestellte Benutzer aus der Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” entfernen
Microsoft 365 Apps for Enterprise, Outlook 2016 und später
Modern Authentication ist standardmäßig aktiviert und es ist keine weitere Aktion notwendig.
Exchange ActiveSync
Bei Exchange ActiveSync ist die einfachste Alternative der Umstieg auf Outlook für iOS und Android.
Der Vorteil bei der Umstellung auf die Outlook App, im Gegensatz zu anderen Modern Auth fähigen Clients, ist das später weitere Funktionen von Microsoft 365 genutzt werden können.
Dazu gehören z.B.
Weitere Informationen dazu finden sich im FAQ.
Native Apps wie iOS Mail und GMail müssen vor der Nutzung explizit freigegeben werden, wenn Benutzer nicht das Recht haben Anwendungen selbst freizugeben.
Für die Abschaltung dieser Benutzergruppe gibt es noch einen alternativen Weg. Durch den Einsatz einer weiteren Conditional Access Policy können explizit nur Exchange Active Sync verboten werden. So werden Benutzer die Outlook 2010 und Exchange ActiveSync nicht verfrüht aus der Ausnahmegruppe entfernt.
Dieser Weg ist jedoch optional und für die Abschaltung nicht erforderlich.
Benutzer identifizieren
|
|
Nachdem die Benutzer identifiziert wurden, müssen diese über die Änderung informiert werden.
Bei der Kommunikation empfiehlt sich eine zweitstufige Benachrichtigung per E-Mail.
Erste E-Mail
Die erste E-Mail wird eine Woche vor der Abschaltung versendet und enthält die notwendige Dokumentation für den Umstieg, z.B. für die Installation und Einrichtung der Outlook für iOS und Android App.
Um den Umstieg auf Outlook for mobile so einfach wie möglich zu gestalten bietet Microsoft Spickzettel für diese Produkte an. In diesen Dokumenten sind die Kernfunktionen von Outlook auf zwei Seiten zusammengefasst. Diese können, wenn gewünscht, ebenfalls in die Kommunikation aufgenommen werden.
Erinnerungs-E-Mail
Die zweite E-Mail dient als letzte Erinnerung und wird einen Tag vor der Abschaltung versendet.
Informieren Sie auch Ihren 1st Level Support, damit dieser bei der untenstehenden Fehlermeldung, die Nutzung eines ActiveSync Clients identifiziert und dem Nutzung die INstallation Outlook für iOS und Android rät.
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.
Aktionsplan
- Betroffene Benutzer in die Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” aufnehmen
- Optional: Conditional Access Policy “Temporary Policy: Block ActiveSync clients” anlegen
- Erste Kommunikation an die Benutzer ca. 1 Woche vor der Abschaltung
- Am Tag vor der Abschaltung, erneute Kommunikation an die Benutzer
- Standard: Zum kommunizierten Termin die Benutzer aus der Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” entfernen
- Optional: Zum kommunizierten Termin die Conditional Access Policy “Temporary Policy: Block ActiveSync clients” aktivieren.
POP3 und IMAP Clients
Bei Nutzern von POP3 und IMAP Clients sollte ebenfalls auf die Alternative Outlook für iOS und Android hingewiesen werden.
Jedoch ist es bei diesen Protokollen auch nicht unüblich, dass ein Servicebenutzer auf ein Postfach zugreift um E-Mails weiter zu verarbeiten. In diesem Fall ist eine Anpassung der Software notwendig. Bis diese Anpassung durchgeführt wurde, muss der Benutzer in der Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” enthalten bleiben.
Benutzer identifizieren
|
|
Zusätzlich zum Benutzernamen wird noch das genutzte Protkoll ausgegeben.
Aktionsplan
- Betroffene Benutzer in die Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” aufnehmen
- Erste Kommunikation an die Benutzer ca. 1 Woche vor der Abschaltung
- Am Tag vor der Abschaltung, erneute Kommunikation an die Benutzer
- Zum kommunizierten Termin die Benutzer aus der Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” entfernen
SMTP Clients
Bei den SMTP Clients ist in jedem Fall eine Anpassung am Client bzw. an der Methode notwendig.
Anpassung der Client App möglich
Wenn die Client App selbst entwickelt wurde und noch aktiv gepflegt wird bietet sich der Umstieg auf SMTP AUTH mit OAuth 2.0 Support an.
Client App kann nicht angepasst werden
In vielen Fällen wird es leider darauf rauslaufen, dass eine Anpassung der Client App nicht möglich ist und man maximal die Paramater für die Authentifizierung und den Server einstellen kann.
Mailempfänger intern
Wenn nur Postfächer im eigenen Tenant erreicht werden müssen ist der unauthentifizierte Versand über den Server tenantdomain.mail.protection.outlook.com
die einfachste Alternative.
Um zu verhindern, dass die Mails im Spam Order der Benutzer landen, muss die absendene Public IP-Adresse im DNS als Tei des SPF Eintrag gepflegt werden. z.B.
"v=spf1 ip4:12.34.56.78 include:spf.protection.outlook.com -all"
Um die Änderung zu prüfen bietet sich z.B. die Google Admin Toolbox an.
Mailempfänger intern und extern
Wenn auch externe Empfänger angeschrieben werden müssen, reicht die oben genannte Implementierung nicht aus. Es muss noch ein Exchange Connector eingerichtet werden.
Die Anpassung des SPF ist jedoch in jedem Fall notwendig.
Benutzer identifizieren
|
|
Aktionsplan
- Betroffene Benutzer in die Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” aufnehmen
- Mail Flow Best Pratices von Microsoft umsetzen
- Umgestellte Benutzer aus der Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” entfernen
Andere Clientapplikationen
Die oben genannten Usecases dürften für einen Großteil der noch verbliebenen Anwender zutreffen. Für alle anderen Anwender gilt es, gemeinsam mit dem Anwender zu prüfen welche Applikation noch Legacy Authentication nutzt und diese zu ersetzten.
Eine Blaupause für dieses Vorgehen gibt es nicht. Jedoch gibt der UserAgent einen guten Hinweis auf die genutzte Applikation.
Beispiele sind z.B.
UserAgent | Applikation | Migration |
---|---|---|
Mac+OS+X/10.15.7 (19H524) CalendarAgent/930.5.1 |
Apple Kalender | Outlook für Mac |
AppleExchangeWebServices/807 ExchangeSync/121 |
MacOS Mail | Outlook für Mac |
Microsoft WinRM Client |
Veraltetes PowerShell Modul | Siehe diese Auflistung |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
Thunderbird | Outlook im Web |
Benutzer identifizieren
|
|
Aktionsplan
- Betroffene Benutzer in die Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” aufnehmen
- Zusammen mit dem Benutzer die Migrationsmöglichkeiten prüfen
- Umgestellte Benutzer aus der Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” entfernen
Umstellung auf “Explizites Erlauben”
Nachdem alle betroffenen Benutzerkonten identifiziert wurden und für den Umstellungzeitraum Mitglied der Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” sind, ist es Zeit Phase 2 zu starten.
In dieser Phase wird die Conditional Access Policy Temporary Policy: Block legacy authentication Rollout
so konfiguriert, dass jeder Benutzer geblockt wird, der nicht explizit Mitglied der Gruppe ist.
So werden neue Benutzer sofort geschützt und macht es leichter Benutzer nach und nach aus der Ausnahmegruppe zu entfernen.
Gruppe befüllen
Um die Gruppe zu befüllen bietet sich das Skript aus Teil 4 an.
Es muss lediglich in Zeile 4 der Dateipfad und in Zeile 5 der Gruppenname angepasst werden.
|
|
Die benötigten CSV Dateien können mit den oben vorgestellten Kusto Abfragen und der Export Funktion erstellt werden.
Conditional Access Policy anpassen
Im Azure Active Directory Portal unter “Security” -> “[Conditional Access](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies" die Richtlinie “Temporary Policy: Block legacy authentication Rollout” auswählen.
Im Bereich “Users and groups” unter “Include” die Option “All guest and external users” auswählen und unter “Exclude” sicherstellen das der Breakglass Account sowie die Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” ausgewählt sind.
Anschließend die Conditional Access Policy speichern.
Mit dieser Änderung ist ein Großteil der Benutzer nicht mehr in der Lage Legacy Authentication zu nutzen.
Nun gilt es anhand des oben definierten Aktionsplans die Mitglieder der Gruppe “CAPolicy-Exclude-Block-Legacy-Authentication” ebenfalls von der Nutzung abzubringen.
Nächste Schritte
Die Umsetzung der oben genannten Aktionen wird mit ziemlicher Sicherheit einige Zeit in Anspruch nehmen.
Pflegen Sie die Gruppe mit den Ausnahmen akribisch, um zu verhindern, dass Anwender noch in der Liste stehen obwohl Sie Legacy Authentication gar nicht mehr nutzen.
Prüfen Sie in regelmäßigen Abständen, ob die Gesamtzahl der Anwender die Legacy Authentication nutzen geringer wird. Nutzen Sie dazu das Workbook “Conditional Access Insights and Reporting” und filtern Sie auf die Report-Only Policy “Common policy: Block legacy authentication” und die fehlerhaften Loginversuche.
Im letzten Teil der Serie beschäftigen wir uns mit den Nacharbeiten und dem letzten 1%.
Optionaler Schritt: Block Exchange ActiveSync Conditional Access Policy
Wenn wie oben beschrieben, die Exchange ActiveSync Client, unabhängig von der Ausnahmeliste blockiert werden sollen, muss die folgende Conditional Access Policy angelegt werden.
Nach der Anlage ist Sie im Report Only Modus und hat noch keine Auswirkungen. Erst wenn Sie aktiviert wird, können die Anwender Exchange ActiveSync nicht mehr verwenden.
- Im Entra ID (Azure AD) Portal unter Security -> Conditional Access eine neue Richtlinie mit dem Namen “Temporary Policy: Block ActiveSync clients” anlegen
- Unter Assignments -> “Users and groups” auswählen
- Include: “All users”
- Exclude: Break Glass Account
- Include: “All users”
- Unter Assignments -> “Cloud apps or actions” -> “Select apps” -> “Office 365 Exchange Online” auswählen
- Bei “Conditions” -> “Device platforms” “Android”, “iOS” und “Windows Phone” auswählen
- Bei “Conditions” -> “Client apps” unter Legacy authentication ausschließlich “Exchange ActiveSync Clients” auswählen
- Als “Access controls” -> “Grant” die Option “Block access” wählen
- Zuletzt noch die Policy auf “Report-Only” stellen und erstellen.
Den aktuellen Benutzer nicht von der Richtlinie ausschließen. Dafür ist der Break Glass Account gedacht und die Richtlinie ist zusätzlich nur im Status Report Only.