ADFS Extranet Lockout

Ein ADFS-Server ist in der Regel auch aus dem Internet erreichbar, damit Anwender überall auf der Welt sich am ADFS-Service authentifizieren können und Tokens für den Zugriff auf die jeweiligen Dienste bekommen kann. Damit öffnen wir natürlich wieder eine Tür, über den Angriffe auf Konten erfolgen können. Aber ADFS enthält einen Schutz, den viele andere Dienste nicht haben: ADFS kann zu viele Fehlversuche erkennen und blockieren.

Exchange ActiveSync, Exchange OWA und viele andere Webseiten haben so einen Schutz nicht und die Firmen haben daher in der Regel ein Portal oder einen Reverse Proxy mit "Pre Authentication" davor geschaltet.

Intranet und Extranet

Der ADFS-Server unterscheidet genau, ob ein Zugriff auf dem internen Netzwerk oder aus dem Internet kommt. Als Kriterium wird dazu der vorgeschaltete ADFS-Proxy genutzt, der einen HTTP-Header (Feld "X-MS-Proxy") in den Request addiert und so dem eigentlichen ADFS-Server mitteilt, dass der Zugriff über den Proxy und damit von extern gekommen ist.

Der gleiche Header wird übrigens auch genutzt, um die Authentifizierung zu bestimmen, die dem Client angeboten wird.

Clients, die im internen LAN sind, sollten daher nie den DNS-Namen auf den ADFS-Proxy auflösen oder über einen HTTP-Proxy auf den ADFS-Server von extern zugreifen. Nur beim direkten internen Zugriff funktioniert z.B.: auch die Windows Authentifizierung (Kerberos/NTLM)

Extranet Lockout konfigurieren

Aber selbst wenn der Zugriff nicht gelingt, weil das Kennwort sicher genug ist oder das Konto gesperrt wird, enthält der ADFS- 2012R2-Server mittlerweile eine Funktion, um zu viele externe Anmeldungen zu verhindern ohne das interne Konto zu sperren. Allerdings ist diese Funktion bei Windows 2012 per Default nicht aktiv. Bei Windows 2016 hingegen schon, wenngleich der Threshold auf 15 Versuche gestellt ist.

Get-AdfsProperties | fl ex*

ExtendedProtectionTokenCheck : Allow
ExtranetLockoutThreshold     : 2147483647
ExtranetLockoutEnabled       : False
ExtranetObservationWindow    : 00:30:00

Mein Ratschlag
Aktivieren Sie diese nützliche Funktion und blockieren Sie den Zugang für Konten über DFS , ehe das Konto intern gesperrt wird.

Die Werte für die Zeitdauer und die Anzahl kann einfach gesetzt werden. Der Parameter für die Aktivierung hingegen lautet etwas anders.

Set-AdfsProperties `
   -ExtranetLockoutThreshold 2 `
   -ExtranetObservationWindow 00:01:00 `
   -EnableExtranetLockout $true

Hier wird nach zwei Versuchen jeder weitere Versuch für weitere 1 Minute unterbunden.

Im Eventlog werden zwar die falschen Anmeldungen protokolliert aber es gibt keinen Eintrag, der ein so gesperrtes Konto identifiziert und damit weitere Anmeldeversuche protokolliert. Auch der Anwender bekommt keinen Hinweis darauf, dass sein Konto für ADFs aktuell gesperrt ist. Als Administrator könnte ich nur die Anzahl der "Failed Login" pro User auf dem ADFS-Server ermitteln und sehen, ob schon so viele fehlerhafte Anmeldungen erfolgt sind, wie im ExtranetLockoutThreshold konfiguriert sind.

Status von Benutzern abfragen

Wenn auf ein Konto ein Angriff gefahren wird, dann wird es nach der eingestellten Zeit an Fehlversuchen durch ADFS gesperrt. Der Anwender kann also nicht mehr über den ADFS-Proxy weitere Authentifizierungen versuchen. Wenn die Werte niedriger als die AD-Lockout-Ricihtlinien eingestellt sind, kann der Anwender weiterhin sich intern anmelden und arbeiten und auch alle Bestandstickets, die er aktuell nutzt, funktionieren natürlich weiter, wenn das Konto nicht gesperrt ist. Ein Angreifer kann auch nicht weiter neue Kennworte über den ADFS-Proxy ausprobieren.

Ob ein Konto nun aber durch ADFS aktuell eingeschränkt ist, sehen Sie einmal im Eventlog aber auch über die Powershell. Interessant sind hier die Werte zu "LastFailed" und "BadPasswordCount"

Get-AdfsAccountActivity `
   -UserPrincipalName <UPN>

