Dela via

Översikt över AD FS Extranet Lockout och Extranet Smart Lockout

ESL (Extranet Smart Lockout) skyddar dina användare från att drabbas av extranätskontoutelåsning från skadlig aktivitet.

ESL gör det möjligt för AD FS att skilja mellan inloggningsförsök från en välbekant plats för en användare och inloggningsförsök från vad som kan vara en angripare. AD FS kan låsa ute angripare samtidigt som giltiga användare kan fortsätta att använda sina konton. Den här skillnaden förhindrar och skyddar mot denial-of-service och vissa klasser av lösenordssprayattacker på användaren. ESL är tillgängligt för AD FS i Windows Server 2016 och är inbyggt i AD FS i Windows Server 2019.

ESL är endast tillgängligt för begäranden om användarnamn och lösenordsautentisering som kommer via extranätet med webbprogramproxyn eller en proxy från tredje part. Alla proxyservrar från tredje part måste ha stöd för MS-ADFSPIP protokoll som ska användas i stället för webbprogramproxyn, till exempel F5 BIG-IP Access Policy Manager. Läs dokumentationen om proxy från tredje part för att avgöra om proxyn stöder MS-ADFSPIP-protokollet.

Funktioner i AD FS 2019

Extranät Smart Lockout i AD FS 2019 ger följande fördelar jämfört med AD FS 2016:

  • Oberoende tröskelvärden för utelåsning för välbekanta och okända platser. Användare på kända bra platser kan ha mer utrymme för fel än begäranden från misstänkta platser.
  • Revisionsläge för smart utelåsning samtidigt som du fortsätter att tillämpa tidigare beteende för mjuk utelåsning. Med den här distinktionen kan du lära dig mer om välbekanta platser och fortfarande skyddas av extranätsutelåsningsfunktionen som är tillgänglig från AD FS 2012 R2.

Konfigurationsinformation

När ESL är aktiverat skapas en ny tabell i artefaktdatabasen AdfsArtifactStore.AccountActivity. En nod väljs också i AD FS-servergruppen som primär nod för "Användaraktivitet". I en WID-konfiguration (Windows Internal Database) är den här noden alltid den primära noden. I en SQL-konfiguration väljs en nod som primär nod för användaraktivitet.

Om du vill visa den nod som valts som den primära noden "Användaraktivitet" använder du (Get-AdfsFarmInformation).FarmRoles.

Alla sekundära noder kontaktar den primära noden vid varje ny inloggning via port 80 för att lära sig det senaste värdet för antalet felaktiga lösenord och nya välbekanta platsvärden. Sekundära noder uppdaterar också den primära noden när inloggningen har bearbetats.

diagram som visar inloggningsprocessen mellan primära noder, sekundära noder och klienten.

Om den sekundära noden inte kan kontakta den primära noden skriver den sekundära noden felhändelser i AD FS-administratörsloggen. Autentiseringar fortsätter att bearbetas, men AD FS skriver bara det uppdaterade tillståndet lokalt. AD FS försöker kontakta den primära noden var 10:e minut. AD FS växlar tillbaka till den primära noden när den primära noden är tillgänglig.

