Legacy Authentication kontrolliert abschalten - Die nächsten 9%

Artikelübersicht

Dies ist Teil fünf der sechsteiligen Serie zum Thema “Legacy Authentication kontrolliert abschalten”.

1. Vorwort
2. Modern Authentication aktivieren
3. Voraussetzungen schaffen
4. Einblicke gewinnen
5. Die ersten 90%
6. Die nächsten 9%
7. 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.

1
2
3
4
5
6
7
8
9

SigninLogs
// set TimeSpan to 7 days
| where TimeGenerated > ago(7d)
// Only query successful logins
| extend errorCode = toint(Status.errorCode)
| where errorCode == 0
// Only Outlook 2010
| where UserAgent contains "Microsoft Office/14.0"
| distinct UserPrincipalName

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.

7
8

// Only Outlook 2010 and before
| where UserAgent contains "Microsoft Office/14.0" or UserAgent contains "Microsoft Office/12.0" or UserAgent contains "Microsoft Office/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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

SigninLogs
// set TimeSpan to 7 days
| where TimeGenerated > ago(7d)
// Only query successful logins
| extend errorCode = toint(Status.errorCode)
| where errorCode == 0
// Check if ClientAppUsed is considered Legacy Auth - Empty is not considered Legacy Auth
| extend ClientAppUsed = iff(isempty(ClientAppUsed) == true, "Unknown", ClientAppUsed)  
| extend isLegacyAuth = case(ClientAppUsed contains "Browser", "No", ClientAppUsed contains "Mobile Apps and Desktop clients", "No", ClientAppUsed contains "Exchange ActiveSync", "Yes", ClientAppUsed contains "Unknown", "Unknown", "Yes") 
| where isLegacyAuth == "Yes"
// Only Outlook 2013
| where UserAgent contains "Microsoft Office/15.0"
| distinct UserPrincipalName

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.

• App protection policies
• Sensitivity labeling and protection
• Azure Rights Management data protection

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

1
2
3
4
5
6
7

SigninLogs
| where TimeGenerated > ago(7d)
// Only query successful logins
| extend errorCode = toint(Status.errorCode)
| where errorCode == 0
| where ClientAppUsed == "Exchange ActiveSync"
| distinct UserPrincipalName

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.

• Spickzettel für Outlook für iOS
• Spickzettel für Outlook für Android

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.

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

SigninLogs
// set TimeSpan to 7 days
| where TimeGenerated > ago(7d)
// Only query successful logins
| extend errorCode = toint(Status.errorCode)
| where errorCode == 0
// Check if ClientAppUsed is considered Legacy Auth - Empty is not considered Legacy Auth
| extend ClientAppUsed = iff(isempty(ClientAppUsed) == true, "Unknown", ClientAppUsed)  
| extend isLegacyAuth = case(ClientAppUsed contains "Browser", "No", ClientAppUsed contains "Mobile Apps and Desktop clients", "No", ClientAppUsed contains "Exchange ActiveSync", "Yes", ClientAppUsed contains "Unknown", "Unknown", "Yes") 
| where isLegacyAuth == "Yes"
| where ClientAppUsed in ("POP3","IMAP4")
| distinct UserPrincipalName, ClientAppUsed

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

SigninLogs
// set TimeSpan to 7 days
| where TimeGenerated > ago(7d)
// Only query successful logins
| extend errorCode = toint(Status.errorCode)
| where errorCode == 0
// Check if ClientAppUsed is considered Legacy Auth - Empty is not considered Legacy Auth
| extend ClientAppUsed = iff(isempty(ClientAppUsed) == true, "Unknown", ClientAppUsed)  
| extend isLegacyAuth = case(ClientAppUsed contains "Browser", "No", ClientAppUsed contains "Mobile Apps and Desktop clients", "No", ClientAppUsed contains "Exchange ActiveSync", "Yes", ClientAppUsed contains "Unknown", "Unknown", "Yes") 
| where isLegacyAuth == "Yes"
| where ClientAppUsed contains "Authenticated SMTP"
| distinct UserPrincipalName

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.

Benutzer identifizieren

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

SigninLogs
// set TimeSpan to 7 days
| where TimeGenerated > ago(7d)
// Only query successful logins
| extend errorCode = toint(Status.errorCode)
| where errorCode == 0
// Check if ClientAppUsed is considered Legacy Auth - Empty is not considered Legacy Auth
| extend ClientAppUsed = iff(isempty(ClientAppUsed) == true, "Unknown", ClientAppUsed)  
| extend isLegacyAuth = case(ClientAppUsed contains "Browser", "No", ClientAppUsed contains "Mobile Apps and Desktop clients", "No", ClientAppUsed contains "Exchange ActiveSync", "Yes", ClientAppUsed contains "Unknown", "Unknown", "Yes") 
| where isLegacyAuth == "Yes"
| where ClientAppUsed !in ("IMAP4","POP3","Authenticated SMTP", "Exchange ActiveSync")
// Exclude old Office versions
| where UserAgent !contains "Microsoft Office"
// BITS is used for Offline Address Book in older Office versions
| where UserAgent !contains "BITS"
| distinct ClientAppUsed, AppDisplayName, UserAgent, UserPrincipalName

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.

4
5

$Users = Import-Csv -Path .\Downloads\query_data.csv -Delimiter "," -Encoding UTF8
$TargetGroupName = "CAPolicy-Exclude-Block-Legacy-Authentication"

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.

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.

1. Im Entra ID (Azure AD) Portal unter Security -> Conditional Access eine neue Richtlinie mit dem Namen “Temporary Policy: Block ActiveSync clients” anlegen
2. Unter Assignments -> “Users and groups” auswählen
   1. Include: “All users”
      
   2. Exclude: Break Glass Account
      
3. Unter Assignments -> “Cloud apps or actions” -> “Select apps” -> “Office 365 Exchange Online” auswählen
   
4. Bei “Conditions” -> “Device platforms” “Android”, “iOS” und “Windows Phone” auswählen
   
5. Bei “Conditions” -> “Client apps” unter Legacy authentication ausschließlich “Exchange ActiveSync Clients” auswählen
   
6. Als “Access controls” -> “Grant” die Option “Block access” wählen
   
7. 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.