Extranetsperre und intelligente Extranetsperre in AD FS – Übersicht

Die intelligente Extranetsperre (Extranet Smart Lockout, ESL) schützt Ihre Benutzer davor, dass ihr Extranetkonto durch schädliche Aktivitäten gesperrt wird.

ESL versetzt AD FS in die Lage, zwischen Anmeldeversuchen von einem vertrauenswürdigen Standort eines Benutzers bzw. einer Benutzerin und Anmeldeversuchen von einem möglichen Angreifer zu unterscheiden. AD FS kann Angreifer aussperren, während gültige Benutzer ihre Konten weiterhin nutzen können. Dies verhindert und schützt vor Denial-of-Service-Angriffen und bestimmten Arten von Kennwort-Spray-Angriffen auf Benutzer*innen. ESL ist für AD FS in Windows Server 2016 verfügbar und in AD FS in Windows Server 2019 integriert.

ESL ist nur für Authentifizierungsanforderungen in Verbindung mit Benutzernamen und Kennwörtern verfügbar, die über das Extranet per Webanwendungsproxy oder Drittanbieterproxy eingehen. Jeder Drittanbieterproxy muss das MS-ADFSPIP-Protokoll unterstützen, das anstelle des Webanwendungsproxys verwendet werden soll, z. B. F5 BIG-IP Access Policy Manager. Lesen Sie die Dokumentation zum Drittanbieterproxy, um festzustellen, ob der Proxy das MS-ADFSPIP-Protokoll unterstützt.

Features in AD FS 2019

Die intelligente Extranetsperre in AD FS 2019 bietet gegenüber AD FS 2016 folgende Vorteile:

• Unabhängige Sperrschwellenwerte für vertrauenswürdige und unbekannte Standorte Benutzer*innen an bekannten, als sicher geltenden Standorten haben mehr Spielraum für Fehler als Anforderungen, die von verdächtigen Standorten eingehen.
• Überwachungsmodus für intelligente Sperren, während Sie weiterhin das frühere Verhalten der weichen Sperrung erzwingen. Durch diese Unterscheidung erfahren Sie mehr über die vertrauenswürdigen Standorte der Benutzer*innen und sind trotzdem durch die Extranetsperrfunktion in AD FS 2012 R2 geschützt.

Konfigurationsinformationen

Wenn ESL aktiviert ist, wird in der Artefaktdatenbank eine neue Tabelle (AdfsArtifactStore.AccountActivity) erstellt. In der AD FS-Farm wird außerdem ein Knoten als primärer Knoten für „Benutzeraktivität“ ausgewählt. In einer WID-Konfiguration (Windows Internal Database, interne Windows-Datenbank) ist dieser Knoten immer der primäre Knoten. In einer SQL-Konfiguration wird ein Knoten als primärer Benutzeraktivitätsknoten ausgewählt.

Verwenden Sie (Get-AdfsFarmInformation).FarmRoles, um den als primären Benutzeraktivitätsknoten ausgewählten Knoten anzuzeigen.

Alle sekundären Knoten kontaktieren den primären Knoten bei jeder neuen Anmeldung über Port 80, um den neuesten Wert für die Anzahl fehlerhafter Kennwörter und für neue vertrauenswürdige Standorte zu ermitteln. Sekundäre Knoten aktualisieren außerdem den primären Knoten, nachdem die Anmeldung verarbeitet wurde.

Wenn der sekundäre Knoten den primären Knoten nicht kontaktieren kann, schreibt der sekundäre Knoten Fehlerereignisse in das AD FS-Administratorprotokoll. Authentifizierungen werden weiterhin verarbeitet, allerdings wird nur der aktualisierte Status lokal von AD FS aufgezeichnet. AD FS versucht alle 10 Minuten erneut, den primären Knoten zu kontaktieren. AD FS wechselt zurück zum primären Knoten, sobald der primäre Knoten verfügbar ist.

Begriff