Terminologi

  • FamiliarLocation: Under en autentiseringsbegäran kontrollerar ESL alla presenterade internetprotokoll (IP-adresser). Dessa IP-adresser är en kombination av nätverks-IP, vidarebefordrad IP och den valfria x-forwarded-for IP-adressen. Om begäran lyckas läggs alla IP-adresser till i tabellen Kontoaktivitet som "välbekanta IP-adresser". Om begäran har alla IP-adresser som finns i de "välbekanta IP-adresserna" behandlas begäran som en "bekant" plats.
  • UnknownLocation: Om en begäran som kommer in har minst en IP-adress som inte finns i den befintliga FamiliarLocation-listan behandlas begäran som en "okänd" plats. Den här åtgärden hanterar proxyscenarier som äldre Exchange Online-autentisering där Exchange Online-adresser hanterar både lyckade och misslyckade begäranden.
  • badPwdCount: Ett värde som representerar antalet gånger ett felaktigt lösenord skickades och autentiseringen misslyckades. För varje användare sparas separata räknare för välbekanta platser och okända platser.
  • UnknownLockout: Ett booleskt värde per användare om användaren är utelåst från att komma åt från okända platser. Det här värdet beräknas baserat på värdena badPwdCountUnfamiliar och ExtranetLockoutThreshold.
  • ExtranetLockoutThreshold: Det här värdet avgör det maximala antalet misslyckade lösenordsförsök. När tröskelvärdet nås avvisar AD FS begäranden från extranätet tills observationsfönstret har passerat.
  • ExtranetObservationWindow: Det här värdet avgör hur länge användarnamn och lösenordsbegäranden från okända platser är utelåst. När fönstret har passerat börjar AD FS utföra autentisering med användarnamn och lösenord från okända platser igen.
  • ExtranetLockoutRequirePDC: När det är aktiverat kräver extranätsutelåsning en primär domänkontrollant (PDC). När den är inaktiverad återgår extranätsutelåsningen till en annan domänkontrollant om PDC:n inte är tillgänglig.
  • ExtranetLockoutMode: Styr läget för Loggnings- kontra Tvingat för ESL.
    • ADFSSmartLockoutLogOnly: ESL är aktiverat. AD FS skriver administratörs- och granskningshändelser men avvisar inte autentiseringsbegäranden. Det här läget är avsett att aktiveras för att FamiliarLocation ska fyllas i innan ADFSSmartLockoutEnforce är aktiverat.
    • ADFSSmartLockoutEnforce: Fullständigt stöd för att blockera okända autentiseringsbegäranden när tröskelvärden nås.

IPv4- och IPv6-adresser stöds.

En transaktions anatomi

  • förautentiseringskontroll: Under en autentiseringsbegäran kontrollerar ESL alla presenterade IP-adresser. Dessa IP-adresser är en kombination av nätverks-IP, vidarebefordrad IP och den valfria x-forwarded-for IP-adressen. I granskningsloggarna visas dessa IP-adresser i fältet <IpAddress> i ordningen x-ms-forwarded-client-ip, x-forwarded-for, x-ms-proxy-client-ip.

    Baserat på dessa IP-adresser avgör AD FS om begäran kommer från en bekant plats och kontrollerar sedan om respektive badPwdCount är mindre än den angivna tröskelvärdesgränsen eller om det senaste misslyckade försöket inträffade längre än tidsperioden för observationsfönstret. Om något av dessa villkor är sant tillåter AD FS den här transaktionen för ytterligare bearbetning och validering av autentiseringsuppgifter. Om båda villkoren är falska är kontot redan i ett låst tillstånd tills observationsfönstret passerar. När observationsfönstret har passerat tillåts användaren ett försök att autentisera. I Windows Server 2019 kontrollerar AD FS mot lämplig tröskelvärdesgräns baserat på om IP-adressen matchar en bekant plats.

  • Lyckad inloggning: Om inloggningen lyckas läggs IP-adresserna från begäran till i användarens välbekanta IP-lista för plats.

  • Misslyckad inloggning: Om inloggningen misslyckas ökar badPwdCount-. Användaren hamnar i ett utelåsningstillstånd om angriparen skickar fler felaktiga lösenord till systemet än vad tröskelvärdet tillåter. (antalFelaktigaLösenord > ExtranetLockoutGräns)

diagram som visar processen för lyckad och misslyckad autentisering.

Värdet UnknownLockout är lika med True när kontot är utelåst. Den här utelåsningen innebär att användarens badPwdCount överskrider tröskelvärdet. Till exempel försökte någon fler lösenord än systemet tillåter. I det här tillståndet finns det två sätt som en giltig användare kan logga in på:

  • Vänta tills att ObservationWindow tid har gått.
  • För att återställa låsningsläget, återställ badPwdCount till noll med Reset-ADFSAccountLockout.

Om inga återställningar sker tillåts kontot ett enda lösenordsförsök mot AD för varje observationsfönster. Efter det försöket återgår kontot till det låsta tillståndet och observationsfönstret startas om. Värdet badPwdCount återställs bara automatiskt efter en lyckad lösenordsinloggning.

Log-Only-läge jämfört med tvingande läge