LastFailed      : 
BadPasswordCount:  0

Aktuelle PS1 Ausgabe fehlt

ADFS 2016 Smart Lockout Policies

Der mit Windows 2016 installierbare ADFS-Service hat die Lockout-Policies noch etwas verfeinert. Es kommt nicht nur auf den Benutzer an, sondern auch die IP-Adresse des Clients wird mit einbezogen. Dazu installiert ADFS auf dem SQLServer extra eine eigene Tabelle mit dem Namen "ArtifactStore", auf der Sie aber erst noch die Berechtigungen anpassen müssen. Allerdings können Sie dabei auch einen Fehler bekommen.

# Anmeldeinformationen eines Administrators einholen
$cred=Get-Credential
Update-AdfsArtifactDatabasePermission -Credential $cred
Update-AdfsArtifactDatabasePermission : PS0359: Node adfs01.msxfaq.de does not have all updates installed.
This node must be updated before permissions can be granted.  
See https://go.microsoft.com/fwlink/?linkid=864556 for more information.

Das Update KB4103720 löst einige ADFS-Probleme und ist vom Mai/Juni 2018.

  • 2018-05 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4103720)

Dumm nur, wenn der Server schon viel neuer ist und die PowerShell das einfach nicht versteht. Sie scheint genau diesen KB-Patch zu suchen. Eine Lösung ist aber einfach. Sie müssen sich einfach mit der SQL-Datenbank verbinden und einen Befehl ausführen.

Nun ist es so, dass die meisten ADFS-Server vermutlich mit der Windows Internal Database "WID" installiert werden. Diese Datenbank ist nur lokal erreichbar. Ich möchte aber nicht ein vollwertiges SQL-Management Studio installieren. Aber auch hier gibt es Abhilfe in Form des Azure Data Studio.

Azure Data Studio
https://azure.microsoft.com/de-de/updates/azure-data-studio-is-now-available/ https://docs.microsoft.com/de-de/sql/azure-data-studio/what-is?view=sql-server-2017

Laden Sie hier einfach das ZIP-Archiv auf den Server und entpacken es. Das Programm kann dann ohne Installation direkt aufgerufen und später rückstandsfrei wieder entfernt werden

Verbinden Sie sich dann mit der WID-Instanz unter der Adresse "\\.\pipe\microsoft##wid\tsql\query" und wählen Sie die passende Datenbank aus. Dann noch auf "New Query" drücken.

Starten Sie den folgenden Befehl, indem Sie den Text in das Komandofenster kopieren und "RUN" klicken

sp_addrolemember 'db_owner', 'db_genevaservice'

Danach kann die Konfiguration bezüglich Account Lockout weiter geführt werden. Die Standardeinstellungen bei Windows 2016 weichen von Windows 2012 ab.

ExtranetLockoutThreshold                   : 15
ExtranetLockoutMode                        : ADPasswordCounter

Die „Lockout“-Funktion ist schon per Default aktiv, aber mit 15 Versuchen recht hoch angesetzt. Bei einer Neuinstallation können Sie direkt Smart Lockout aktivieren. Wenn Sie aber gerade erst migrieren, dann ist es sinnvoller mit einer "Logging Only"-Konfiguration zu starten

# Smart Lockout mit "Logging Only" aktivieren
Set-AdfsProperties 
   -EnableExtranetLockout $true `
   -ExtranetLockoutThreshold 5 `
   -ExtranetObservationWindow (new-timespan -Minutes 30) `
   -ExtranetLockoutRequirePDC $false `
   -ExtranetLockoutMode AdfsSmartlockoutLogOnly
Restart-Service adfssrv

Im ADFS Eventlog sehen Sie dann, welche Benutzer vielleicht geblockt würden. Das geht auch Pro User über den bekannten Befehl

Get-ADFSAccountActivity <upn>

Wenn Sie dann sicher sind, dass alles wie erwartet erkannte wird, dann können Sie die Policy auch scharf stellen:

# Smart Lockout aktiv machen
Set-AdfsProperties `
   -EnableExtranetLockout $true `
   -ExtranetLockoutThreshold 5 `
   -ExtranetObservationWindow (new-timespan -Minutes 30) `
   -ExtranetLockoutRequirePDC $false `
   -ExtranetLockoutMode AdfsSmartLockoutEnforce
Restart-Service adfssrv

Weitere Links