• FamiliarLocation: Während einer Authentifizierungsanforderung überprüft ESL alle angegebenen IP-Adressen (Internet Protocol, Internetprotokoll). Bei diesen IP-Adressen handelt es sich um eine Kombination aus Netzwerk-IP-Adresse, weitergeleiteter IP-Adresse und optionaler „x-forwarded-for“-IP-Adresse. Wenn die Anforderung erfolgreich ist, werden alle IP-Adressen der Kontoaktivitätstabelle als „vertrauenswürdige IP-Adressen“ hinzugefügt. Wenn die Anforderung über alle IP-Adressen verfügt, die in den „vertrauenswürdigen IP-Adressen“ enthalten sind, wird sie als Anforderung von einem „vertrauenswürdigen Standort“ behandelt.
• UnknownLocation: Wenn bei einer eingehenden Anforderung mindestens eine IP-Adresse nicht in der bestehenden Liste FamiliarLocation enthalten ist, wird sie als Anforderung von einem „unbekannten“ Standort behandelt. Mit dieser Aktion können Proxyszenarien wie die Exchange Online-Legacy-Authentifizierung behandelt werden, bei der sowohl erfolgreiche als auch fehlerhafte Anforderungen mit Exchange Online-Adressen verarbeitet werden.
• badPwdCount: Ein Wert für die Häufigkeit, mit der ein falsches Kennwort übermittelt wurde und die Authentifizierung nicht erfolgreich war. Bei jedem*r Benutzer*in werden die Anforderungen von vertrauenswürdigen und unbekannten Standorten separat gezählt.
• UnknownLockout: Ein boolescher Wert pro Benutzer, wenn der Benutzerzugriff von unbekannten Standorten gesperrt ist. Dieser Wert wird basierend auf den Werten badPwdCountUnfamiliar und ExtranetLockoutThreshold berechnet.
• ExtranetLockoutThreshold: Dieser Wert bestimmt die maximale Anzahl fehlerhafter Kennworteingaben. Wenn der Schwellenwert erreicht ist, lehnt AD FS Anforderungen aus dem Extranet ab, bis das Beobachtungsfenster abgelaufen ist.
• ExtranetObservationWindow: Dieser Wert bestimmt, wie lange Anforderungen mit Benutzername und Kennwort von unbekannten Standorten gesperrt werden. Nach Ablauf des Zeitfensters beginnt AD FS wieder mit der Authentifizierung von Anforderungen mit Benutzername und Kennwort, die von unbekannten Standorten eingehen.
• ExtranetLockoutRequirePDC: Wenn dieser Wert aktiviert ist, erfordert die Extranetsperre einen primären Domänencontroller (PDC). Wenn er deaktiviert ist, führt die Extranetsperrfunktion ein Fallback auf einen anderen Domänencontroller aus, falls der PDC nicht verfügbar ist.
• ExtranetLockoutMode: Legt fest, ob der Modus Nur protokollieren oder der Modus Erzwingen der ELS verwendet wird.
  • ADFSSmartLockoutLogOnly: ESL ist aktiviert. AD FS schreibt Administrator- und Überwachungsereignisse, lehnt jedoch keine Authentifizierungsanforderungen ab. Dieser Modus sollte aktiviert werden, damit FamiliarLocation aufgefüllt wird, bevor ADFSSmartLockoutEnforce aktiviert wird.
  • ADFSSmartLockoutEnforce: Authentifizierungsanforderungen von unbekannten Standorten werden vollständig blockiert, wenn die Schwellenwerte erreicht werden.

IPv4- und IPv6-Adressen werden unterstützt.

Aufbau einer Transaktion

• Überprüfung vor der Authentifizierung: Während einer Authentifizierungsanforderung überprüft ESL alle angegebenen IP-Adressen. Bei diesen IP-Adressen handelt es sich um eine Kombination aus Netzwerk-IP-Adresse, weitergeleiteter IP-Adresse und optionaler „x-forwarded-for“-IP-Adresse. In den Überwachungsprotokollen werden diese IP-Adressen im <IpAddress>-Feld in folgender Reihenfolge aufgelistet: x-ms-forwarded-client-ip, x-forwarded-for, x-ms-proxy-client-ip.

  Anhand dieser IP-Adressen ermittelt AD FS, ob die Anforderung von einem vertrauenswürdigen Standort stammt, und überprüft dann, ob der jeweilige badPwdCount-Wert unter dem festgelegten Schwellenwert liegt oder ob der letzte fehlerhafte Versuch länger zurückliegt als der Zeitrahmen des Beobachtungsfensters. Wenn eine dieser Bedingungen TRUE ist, lässt AD FS diese Transaktion für die weitere Verarbeitung und Überprüfung von Anmeldeinformationen zu. Wenn beide Bedingungen FALSE sind, ist das Konto bereits gesperrt, bis das Beobachtungsfenster abgelaufen ist. Nach Ablauf des Beobachtungsfensters darf der Benutzer einmal versuchen, sich zu authentifizieren. Unter Windows 2019 überprüft AD FS anhand des entsprechenden Schwellenwerts, ob die IP-Adresse einem vertrauenswürdigen Standort entspricht.

