AD FS 2016 Extranet Smart Lockout behavior

I’m sure you are familiar with the following articles discussing the Federated account lockouts and AD FS Extranet Smart Lockout (ESL) feature and set up recommendations.

https://blogs.technet.microsoft.com/tspring/2017/01/20/federated-to-microsoft-cloud-and-account-lockouts/

https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-smart-lockout-protection

https://samilamppu.com/2018/07/09/w2016-adfs-smart-lockout/

Recently was helping the customer whose environment was experiencing high volume of on-premises AD accounts lockouts due to the external bad passwords attempts via AD FS 2016 farm.

As per second article, Microsoft recommends enabling the AD FS ESL in the log only mode. It is recommended to run AD FS ESL in such mode for 5-7 days to build the list of familiar locations per user.

Since the impact of the AD lockouts was high to the customer, they decided to switch from log to enforce mode after 24 hours of enabling the ESL, but ran into following issue.

It was not enough time to build the familiar IPs list, and some users accounts still experiencing heavy bad passwords attempts were locked out on AD FS side due to empty familiar IP addresses list.

This happened because in case in the output of Get-AdfsAccountActivity PowerShell cmdlet you see the familiar IP list is empty and the UnknownLockout = True, the user will not be able to sign in with correct password until the observationWindows time elapses or ADFS admin resets the count. In such scenario AD FS ESL works in AD FS Extranet Lockout mode introduced in AD FS 3.0.

This issue was addressed in AD FS 2019 where you can enable audit mode for smart lockout while continuing to enforce the soft lockout behavior (ADPasswordCounter)

Advertisements

PowerShell script to collect AD FS 2016 bad password sign in attempts data

There is an excellent blogpost about federated to Microsoft Cloud accounts lockouts data collection, analysis and mitigation. 

The article above provides links to the scripts collecting event logs data for Windows Server 2008 R2, 2012 and 2012 R2.

But in Windows Server 2016 there were audit enhancements made in AD FS 2016 auditing to make it more streamlined and less verbose.

With this enhancement the EventIDs for Audit Failure logged in the Security logs by AD FS Auditing has changed.

Below is my version on PowerShell script to parse the Security Event log and collect information about EventID 1203 – “Fresh Credential Validation Error”.

$events = Get-WinEvent -FilterHashtable @{Logname='Security';Id=1203}
$events2 = ($events | select Message,TimeCreated -ExpandProperty Message)
$info = @()
$events2 | foreach {
    $IpStart = $_.Message.IndexOf("<IpAddress>")
    $IpEnd = $_.Message.IndexOf("</IpAddress>")
    $IpAddresses = $_.Message.Substring($IpStart+11,($IpEnd-$IpStart-11))

    $UserIdStart = $_.Message.IndexOf("<UserId>")
    $UserIdEnd = $_.Message.IndexOf("</UserId>")
    $UserId = $_.Message.Substring($UserIdStart+8,($UserIdEnd-$UserIdStart-8))

    $AuditStart = $_.Message.IndexOf("<AuditResult>")
    $AuditEnd = $_.Message.IndexOf("</AuditResult>")
    $Auditresult = $_.Message.Substring($AuditStart+13,($AuditEnd-$AuditStart-13))
    
    $FailureStart = $_.Message.IndexOf("<FailureType>")
    $FailureEnd = $_.Message.IndexOf("</FailureType>")
    $FailureType = $_.Message.Substring($FailureStart+13,($FailureEnd-$FailureStart-13))
    
    $AuthStart = $_.Message.IndexOf("<AuthProtocol>")
    $AuthEnd = $_.Message.IndexOf("</AuthProtocol>")
    $AuthProtocol = $_.Message.Substring($AuthStart+14,($AuthEnd-$AuthStart-14))
    
    $EndpointStart = $_.Message.IndexOf("<Endpoint>")
    $EndpointEnd = $_.Message.IndexOf("</Endpoint>")
    $Endpoint = $_.Message.Substring($EndpointStart+10,($EndpointEnd-$EndpointStart-10))

$Fail = New-object -TypeName PSObject
add-member -inputobject $Fail -membertype noteproperty -name "TimeStamp" -value $_.TimeCreated
add-member -inputobject $Fail -membertype noteproperty -name "IPaddress" -value $IpAddresses
add-member -inputobject $Fail -membertype noteproperty -name "User ID" -value $UserId
add-member -inputobject $Fail -membertype noteproperty -name "Audit" -value $Auditresult
add-member -inputobject $Fail -membertype noteproperty -name "FailureType" -value $FailureType
add-member -inputobject $Fail -membertype noteproperty -name "Protocol" -value $AuthProtocol
add-member -inputobject $Fail -membertype noteproperty -name "ADFS Endpoint" -value $Endpoint

$info +=$Fail
}
$info 

Also would higly recommend reading the following blogpost about best practices for defending against password spray attack using Azure AD and AD FS. Note the new Smart Lockout settings coming to AD FS 2016 in March 2018.