Configuring Account Lockout throughout a Hybrid Identity Environment

Hybrid Identity

Denial of Service attacks on identity and access systems are common place. When you think you’re done when you’ve covered all the bases with account lock-out in your on-premises Active Directory Domain Services (AD DS) environment, you’re wrong. Hybrid Identity requires more effort and Microsoft only made the tools you need generally available this month.

Let’s have a look.

 

A multi-layer approach

Attackers may cause Denial of Service through password spraying (trying the same password on all user accounts) and/or brute-force attacks (trying multiple passwords for one user account). As accounts get locked, end users experience errors when they themselves log on and disruption in their logged-on applications.

To avoid the Denial of Service situations, common endpoints need to be protected in a smart way. I feel this requires a multi-layer approach, where the actual account lock in the Identity Provider is prohibited from end user-facing endpoints.

Also, Hybrid Identity is different from a couple of years ago. Previously, all we needed to focus on was Active Directory Federation Services (AD FS). Today, account lock-out needs to be available for all sign in methods, whether the organization leverages AD FS, Password Hash Sync (PHS) or Pass-through Authentication (PTA).

The layers should be:

  1. Extranet Smart Lock-out (for AD FS)
    Azure AD Custom Smart Lock-out (for PHS and PTA) Preview
  2. Active Directory (AD) password and account lock-out policies

Note:
As the Azure AD Lock-out feature doesn’t affect authentications when Active Directory Federation Services (AD FS) is used as the sign in method, we’ll have to configure the Extranet (Smart) Lock-out feature in AD FS instead of the Azure AD Lock-out feature.

We’ll have to make sure the most outwards-oriented layer has lower values for the lock-out threshold and observation time window, than the inner-most layer. This way, the outer layer would cause an account lock-out earlier than the inner layer. Then, end users might always revert to inside authentication when the outside authentication is locked out.

For the purpose of this blogpost, we’ll use a lock-out threshold of 10 attempts during an observation window of 5 minutes and a lock-out period of 5 minutes for outside authentication and 5 attempts within 5 minutes for indefinite lock-out for inside authentication (after which the account will need to be unlocked by service desk personnel).

 

Configuring AD FS Extranet Smart Lock-out

Requirements:

  • Active Directory Federation Services (AD FS) as sign in method
  • AD FS Servers running Windows Server 2016
  • June 2018 Cumulative update KB4284880, or above installed on all AD FS Servers

When your organization has deployed Active Directory Federation Services (AD FS) with Web Application Proxies or other MS-ADFSPIP-enabled front-end servers (like F5 appliances), you should be familiar with the AD FS Extranet Lock-out feature, as depicted below:

Overview of AD FS Smart Account Lock-out (Click for original picture)

For organizations leveraging Active Directory Federation Services (AD FS) on Windows Server 2016, a new feature is available, labeled Extranet Smart Lock-out. This feature is generally available since the June 2018 Cumulative update for Windows Server 2016 (KB4284880, OS Build 14393.2312).

Note:
The feature was originally announced as part of the March 2018 Cumulative update for Windows Server 2017 (KB4088889, OS Build 14393.2155). After a quality issue was detected, the feature was postponed to May/June, where it was mentioned as:

Addresses an issue where enabling Extranet Smart Lock-out in UTC +1 and higher (Europe and Asia) did not work.

The difference between ‘normal’ Extranet Lock-out and Extranet Smart Lock-out is the use of a new AccountActivity table in the Artifact Resolution Store of the AD FS farm or in the Windows Internal Database (WID) installations on all AD FS servers in the AD FS farm.

Whenever a password-based authentication is successful, a ‘familiar IP’ address is added to the table. Whenever a password-based authentication, originating from an unfamiliar IP address failed, the failed authentication count for that IP address is incremented. When the failed authentication count for an unfamiliar IP reaches the lock-out threshold, authentication attempts from the specific unfamiliar IP address are locked out. However, end users from familiar IP addresses do not experience any lock-outs, because lock-outs from familiar locations apply separately from this new unfamiliar lock-out counter.

To enable Extranet Smart Account Lock-out for an AD FS farm using Windows Internal Database (WID), run the following lines of PowerShell:

Set-AdfsProperties -ExtranetLockoutThreshold 10

Set-AdfsProperties -ExtranetObservationWindow (New-Timespan -minutes 5)

Set-AdfsProperties -EnableExtranetLockout $true

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce

Restart-Service adfssrv

 

Configuring Azure AD Custom Smart Lock-out

Even when organizations are not running Active Directory Federation Services, or are using another sign in method for Azure Active Directory and its connected services, like Office 365, account lock-out can be configured:

Overview of Azure AD Smart Lock-out (Click for original picture)

Instead of configuring Extranet Smart Lock-out in AD FS, account lock-out needs to be configured in Azure AD.

Perform these steps:

  • Log into the Microsoft Azure Portal with an account with Company Administrator / Global Administrator privileges.
  • In the left navigation pane, click on Azure Active Directory.
  • In the Azure AD navigation pane, click on Authentication methods. Scroll down in the navigation pane until you see it, if needed.

Custom Smart Lockout in Preview for Azure AD (click for original screenshot)

  • In the Custom smart lockout field, specify the settings for Lockout threshold and Lockout duration in seconds.

Note:
The value entered for Lockout duration in seconds applies to each lock-out, but if an account locks repeatedly, the duration increases exponentially.

  • Click Save in the top bar, when done.

 

Configuring AD password policies

Requirements:

  • At least one Active Directory Domain Controller running Windows Server 2012, or up
  • The Active Directory Domain Functional Level (DFL) must be Windows Server 2008

The inner layer consists of fine-grained Password and Account Lock-out policies (FGPP). With the availability of managing Fine-grained Password Policies from the Graphical User Interface (GUI) of the Active Directory Administrative Center (ADAC) and in Windows PowerShell, it has become much easier to manage password and lock-out settings for (groups of) users.

Use the below lines of code to create a fine-grained password policy and assign it to the built-in Domain Users group:

New-ADFineGrainedPasswordPolicy -Name LockoutPolicy -DisplayName LockoutPolicy -Precedence 100 -ComplexityEnabled $true -ReversibleEncryptionEnabled $false -PasswordHistoryCount 10 -MinPasswordLength 8 -MinPasswordAge 0.00:15:00 -MaxPasswordAge 42.00:00:00 -LockoutThreshold 20 -LockoutObservationWindow 0.00:5:00 -LockoutDuration 0.00:30:00

Add-ADFineGrainedPasswordPolicySubject -Identity LockOutPolicy -Subjects “Domain Users”

 

Concluding

We’ve seem to have come full circle. Where a couple of decades ago, password attacks caused denial of service in Active Directory environments, we’re seeing the same kind of attacks on Hybrid Identity environments.

Luckily, this time, there is comprehensive multi-layer protection available.

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.