• Erfolgreiche Anmeldung: Wenn die Anmeldung erfolgreich ist, werden die IP-Adressen aus der Anforderung der Liste der IP-Adressen für vertrauenswürdige Standorte des Benutzers bzw. der Benutzerin hinzugefügt.

• Fehlerhafte Anmeldung: Wenn bei der Anmeldung ein Fehler auftritt, wird der badPwdCount-Wert erhöht. Der Benutzer bzw. die Benutzerin wird gesperrt, wenn der*die Angreifer*in mehr fehlerhafte Kennwörter an das System übermittelt, als der Schwellenwert zulässt. (badPwdCount > ExtranetLockoutThreshold)

Der UnknownLockout-Wert ist True, wenn das Konto gesperrt ist. Diese Sperre bedeutet, dass der badPwdCount-Wert des Benutzers bzw. der Benutzerin den Schwellenwert überschreitet. Beispielsweise hat jemand versucht, mehr Kennwörter einzugeben, als das System zulässt. Hier hat ein zulässiger Benutzer bzw. eine zulässigen Benutzerin zwei Möglichkeiten, sich anzumelden:

• Er bzw. sie muss warten, bis die ObservationWindow-Dauer abgelaufen ist.
• Um den Sperrstatus zurückzusetzen, setzen Sie den badPwdCount-Wert mit Reset-ADFSAccountLockout auf 0 (null) zurück.

Wenn keine Werte zurückgesetzt werden, wird dem Konto für jedes Beobachtungsfenster eine einzelne Kennworteingabe für AD gewährt. Nach diesem Versuch wird das Konto wieder gesperrt und das Beobachtungsfenster neu gestartet. Der badPwdCount-Wert wird erst automatisch zurückgesetzt, nachdem eine Anmeldung mit einem gültigen Kennwort erfolgreich war.

Modus „Nur protokollieren“ oder Modus „Erzwingen“

Die AccountActivity-Tabelle wird sowohl im Modus Nur protokollieren als auch im Modus Erzwingen aufgefüllt. Wenn der Modus Nur protokollieren umgangen wird und ESL ohne die empfohlene Wartezeit direkt in den Modus Erzwingen wechselt, sind die vertrauenswürdigen IP-Adressen der Benutzer in AD FS nicht bekannt. In diesem Fall würde sich ESL wie ADBadPasswordCounter“ erhalten und möglicherweise den legitimen Benutzerverkehr blockieren, wenn das Benutzerkonto einem aktiven Brute-Force-Angriff ausgesetzt ist. Wenn der Modus Nur protokollieren umgangen wird und der*die Benutzer*in aufgrund von UnknownLockout = True gesperrt ist und versucht, sich mit einem geeigneten Kennwort über eine IP-Adresse anzumelden, die nicht in der Liste „vertrauenswürdiger IP-Adressen“ enthalten ist, kann er bzw. sie sich nicht anmelden. Um dieses Szenario zu vermeiden, wird der Modus Nur protokollieren für 3–7 Tage empfohlen. Wenn Konten aktiv angegriffen werden, muss der Modus Nur protokollieren mindestens 24 Stunden aufrechterhalten werden, um zu verhindern, dass legitime Benutzer*innen gesperrt werden.

Konfiguration der intelligenten Extranetsperre

In den folgenden Abschnitten werden die Voraussetzungen und Konfigurationen zum Aktivieren von ESL für AD FS 2016 beschrieben.

Voraussetzungen für AD FS 2016

1. Installieren Sie Updates auf allen Knoten in der Farm.

   Stellen Sie zunächst sicher, dass alle Windows Server 2016-AD FS-Server auf dem Stand der Windows-Updates vom Juni 2018 sind und dass die AD FS 2016-Farm auf der Ebene von 2016-Farmen ausgeführt wird.

2. Überprüfen Sie die Berechtigungen.

   ELS erfordert, dass die Windows-Remoteverwaltung auf jedem AD FS-Server aktiviert ist.

