In Windows Server 2012 R2 there was already a Extranet lockout version available but this was based on a bad password count an relied on your AD PDC server to function. With update of March 2018 for Windows Server 2016 an feature has been added to the AD FS (Active Directory Federation Services) server named: Extranet Smart Lockout (ESL). This feature enable AD FS to differentiate between sign-in attempts from a valid user and sign-ins from what may be an attacker. This means AD FS can lockout attackers whilst still allowing your users to sign-in with their account. This feature better protects users against denial of service and targeted attacks.
To start using this new feature you have to ensure that all your Windows Server 2016 AD FS servers are up to date (at minimum the updates from March 2018 but hopefully your servers are fully up to date).
Prepare the database
The ESL requires your AD FS Service account to have permissions to create a new table in the AD FS artifact database. Run the following cmdlet to grant this permission, you should provide the credential of your AD FS service account which should have administrator rights:
|
1 2 |
$Credential= Get-Credential Update-AdfsArtifactDatabasePermission -Credential $Credential |
In case you get an PS0159 error message check out this post: PS0159 the operation is not supported at the current farm behavior level 1 raise the farm to at least version 2 before retrying
If your AD FS farm is using an SQL Server then the above command might fail due to a loack of permissions on your SQL Server. You can configure the database permission manually by running the following command whist connected to the AdfsArtifactStore database:
|
1 |
ALTER AUTHORIZATION ON SCHEMA::[ArtifactStore] TO [db_genevaservice] |
Enable Extranet Smart Lockout
The ExtranetLocketMode now has three parameters which you can use, these are:
- ADPasswordCounter – This is the legacy AD FS “extranet soft lockout” mode, which does not differentiate based on location. This is the default value.
- ADFSSmartLockoutLogOnly – This is Extranet Smart Lockout. Instead of rejecting authentication requests, AD FS writes admin and audit events.
- ADFSSmartLockoutEnforce – This is Extranet Smart Lockout with full support for blocking unfamiliar requests when thresholds are reached.
The first option ADPasswordCounter is the default option which was also available in the Windows Server 2012 R2 version.
I would recommend to start with the LogOnly option and monitor this for a short period before enforcing the new setting. Run the following cmdlet to enable the Smart lockout mode in log-only mode, enabling this feature does require a restart of the AD FS service.
|
1 2 3 4 5 |
# Enable ESL log only Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly # Restart the AD FS Service Restart-service adfssrv |
Configure ESL Options
There are two options you can configure with ESL these are the Lockout threshold and the observation window.
- Lockout Threshold setting
When an authentication is successful the AD FS stores the (client) IP number from where the authentication took place as a familiar location in the account activity table. When an authentication attempt fails and the source IP does not match a familiar location, the failed authentication count is incremented.
If the failed attempts from an unfamiliar reaches the lockout threshold and the failed authentication is from an unfamiliar location the account is locked out.
You can set the threshold using this cmdlet:
|
1 |
Set-AdfsProperties -ExtranetLockoutThreshold 10 |
- Observation window setting
Once the account is locked the observation window setting is used. This is the time in minutes that an account remains locked, after the account unlocks, only one authentication attempt is allowed. If this one authentication attempt is successful the ‘failed authentication count’ is reset to 0, if the authentication attempt fails the account will remain locked for an additional observation window after which the accounts once again unlocks and one authentication attempt is allowed.
You can set the Observation window using this cmdlet:
|
1 |
Set-AdfsProperties -ExtranetObservationWindow ( new-timespan -minutes 10 ) |
Enable lockout
You can enable or disable the extranet lockout using either one of these cmdlets:
|
1 2 3 4 5 |
# To enable extranet lockout Set-AdfsProperties -EnableExtranetLockout $true # To disable extranet lockout Set-AdfsProperties -EnableExtranetLockout $false |
Enfore SmartLockout
Once you’ve monitored your environment for a couple of days and you want to enforce the setting you can set your environment to enforce the setting by running this cmdlet after which you will need to restart the adfs service to activate the new setting:
|
1 2 3 4 5 |
# Enable ESL Enforce mode Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce # Restart the AD FS Service Restart-service adfssrv |
User activity
In a separate blog I will go into more detail on this subject, below is a summary on how to monitor user activity.
You can find the account activity by running this cmdlet: Get-AdfsAccountActivity
|
1 |
Get-ADFSAccountActivity user@xanderbikbergen.com |
You can manually add a familiar location to a user or erase state for an account
|
1 |
Set-ADFSAccountActivity user@xanderbikbergen.com -FamiliarLocation “1.2.3.4” |
Reset the lockout counter for an user account
|
1 |
Reset-AdfsAccountLockout user@xanderbikbergen.com -Familiar |
Using the internal Windows Database and when I run this command Update-AdfsArtifactDatabasePermission -Credential $Credential it is successful, however when I run the diagnositc tool it keeps telling me The ADFS service account has insufficent privileges to create the Account Activity database. I’ve run that command several times, rebooted etc but diagnositc keeps giving me that error.
I just wanted to note that this note for SQL server:
ALTER AUTHORIZATION ON SCHEMA::[ArtifactStore] TO [db_genevaservice]
Is insufficient – schema ownership does not grant the CREATE TABLE right and this feature requires the creation of a table in the database. An error is logged in the AD FS admin log regarding the failure to create the new table each time the service is restarted. I couldn’t find any information about the best way to resolve this, so I just granted CREATE TABLE permission to the db_genevaservice role on the AdfsArtifactStore database and the table was created.