Tabellen AccountActivity fylls i både i endast loggläge och framtvingat läge. Om Endast loggning-läge kringgås och ESL flyttas direkt till tvinga-läge utan den rekommenderade väntetiden, är användarnas bekanta IP-adresser inte kända för AD FS. ESL beter sig sedan som ADBadPasswordCounter, vilket potentiellt blockerar legitim användartrafik om användarkontot är under en aktiv råstyrkeattack. Om log-only--läget kringgås och användaren går in i ett låst tillstånd där UnknownLockout- är lika med True och försöker logga in med ett bra lösenord från en IP-adress som inte finns i den "välbekanta" IP-listan kan de inte logga in. Log-Only-läge rekommenderas i 3–7 dagar för att undvika det här scenariot. Om konton aktivt attackeras krävs minst 24 timmars log-only- läge för att förhindra utelåsning till legitima användare.

Smart utelåsningskonfiguration för extranät

I följande avsnitt beskrivs förutsättningarna och konfigurationerna för att aktivera ESL för AD FS 2016.

Förutsättningar för AD FS 2016

  1. Installera uppdateringar på alla noder i servergruppen.

    Kontrollera först att alla Windows Server 2016 AD FS-servrar är uppdaterade från och med Windows-uppdateringarna i juni 2018 och att AD FS 2016-servergruppen körs på 2016-servergruppens beteendenivå.

  2. Verifiera behörigheter.

    ESL kräver att Windows Fjärrhantering är aktiverat på varje AD FS-server.

  3. Uppdatera behörigheter för artefaktdatabasen.

    ESL kräver att AD FS-tjänstkontot har behörighet att skapa en ny tabell i AD FS-artefaktdatabasen. Logga in på valfri AD FS-server som AD FS-administratör. Bevilja sedan den här behörigheten i ett PowerShell-kommandotolk genom att köra följande kommandon:

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

    Anmärkning

    Platshållaren $cred är ett konto som har AD FS-administratörsbehörighet. Detta bör ge skrivbehörighet för att skapa tabellen.

    De tidigare kommandona kan misslyckas på grund av bristande behörighet eftersom AD FS-servergruppen använder SQL Server och de autentiseringsuppgifter som angavs tidigare inte har administratörsbehörighet på SQL-servern. I det här fallet kan du konfigurera databasbehörigheter manuellt i SQL Server Database när du är ansluten till AdfsArtifactStore databas genom att köra följande kommando:

    # 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()
}
}

Kontrollera att AD FS-säkerhetsgranskningsloggning är aktiverad

Den här funktionen använder säkerhetsgranskningsloggar, så granskning måste aktiveras i AD FS och den lokala principen på alla AD FS-servrar.

Konfigurationsinstruktioner

ESL använder AD FS-egenskapen ExtranetLockoutEnabled. Den här egenskapen användes tidigare för att styra Extranet Soft Lockout i Server 2012 R2. Om ESL är aktiverat och du vill visa den aktuella egenskapskonfigurationen kör du Get-AdfsProperties.

Konfigurationsrekommendationer

När du konfigurerar ESL följer du metodtipsen för att ange tröskelvärden:

ExtranetObservationWindow (new-timespan -Minutes 30)

ExtranetLockoutThreshold: Half of AD Threshold Value

AD value: 20, ExtranetLockoutThreshold: 10

Active Directory-utelåsning fungerar oberoende av ESL. Men om Active Directory-utelåsning är aktiverat väljer du ExtranetLockoutThreshold i AD FS och Tröskelvärde för kontoutelåsning i AD.

ExtranetLockoutRequirePDC - $false

När det är aktiverat kräver extranätsutelåsning en primär domänkontrollant (PDC). När det är inaktiverat och konfigurerat som falskt återgår extranätsutelåsningen till en annan domänkontrollant om PDC inte är tillgänglig.

För att ställa in den här egenskapen, kör kommandot:

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

Aktivera Log-Only läge

I log-only-läge fyller AD FS i en användares välbekanta platsinformation och skriver säkerhetsgranskningshändelser men blockerar inga begäranden. Det här läget används för att verifiera att smart utelåsning körs och för att låta AD FS "lära sig" användarnas välbekanta platser innan läget Framtvinga aktiveras. Som AD FS lär sig lagrar den inloggningsaktivitet per användare (oavsett om det är i log-only--läge eller Framtvinga läge). Ange utlåsningsbeteendet till Log-Only genom att köra följande cmdlet:

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly

Log-Only-läge är avsett att vara ett tillfälligt tillstånd så att systemet kan lära sig inloggningsbeteendet innan låsningstillämpning införs med smart låsningbeteende. Den rekommenderade varaktigheten för log-only läge är 3–7 dagar. Om konton aktivt attackeras måste log-only--läge köras i minst 24 timmar.