3. Aktualisieren Sie die Berechtigungen der Artefaktdatenbank.

   ELS erfordert, dass das AD FS-Dienstkonto über Berechtigungen zum Erstellen einer neuen Tabelle in der AD FS-Artefaktdatenbank verfügt. Melden Sie sich bei einem beliebigen AD FS-Server als AD FS-Administrator*in an. Erteilen Sie dann diese Berechtigung in einem PowerShell-Eingabeaufforderungsfenster, indem Sie die folgenden Befehle ausführen:

   PS C:\>$cred = Get-Credential
   PS C:\>Update-AdfsArtifactDatabasePermission -Credential $cred
   

   Hinweis

   Der $cred-Platzhalter steht für ein Konto mit AD FS-Administratorberechtigungen. Dadurch sollten Sie eine Schreibberechtigung zum Erstellen der Tabelle erhalten.

   Die oben genannten Befehle können aufgrund unzureichender Berechtigungen fehlschlagen, da Ihre AD FS-Farm SQL Server verwendet und die oben angegebenen Anmeldeinformationen keine Administratorberechtigung für SQL Server aufweisen. In diesem Fall können Sie Datenbankberechtigungen in SQL Server-Datenbank manuell konfigurieren, indem Sie den folgenden Befehl ausführen, während Sie mit der AdfsArtifactStore-Datenbank verbunden sind.

   # when prompted with “Are you sure you want to perform this action?”, enter Y.
   
   [CmdletBinding(SupportsShouldProcess=$true,ConfirmImpact = 'High')]
   Param()
   
   $fileLocation = "$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config"
   
   if (-not [System.IO.File]::Exists($fileLocation))
   {
   write-error "Unable to open AD FS configuration file."
   return
   }
   
   $doc = new-object Xml
   $doc.Load($fileLocation)
   $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
   $connString = $connString -replace "Initial Catalog=AdfsConfigurationV[0-9]*", "Initial Catalog=AdfsArtifactStore"
   
   if ($PSCmdlet.ShouldProcess($connString, "Executing SQL command sp_addrolemember 'db_owner', 'db_genevaservice' "))
   {
   $cli = new-object System.Data.SqlClient.SqlConnection
   $cli.ConnectionString = $connString
   $cli.Open()
   
   try
   {
   
   $cmd = new-object System.Data.SqlClient.SqlCommand
   $cmd.CommandText = "sp_addrolemember 'db_owner', 'db_genevaservice'"
   $cmd.Connection = $cli
   $rowsAffected = $cmd.ExecuteNonQuery()
   if ( -1 -eq $rowsAffected )
   {
   write-host "Success"
   }
   }
   finally
   {
   $cli.CLose()
   }
   }
   

Sicherstellen, dass AD FS-Sicherheitsüberwachungsprotokolle aktiviert sind

Dieses Feature nutzt Sicherheitsüberwachungsprotokolle. Daher müssen in AD FS die Überwachung und auf allen AD FS-Servern die lokale Richtlinie aktiviert werden.

Konfigurationsanweisungen

ELS verwendet die AD FS-Eigenschaft ExtranetLockoutEnabled. Diese Eigenschaft wurde zuvor verwendet, um die weiche Extranetsperre in Server 2012 R2 zu steuern. Wenn ESL aktiviert ist und Sie die aktuelle Eigenschaftskonfiguration anzeigen möchten, führen Sie Get-AdfsProperties aus.

Konfigurationsempfehlungen

Befolgen Sie beim Konfigurieren der ELS die bewährten Methoden zum Festlegen von Schwellenwerten:

ExtranetObservationWindow (new-timespan -Minutes 30)

ExtranetLockoutThreshold: Half of AD Threshold Value

AD value: 20, ExtranetLockoutThreshold: 10

Die Active Directory-Sperre funktioniert unabhängig von ELS. Wenn die Active Directory-Sperre jedoch aktiviert ist, wählen Sie ExtranetLockoutThreshold in AD FS und Schwellenwert für Kontosperre in AD aus.

ExtranetLockoutRequirePDC - $false

Falls aktiviert, erfordert die Extranetsperre einen primären Domänencontroller (PDC). Falls deaktiviert und mit „false“ konfiguriert, weicht die Extranetsperrfunktion auf einen anderen Domänencontroller aus, falls der PDC nicht verfügbar ist.

Um diese Eigenschaft festzulegen, führen Sie Folgendes aus:

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (New-TimeSpan -Minutes 30) -ExtranetLockoutRequirePDC $false

Aktivieren des Modus „Nur protokollieren“

Im Modus Nur protokollieren füllt AD FS Informationen zu vertrauenswürdigen Standorten von Benutzer*innen auf und zeichnet Sicherheitsüberwachungsereignisse auf, sperrt aber keine Anforderungen. Dieser Modus wird verwendet, um zu überprüfen, ob die intelligente Sperre ausgeführt wird, und um AD FS die Möglichkeit zu geben, vertrauenswürdige Standorte von Benutzer*innen „kennenzulernen“, bevor der Modus Erzwingen aktiviert wird. Während dieser „Kennenlernphase“ speichert AD FS die Anmeldeaktivitäten pro Benutzer (sowohl im Modus Nur protokollieren als auch im Modus Erzwingen). Legen Sie das Sperrverhalten auf Nur protokollieren fest, indem Sie das folgende Cmdlet ausführen:

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly

