Windows Server 2012 R2 AD FS added the Extranet Account Lockout protection feature. The intent of Extranet Account Lockout protection is to add an additional feature to password authentication which traverses Web Application Proxy (WAP). Note that the feature is not available for authentication directly targeting AD FS. The reason for this is that the Extranet Account Lockout protection was designed to help prevent external malicious account logon activities from locking out the internal AD DS account. If an external bad actor knows your logon ID, then it is trivial for them to lockout your AD DS object. All they have to do is enter invalid passwords until the account is locked out in AD.
Please see this post for more details on the initial implementation of Extranet Account Lockout protection in AD FS 2012 R2.
Consider the Extranet Account Lockout feature similar to the soft account lockout which was present in TMG. After a configured number of failures, TMG would place the account into a soft lock state and cease providing invalid credentials to AD. This prevents hammering against the AD object. While the account may be in the soft lock state on TMG, it is still active and fully functional in AD.
By enabling the feature and correctly configuring it we can help to prevent external bad actors from easily locking out AD accounts. Note that Extranet Account Lockout is NOT enabled by default – you must enable it.
Additionally, please also be aware of the Smart Lockout feature in Azure AD:
Azure AD Password Protection and Smart Lockout are now in Public Preview!
Azure Active Directory smart lockout
There’s A Fly In My Ointment
While the additional protection afforded by Extranet Account Lockout protection is very useful, it has operated in a binary fashion. When an account is locked out on WAP, it is locked to to both the valid user and any bad actors. The status of the lockout is black or white. There is no grey.
Once in the locked out state, there was no direct command to run to unlock. Nor was there an easy way to determine whom was currently in the soft lock state. It was necessary to address the locked out state indirectly.
The other issue was the hard reliance on the PDC emulator FSMO role. If that servers was unavailable for any reason, users will be denied access.
And Lo! Now for some good news!
Windows Server 2016 Update Removes The Fly
The June 2018 update for Windows Server 2016 has extended the functionality of Extranet Account Lockout protection. This updated feature is call Extranet Smart Account Lockout (ESL) protection. AD FS is now able to distinguish between valid user sign-in attempts and those from a potentially attacker which originate from unknown locations.
A database is required for AD FS to store its configuration. By default a local Windows Internal Database (WID) is used though a remote SQL instance can also be used. The June 2018 update adds the capability to store the location of where the valid authentication attempts were made. When a password based authentication is successful, AD FS stores the client’s IP address as a familiar location in the account activity table.
If password based authentication fails and the credentials do not come from a familiar location, the failed authentication count is incremented. Once the number of failed password attempts reaches the defined lockout threshold, password based authentication from unfamiliar locations is blocked for that user. There are configuration options to define the lockout threshold and the observation window.
Every time that a password based authentication is successful, AD FS saves the client’s IP as a familiar location in the database. If the password authentication fails, and the request emanates from an unfamiliar location the failed authentication count is incremented.
Note that a process and procedure must also be put in place to monitor and respond to events and alerts created.
Installation
Install at least the June 2018 Windows Updates on all AD FS servers. Note that this is the absolute minimum. It is expected that customers proactively test, plan and roll out updates.
Once all the AD FS servers have been successfully updated the configuration database can be modified. Database changes are required as ESL creates a new table to store the logon information.
Please refer to the following articles for the implementation details:
AD FS Extranet Lockout and Extranet Smart Lockout
Configuration
A new parameter was added to support ESL – ExtranetAccountLockoutMode. This contains the following options:
-
ADPasswordCounter
-
ADFSSmartLockoutLogOnly
-
ADFSSmartLockoutEnforce
ADPasswordCounter – this is the default mode. Consider this the legacy AD FS extranet account Lockout mode. This mode does NOT differentiate based on location.
ADFSSmartLockoutLogOnly – ESL mode is enabled in log only mode. AD FS will write admin and audit events, but will not reject authentication requests.
ADFSSmartLockoutEnforce - ESL is enabled, and will block authentication requests from unfamiliar locations when the configured threshold is reached.
Changing the mode requires restarting the AD FS service on all nodes in the farm. Prior to enforcing the lockout, it is recommended to monitor using ADFSSmartLockoutLogOnly so you can determine the potential impact and frequency of events.
Management
If this sounds good so far, then it is going to get better! One of the issues with the initial release of Extranet Account Lockout protection was the lack of management interface. There was no straightforward way to determine who was locked out, the recent lockout activity for a user and to reset the lockout.
Such issues are solved with the below cmdlets:
Get-ADFSAccountActivity
Set-ADFSAccountActivity
Reset-ADFSAccountActivity
The cmdlets automatically connect to the master node in the AD FS farm to help ensure data is consistent.
While the above cmdlets are able to provide details about the current status of an account, additional monitoring should also be considered. As mentioned in the release notes, AD FS will write an ExtranetLockoutAudit EventID to the security event log.
It is also worth reviewing the Azure AD Connect Health capability:
Monitor your AD FS sign-in activity using Azure AD Connect Health’s risky IP reports
Cheers,
Rhoderick