På AD FS 2016, om 2012 R2 Extranet Soft Lockout-beteende är aktiverat innan Extranet Smart Lockout aktiveras, inaktiverar Log-Only-läge Extranet Soft Lockout-beteendet. AD FS Smart Lockout låser inte ut användare i log-only läge. Lokal AD kan dock låsa ut användaren baserat på AD-konfigurationen. Läs AD-utelåsningsprinciper för att lära dig hur lokal AD kan låsa ut användare.

På AD FS 2019 är en annan fördel att kunna aktivera log-only läge för smart utelåsning samtidigt som du fortsätter att tillämpa det tidigare beteendet för mjuk utelåsning med hjälp av nedanstående PowerShell:

Set-AdfsProperties -ExtranetLockoutMode 3

För att det nya läget ska börja gälla startar du om AD FS-tjänsten på alla noder i servergruppen med hjälp av:

Restart-service adfssrv

När läget har konfigurerats kan du aktivera smart utelåsning med hjälp av parametern EnableExtranetLockout:

Set-AdfsProperties -EnableExtranetLockout $true

Aktivera framtvinga läge

När du är nöjd med tröskelvärdet för utelåsning och övervakningsfönstret kan ESL flyttas till Framtvinga läge med hjälp av följande PSH-cmdlet:

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce

Starta om AD FS-tjänsten på alla noder i servergruppen med hjälp av följande kommando för att det nya läget ska börja gälla.

Restart-service adfssrv

Hantera användarkontoaktivitet

AD FS innehåller tre cmdletar för att hantera kontoaktivitetsdata. Dessa cmdletar ansluter automatiskt till noden i servergruppen som innehåller den primära rollen.

Anmärkning

Du kan använda JEA (Just Enough Administration) för att delegera AD FS-kommandon för att återställa kontoutelåsningar. Du kan till exempel delegera behörigheter till supportavdelningens personal för att använda ESL-kommandon. För mer information, se Delegera AD FS Powershell-cmdlet-åtkomst till användare som inte är administratörer.

Du kan åsidosätta det här beteendet genom att skicka parametern -Server.

Get-ADFSAccountActivity -UserPrincipalName

Cmdleten ansluter automatiskt till servergruppens primära nod med hjälp av REST-slutpunkten för kontoaktivitet. Därför bör alla data alltid vara konsekventa. Läs den aktuella kontoaktiviteten för ett användarkonto med hjälp av:

Get-ADFSAccountActivity user@contoso.com

Egenskaper:

  • BadPwdCountFamiliar: Ökas när en autentisering misslyckas från en känd plats.
  • BadPwdCountUnknown: Ökas när autentisering misslyckas från en okänd plats.
  • LastFailedAuthFamiliar: Om autentiseringen misslyckades från en bekant plats är LastFailedAuthFamiliar inställd på tidpunkten för misslyckad autentisering.
  • LastFailedAuthUnknown: Om autentiseringen misslyckades från en okänd plats är LastFailedAuthUnknown inställd på tidpunkten för misslyckad autentisering.
  • FamiliarLockout: Booleskt värde som är True om BadPwdCountFamiliar>ExtranetLockoutThreshold.
  • UnknownLockout: Ett booleskt värde som är Sant om BadPwdCountUnknown>ExtranetLockoutThreshold.
  • FamiliarIPs: högst 20 IP-adresser som är bekanta för användaren. När 20 IP-adresser överskrids tas den äldsta IP-adressen i listan bort.

Set-ADFSAccountActivity

Set-ADFSAccountActivity lägger till nya välbekanta platser. Den välbekanta IP-listan har högst 20 poster. Om 20 poster överskrids tas den äldsta IP-adressen i listan bort.

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

Reset-ADFSAccountLockout

Återställer utelåsningsräknaren för ett användarkonto för varje välbekant plats (badPwdCountFamiliar) eller räknaren för en okänd plats (badPwdCountUnfamiliar). När du återställer en räknare uppdateras FamiliarLockout eller UnfamiliarLockout-värdet, eftersom reset-räknaren är mindre än tröskelvärdet.

Reset-ADFSAccountLockout user@contoso.com -Location Familiar