Der Modus Nur protokollieren ist als vorübergehender Zustand gedacht, damit das System das Anmeldeverhalten erlernen kann, bevor die Sperrung mit der intelligenten Sperre erzwungen wird. Die empfohlene Dauer für den Modus Nur protokollieren beträgt 3–7 Tage. Wenn Konten aktiv angegriffen werden, muss der Modus Nur protokollieren mindestens 24 Stunden ausgeführt werden.

Wenn in AD FS 2016 die weiche Extranetsperre von 2012 R2 aktiviert ist, bevor die intelligente Extranetsperre aktiviert wird, wird die weiche Extranetsperre durch den Modus Nur protokollieren deaktiviert. Im Modus Nur protokollieren werden Benutzer*innen durch die intelligente AD FS-Sperre nicht gesperrt. Allerdings können Benutzer*innen in der lokalen AD-Instanz durch die AD-Konfiguration gesperrt werden. In den AD-Sperrungsrichtlinien erfahren Sie, wie Benutzer*innen in einer lokalen AD-Instanz gesperrt werden können.

AD FS 2019 bietet den zusätzlichen Vorteil, dass der Modus Nur protokollieren für die intelligente Sperre aktiviert werden kann, während weiterhin das frühere Verhalten der weichen Sperre mithilfe des folgenden PowerShell-Befehls erzwungen werden kann:

Set-AdfsProperties -ExtranetLockoutMode 3

Damit der neue Modus wirksam wird, starten Sie den AD FS-Dienst auf allen Knoten in der Farm wie folgt neu:

Restart-service adfssrv

Sobald der Modus konfiguriert ist, können Sie die intelligente Sperre mithilfe des EnableExtranetLockout-Parameters aktivieren:

Set-AdfsProperties -EnableExtranetLockout $true

Aktivieren des Modus „Erzwingen“

Wenn Sie mit dem Sperrschwellenwert und dem Beobachtungsfenster zurechtkommen, kann ESL mit dem folgenden PSH-Cmdlet in den Modus Erzwingen versetzt werden:

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce

Damit der neue Modus wirksam wird, starten Sie den AD FS-Dienst auf allen Knoten in der Farm mit dem folgenden Befehl neu.

Restart-service adfssrv

Verwalten von Benutzerkontoaktivitäten

AD FS bietet drei Cmdlets zum Verwalten von Kontoaktivitätsdaten. Diese Cmdlets stellen automatisch eine Verbindung mit dem Knoten in der Farm her, der über die primäre Rolle verfügt.

Hinweis

Mithilfe von Just Enough Administration (JEA) können Sie AD FS-Cmdlets zum Zurücksetzen von Kontosperren delegieren. Beispielsweise können Sie Berechtigungen für die Verwendung von ESL-Cmdlets an Helpdeskmitarbeiter*innen delegieren. Weitere Informationen finden Sie unter Delegieren des AD FS-PowerShell-Cmdlet-Zugriffs an Benutzer*innen ohne Administratorrechte.

Sie können dieses Verhalten überschreiben, indem Sie den Parameter -Server übergeben.

Get-ADFSAccountActivity -UserPrincipalName

Das Cmdlet stellt über den AccountActivity-REST-Endpunkt automatisch eine Verbindung mit dem primären Knoten her. Daher sollten alle Daten immer konsistent sein. Ermitteln Sie mithilfe des folgenden Befehls die aktuelle Kontoaktivität für ein Benutzerkonto:

Get-ADFSAccountActivity user@contoso.com

Eigenschaften:

• BadPwdCountFamiliar: Wird erhöht, wenn eine Authentifizierung von einem bekannten Standort nicht erfolgreich ist.
• BadPwdCountUnknown: Wird erhöht, wenn eine Authentifizierung von einem unbekannten Standort nicht erfolgreich ist.
• LastFailedAuthFamiliar: Wenn die Authentifizierung von einem vertrauenswürdigen Standort nicht erfolgreich war, wird LastFailedAuthFamiliar auf den Zeitpunkt der nicht erfolgreichen Authentifizierung festgelegt.
• LastFailedAuthUnknown: Wenn die Authentifizierung von einem unbekannten Standort nicht erfolgreich war, wird LastFailedAuthUnknown auf den Zeitpunkt der nicht erfolgreichen Authentifizierung festgelegt.
• FamiliarLockout: Boolescher Wert, der True lautet, wenn BadPwdCountFamiliar>ExtranetLockoutThreshold ist.
• UnknownLockout: Boolescher Wert, der True lautet, wenn BadPwdCountUnknown>ExtranetLockoutThreshold ist.
• FamiliarIPs: Maximal 20 IP-Adressen, die dem Benutzer bzw. der Benutzerin vertraut sind. Wenn 20 IP-Adressen überschritten werden, wird die älteste IP-Adresse in der Liste entfernt.

Set-ADFSAccountActivity

Set-ADFSAccountActivity fügt neue vertrauenswürdige Speicherorte hinzu. Die Liste vertrauenswürdiger IP-Adressen enthält maximal 20 Einträge. Wenn 20 Einträge überschritten werden, wird die älteste IP-Adresse in der Liste entfernt.

Set-ADFSAccountActivity user@contoso.com -AdditionalFamiliarIps “1.2.3.4”

Reset-ADFSAccountLockout

Setzt den Sperrungszähler für ein Benutzerkonto für jeden vertrauenswürdigen Standort (badPwdCountFamiliar) oder für jeden nicht vertrauenswürdigen Standort (badPwdCountUnfamiliar) zurück. Durch das Zurücksetzen eines Zählers wird der FamiliarLockout- oder UnfamiliarLockout-Wert aktualisiert, da der Zurücksetzungszähler unter dem Schwellenwert liegt.

Reset-ADFSAccountLockout user@contoso.com -Location Familiar

Reset-ADFSAccountLockout user@contoso.com -Location Unknown

Ereignisprotokollierung und Informationen zu Benutzeraktivitäten für AD FS Extranetsperren

In den folgenden Abschnitten wird beschrieben, wie Ereignisprotokollierung, Benutzerkontoaktivität und Sperrungen überwacht werden.

Connect Health

Zur Überwachung von Benutzerkontoaktivitäten wird Connect Health empfohlen. Connect Health generiert herunterladbare Berichte zu riskanten IP-Adressen und fehlerhaften Kennworteingaben. Jeder Eintrag im Bericht zu riskanten IP-Adressen enthält aggregierte Informationen zu fehlgeschlagenen AD FS-Anmeldeaktivitäten, für die der angegebene Schwellenwert überschritten wurde. Mithilfe anpassbarer E-Mail-Einstellungen können E-Mail-Benachrichtigungen konfiguriert werden, mit denen Administrator*innen benachrichtigt werden, wenn nicht erfolgreiche AD FS-Anmeldeaktivitäten auftreten. Weitere Informationen und Einrichtungsanweisungen finden Sie unter Überwachen von AD FS mithilfe von Microsoft Entra Connect Health.

Ereignisse für intelligente Extranetsperren in AD FS

Hinweis

Informationen zur Problembehandlung bei ESL finden Sie unter Mitigating password spray attacks and account lockouts (Minimieren von Kennwort-Spray-Angriffen und Kontosperren).

Damit Ereignisse für intelligente Extranetsperren geschrieben werden können, muss ESL im Modus Nur protokollieren oder Erzwingen aktiviert sein. Gleichzeitig muss die AD FS-Sicherheitsüberwachung aktiviert sein. AD FS schreibt Extranetsperrereignisse in den folgenden Fällen in das Sicherheitsüberwachungsprotokoll:

• Ein*e Benutzer*in ist gesperrt. Das bedeutet, dass der*die Benutzer*in den Sperrschwellenwert für fehlgeschlagene Anmeldeversuche erreicht.
• AD FS registriert einen Anmeldeversuch von einem*r Benutzer*in, der bzw. die bereits gesperrt ist.

Im Modus Nur protokollieren können Sie das Sicherheitsüberwachungsprotokoll auf Sperrereignisse überprüfen. Falls Ereignisse gefunden werden, können Sie den Benutzerstatus mithilfe Cmdlets Get-ADFSAccountActivity überprüfen, um festzustellen, ob die Sperre durch eine vertrauenswürdige oder nicht vertrauenswürdige IP-Adresse verursacht wurde. Mit dem Cmdlet Get-ADFSAccountActivity können Sie zudem die Liste der vertrauenswürdigen IP-Adressen dieses Benutzers bzw. dieser Benutzerin überprüfen.