Reset-ADFSAccountLockout user@contoso.com -Location Unknown

Händelseloggning & användaraktivitetsinformation för AD FS-extranätsutelåsning

I följande avsnitt beskrivs hur du övervakar händelseloggning, användarkontoaktivitet och utelåsningar.

Connect Health

Det rekommenderade sättet att övervaka användarkontoaktivitet är via Connect Health. Connect Health genererar nedladdningsbar rapportering om riskfyllda IP-adresser och felaktiga lösenordsförsök. Varje objekt i den riskfyllda IP-rapporten visar aggregerad information om misslyckade AD FS-inloggningsaktiviteter som överskrider det angivna tröskelvärdet. E-postaviseringar kan ställas in för att meddela administratörer med anpassningsbara e-postinställningar när misslyckade AD FS-inloggningsaktiviteter inträffar. Mer information och installationsinstruktioner finns i Övervaka AD FS med Microsoft Entra Connect Health.

AD FS Extranet Smart Lockout-händelser

Anmärkning

Information om hur du felsöker ESL finns i Minimera lösenordssprayattacker och kontoutelåsningar.

För att Extranet Smart Lockout-händelser ska skrivas måste ESL aktiveras i Log-Only eller Framtvinga-läge, och AD FS-säkerhetsgranskningen måste vara aktiverad. AD FS skriver extranätsutelåsningshändelser till säkerhetsgranskningsloggen när:

  • En användare är utelåst, vilket innebär att användaren når tröskelvärdet för utelåsning för misslyckade inloggningsförsök.
  • AD FS tar emot ett inloggningsförsök för en användare som redan är i ett utelåsningstillstånd.

När du är i log-only--läge kan du kontrollera säkerhetsgranskningsloggen efter utelåsningshändelser. För alla händelser som hittas kan du kontrollera användartillståndet med hjälp av cmdleten Get-ADFSAccountActivity för att avgöra om utelåsningen inträffade från välbekanta eller okända IP-adresser. Du kan också använda cmdleten Get-ADFSAccountActivity för att dubbelkolla listan över välbekanta IP-adresser för användaren.

Händelse-ID Beskrivning
1203 Den här händelsen skrivs för varje felaktigt lösenordsförsök. Så snart badPwdCount når det värde som anges i ExtranetLockoutThresholdär kontot utelåst på AD FS under den tid som anges i ExtranetObservationWindow.
aktivitets-ID: %1
XML: %2
1210 Den här händelsen skrivs varje gång en användare är utelåst.
aktivitets-ID: %1
XML: %2
557 (AD FS 2019) Ett fel inträffade när man försökte kommunicera med kontolagringens REST-tjänst på nod %1. Om du använder en WID-servergrupp kan den primära noden vara offline. Om du använder en SQL-servergrupp väljer AD FS automatiskt en ny nod som värd för den primära rollen för användararkivet.
562 (AD FS 2019) Ett fel uppstod när du kommunicerade med kontolagringsslutpunkten på servern %1.
undantagsmeddelande: %2
563 (AD FS 2019) Ett fel uppstod vid beräkning av status för extranätsutelåsning. På grund av värdet för %1tillåts inställningsautentisering för den här användaren och tokenutfärdande fortsätter. Om du använder en WID-servergrupp kan den primära noden vara offline. Om du använder en SQL-servergrupp väljer AD FS automatiskt en ny nod som värd för den primära rollen för användararkivet.
kontoarkivservernamn: %2
användar-ID: %3
undantagsmeddelande: %4
512 Kontot för följande användare är utelåst. Ett inloggningsförsök tillåts på grund av systemkonfigurationen.
aktivitets-ID: %1
användare: %2
klient-IP: %3
antal felaktiga lösenord: %4
senaste misslyckade lösenordsförsöket: %5
515 Följande användarkonto var i ett låst tillstånd och rätt lösenord angavs. Det här kontot kan vara komprometterat.
Mer data
aktivitets-ID: %1
Användare: %2
Klient-IP: %3
516 Följande användarkonto har låsts ut på grund av för många felaktiga lösenordsförsök.
aktivitets-ID: %1
användare: %2
klient-IP: %3
antal felaktiga lösenord: %4
senaste misslyckade lösenordsförsöket: %5

Vanliga frågor och svar om ESL

Kommer en AD FS-servergrupp som använder Extranet Smart Lockout i framtvingat läge någonsin att se att användare obehörigen låses ute?