Ereignis-ID	BESCHREIBUNG
1203	Dieses Ereignis wird für jede versuchte Eingabe eines ungültigen Kennworts geschrieben. Sobald badPwdCount den in ExtranetLockoutThreshold angegebenen Wert erreicht, wird das Konto für die in ExtranetObservationWindow angegebene Dauer in AD FS gesperrt. Aktivitäts-ID: %1 XML: %2
1210	Dieses Ereignis wird jedes Mal geschrieben, wenn ein Benutzer gesperrt wird. Aktivitäts-ID: %1 XML: %2
557 (AD FS 2019)	Beim Versuch, mit dem Kontospeicher-REST-Dienst auf Knoten %1 zu kommunizieren, ist ein Fehler aufgetreten. Wenn Sie eine WID-Farm verwenden, ist der primäre Knoten möglicherweise offline. Wenn Sie eine SQL-Farm verwenden, wählt AD FS automatisch einen neuen Knoten zum Hosten der primären Rolle des Benutzerspeichers aus.
562 (AD FS 2019)	Bei der Kommunikation mit dem Kontospeicher-Endpunkt auf Server %1 ist ein Fehler aufgetreten. Ausnahmemeldung: %2
563 (AD FS 2019)	Beim Berechnen des Extranetsperrstatus ist ein Fehler aufgetreten. Aufgrund des Werts der %1-Einstellung ist die Authentifizierung für diese*n Benutzer*in zulässig, und die Tokenausstellung wird fortgesetzt. Wenn Sie eine WID-Farm verwenden, ist der primäre Knoten möglicherweise offline. Wenn Sie eine SQL-Farm verwenden, wählt AD FS automatisch einen neuen Knoten zum Hosten der primären Rolle des Benutzerspeichers aus. Kontospeicher-Servername: %2 Benutzer-ID: %3 Ausnahmemeldung: %4
512	Das Konto für den folgenden Benutzer bzw. die folgende Benutzerin ist gesperrt. Aufgrund der Systemkonfiguration ist ein Anmeldeversuch zulässig. Aktivitäts-ID: %1 Benutzer: %2 Client-IP: %3 Anzahl fehlerhafter Kennwörter: %4 Letzte fehlerhafte Kennworteingabe: %5
515	Das folgende Benutzerkonto war gesperrt, und das richtige Kennwort wurde angegeben. Dieses Konto ist möglicherweise kompromittiert. Zusätzliche Daten Aktivitäts-ID: %1 Benutzer*in: %2 Client-IP: %3
516	Das folgende Benutzerkonto wurde aufgrund zu vieler fehlerhafter Kennworteingaben gesperrt. Aktivitäts-ID: %1 Benutzer: %2 Client-IP: %3 Anzahl fehlerhafter Kennwörter: %4 Letzte fehlerhafte Kennworteingabe: %5

ESL: Häufig gestellte Fragen

Werden bei einer AD FS-Farm, für die eine intelligente Extranetsperre im Modus „Erzwingen“ verwendet wird, böswillige Benutzer*innen jemals gesperrt?

Wenn intelligente Sperren in AD FS auf den Modus Erzwingen festgelegt sind, wird das Konto des legitimen Benutzers bzw. der legitimen Benutzerin niemals gesperrt, weder bei Brute-Force- noch bei Denial-of-Service-Angriffen. Die einzige Möglichkeit, durch die die Sperrung eines kompromittierten Kontos die Benutzeranmeldung nicht verhindern kann, liegt vor, wenn der*die Angreifer*in über das Benutzerkennwort verfügt oder Anforderungen von einer bekannten (vertrauenswürdigen) IP-Adresse des Benutzers bzw. der Benutzerin senden kann.

Was geschieht, wenn ESL aktiviert ist und der*die Angreifer*in über ein Benutzerkennwort verfügt?

Mit einem Brute-Force-Angriff soll in der Regel ein Kennwort ausgespäht werden, um eine Anmeldung zu ermöglichen. Wenn ein*e Benutzer*in zum Opfer eines Phishingangriffs oder ein Kennwort ausgespäht wird, wird der Zugriff nicht durch die ESL-Funktion gesperrt, da die Anmeldung die Erfolgskriterien erfüllt, d. h. korrektes Kennwort und neue IP-Adresse. In diesem Fall würde die IP-Adresse des Angreifers bzw. der Angreiferin als vertrauenswürdige IP-Adresse interpretiert. In diesem Szenario besteht die beste Vorgehensweise darin, die Benutzeraktivitäten in AD FS zu löschen und eine Multi-Faktor-Authentifizierung für Benutzer*innen zu verlangen. Sie sollten den Microsoft Entra-Kennwortschutz installieren, um sicherzustellen, dass leicht zu erratende Kennwörter nicht in das System gelangen.

Angenommen, ein*e Benutzer*in hat sich noch nie erfolgreich über eine IP-Adresse angemeldet und gibt dann mehrmals ein falsches Kennwort ein. Kann er bzw. sie sich anmelden, sobald er sein Kennwort richtig eingegeben hat?

Wenn ein*e Benutzer*in mehrfach ein falsches Kennwort eingibt (beispielsweise durch falsche Schreibweise) und beim nächsten Versuch das richtige Kennwort eingibt, wird er bzw. sie sofort angemeldet. Dadurch wird die Zählung fehlerhafter Kennwörter gelöscht und die IP-Adresse der FamiliarIPs-Liste hinzugefügt. Wenn der*die Benutzer*in jedoch den Schwellenwert für fehlgeschlagene Anmeldeversuche vom unbekannten Standort überschreitet, wird er bzw. sie gesperrt. Er oder sie muss warten, bis das Beobachtungsfenster abläuft. Anschließend muss er bzw. sie sich mit einem gültigen Kennwort anmelden. Möglicherweise muss er bzw. sie eine*n Administrator*in bitten, das Konto zurückzusetzen.

Funktioniert ESL auch im Intranet?

Wenn die Clients direkt mit den AD FS-Servern verbunden werden und die Verbindung nicht über Webanwendungsproxyserver hergestellt wird, wird ESL nicht angewendet.

Im Feld für die Client-IP-Adressen werden Microsoft-IP-Adressen angezeigt. Kann ESL Brute-Force-Angriffe über Exchange Online blockieren?  

ESL eignet sich gut, um Brute-Force-Angriffe über Exchange Online oder andere Legacyauthentifizierungen zu verhindern. Eine Legacy-Authentifizierung verfügt über die „Aktivitäts-ID“ 00000000-0000-0000-0000-000000000000. Bei diesen Angriffen nutzt der Angreifer die Exchange Online-Standardauthentifizierung (auch Legacy-Authentifizierung genannt) aus, sodass die IP-Adresse des Clients als Microsoft-Adresse erscheint. Die Exchange Online-Server in der Cloud überprüfen die Authentifizierung im Namen des Outlook-Clients. In diesen Szenarien wird die IP-Adresse des böswilligen Absenders bzw. der böswilligen Absenderin im Wert „x-ms-forwarded-client-ip“ und die IP-Adresse des Microsoft Exchange Online-Servers im Wert „x-ms-client-ip“ angegeben. Die intelligente Extranetsperre überprüft Netzwerk-IP-Adressen, weitergeleitete IP-Adressen sowie den „x-forwarded-client-ip“- und „x-ms-client-ip“-Wert. Wenn die Anforderung erfolgreich ist, werden alle IP-Adressen der vertrauenswürdigen Liste hinzugefügt. Wenn eine Anforderung eingeht und eine der angezeigten IP-Adressen nicht in der vertrauenswürdigen Liste enthalten ist, wird die Anforderung als unbekannt markiert. Der vertrauenswürdige Benutzer bzw. die vertrauenswürdige Benutzerin kann sich erfolgreich anmelden, während Anforderungen von unbekannten Standorten gesperrt werden.

Kann ich die Größe von „ADFSArtifactStore“ vor dem Aktivieren von ESL schätzen?

Bei aktivierter ESL verfolgt AD FS die Kontoaktivität und die bekannten Speicherorte für Benutzer*innen in der ADFSArtifactStore-Datenbank nach. Die Größe dieser Datenbank wird relativ zur Anzahl der nachverfolgten Benutzer und bekannten Standorte skaliert. Beim Planen der Aktivierung von ESL können Sie die Größenzunahme für die ADFSArtifactStore-Datenbank auf eine Rate von bis zu 1 GB pro 100.000 Benutzer*innen schätzen. Wenn die AD FS-Farm die interne Windows-Datenbank (Windows Internal Database, WID) verwendet, ist der Standardspeicherort für die Datenbankdateien „C:\Windows\WID\Data“. Um das Auffüllen dieses Laufwerks zu verhindern, stellen Sie sicher, dass mindestens 5 GB freier Speicherplatz verfügbar sind, bevor Sie ESL aktivieren. Planen Sie zusätzlich zum Datenträgerspeicher, dass der gesamte Prozessspeicher nach der Aktivierung von ESL um bis zu weitere 1 GB RAM für Benutzerauffüllungen von maximal 500.000 größer wird.

Siehe auch

• Best Practices zum Sichern von Active Directory-Verbunddiensten (AD FS)
• Set-AdfsProperties
• AD FS-Vorgänge