Om AD FS Smart Lockout är inställt på Framtvinga-läge ser du aldrig det legitima användarkontot låst ut av råstyrke- eller överbelastningsattack. Det enda sättet att låsa ett skadligt konto kan förhindra att en användare loggar in är om den felaktiga aktören har användarlösenordet eller kan skicka begäranden från en känd bra (bekant) IP-adress för den användaren.

Vad händer om ESL är aktiverat och den felaktiga aktören har en användares lösenord?

Det typiska målet med brute force-attackscenariot är att gissa ett lösenord och logga in. Om en användare är phished eller om ett lösenord gissas blockerar inte ESL-funktionen åtkomsten eftersom inloggningen uppfyller kriterierna för ett korrekt lösenord plus ny IP-adress. IP-adressen för illvilliga aktörer skulle då framstå som en känd. Den bästa lösningen i det här scenariot är att rensa användarens aktivitet i AD FS och kräva multifaktorautentisering för användarna. Du bör installera Microsoft Entra Password Protection för att säkerställa att gissningsbara lösenord inte kommer in i systemet.

Om min användare aldrig har loggat in från en IP-adress och sedan försöker med ett felaktigt lösenord några gånger, kommer de att kunna logga in när de äntligen skriver sitt lösenord korrekt?

Om en användare skickar flera felaktiga lösenord (till exempel genom att skriva fel) och vid följande försök får lösenordet korrekt loggar användaren omedelbart in. Den här lyckade inloggningen rensar antalet felaktiga lösenord och lägger till ip-adressen i listan FamiliarIPs. Men om de överskrider tröskelvärdet för misslyckade inloggningar från den okända platsen går de in i utelåsningstillstånd. De måste sedan vänta förbi observationsfönstret och logga in med ett giltigt lösenord. De kan kräva administratörsintervention för att återställa sitt konto.

Fungerar ESL på intranätet också?

Om klienterna ansluter direkt till AD FS-servrarna och inte via webbprogramproxyservrar gäller inte ESL-beteendet.

Jag ser Microsoft IP-adresser i fältet Klient-IP. Blockerar ESL EXO proxifiede brute force-attacker?  

ESL fungerar bra för att förhindra Exchange Online eller andra brutala attacker med gammal autentisering. En äldre autentisering har ett aktivitets-ID på 00000000-0000-0000-0000-0000000000000. I dessa attacker utnyttjar den dåliga aktören grundläggande Exchange Online-autentisering (även kallat äldre autentisering) så att klientens IP-adress visas som en Microsoft-adress. Exchange Online-servrarna i molnet hanterar autentiseringsverifieringen för Outlook-klientens räkning. I dessa scenarier finns IP-adressen för den skadliga inskickare i x-ms-forwarded-client-ip och Microsoft Exchange Online-serverns IP-adress finns i värdet x-ms-client-ip. Extranet Smart Lockout-funktionen kontrollerar nätverks-IP-adresser, vidarebefordrade IP-adresser, x-forwarded-client-IP och värdet x-ms-client-ip. Om begäran lyckas läggs alla IP-adresser till i den välbekanta listan. Om en begäran kommer in och någon av de presenterade IP-adresserna inte finns i den välbekanta listan markeras begäran som obekant. Den välbekanta användaren kan logga in framgångsrikt medan begäranden från okända platser blockeras.

Kan jag uppskatta storleken på ADFSArtifactStore innan jag aktiverar ESL?

När ESL är aktiverat spårar AD FS kontoaktiviteten och kända platser för användare i ADFSArtifactStore-databasen. Den här databasen skalas i storlek i förhållande till antalet användare och kända platser som spåras. När du planerar att aktivera ESL kan du uppskatta storleken på ADFSArtifactStore- databas att växa med en hastighet på upp till 1 GB per 100 000 användare. Om AD FS-servergruppen använder Den interna Windows-databasen (WID) är standardplatsen för databasfilerna C:\Windows\WID\Data. Se till att du har minst 5 GB ledigt lagringsutrymme innan du aktiverar ESL för att förhindra att enheten fylls i. Utöver disklagring planerar du att det totala processminnet ska växa efter att du har aktiverat ESL med upp till 1 GB RAM-minne för en användarpopulation på 500 000 eller mindre.

Se även