Exchange administrators running Office 365 may want to deploy Active Directory Federation Services on Windows Server...
2012 R2 and make the service available via an extranet on the Web Application Proxy server role. The Active Directory Federation Services extranet lockout feature, a security feature of the Web Application Proxy server role, can help. Extranet lockout protects against denial-of-service and brute-force password attacks.
Take, for example, an Active Directory environment that has been configured to lock out the end-user account after a number of unsuccessful attempts to enter the correct password. If Active Directory Federation Services (AD FS) is deployed into this environment and the extranet lockout feature isn't configured accordingly, the user account could be locked out by accessing the Web Application Proxy (WAP) server authentication screen from the extranet and entering an invalid password numerous times in quick succession. The number of invalid password attempts would need to exceed the account lockout threshold specified in Active Directory.
With the AD FS extranet lockout feature configured accordingly, the account in this scenario wouldn't be locked out. Although extranet access would then not be possible for a period of time, the end user would still be able to log on from the internal network.
Understand the parameters
To view extranet lockout settings, run the Get-AdfsProperties PowerShell cmdlet against an AD FS server running on the Windows Server 2012 R2 operating system. There are three parameters that combine to configure the overall extranet lockout feature (Figure 1).
ExtranetLockoutEnabled. The value of this parameter determines whether the extranet lockout feature is enabled. The extranet lockout feature is disabled by default, and this parameter returns a Boolean value of false.
It isn't unreasonable to assume that admins can enable the extranet lockout feature by running the Set-AdfsProperties cmdlet with the ExtranetLockoutEnabled parameter to a Boolean value of true. However, the correct parameter to use is actually EnableExtranetLockout. The full command required to enable the extranet lockout feature is:
Set-AdfsProperties –EnableExtranetLockout $true
ExtranetLockoutThreshold. The value of the ExtranetLockoutThreshold parameter specifies the number of incorrect password attempts the WAP server will allow before AD FS stops communicating with the Active Directory domain controllers. The ExtranetObservationWindow determines how long AD FS stops communicating with the Active Directory domain controllers.
The ExtranetLockoutThreshold parameter value needs to be set lower than the Active Directory account lockout threshold. With this configuration, a user account isn't locked out if the end user continues to enter incorrect passwords via the WAP server authentication screen. Once the WAP server has received the number of incorrect password attempts for a particular user account as specified by the ExtranetLockoutThreshold parameter, AD FS will stop communicating with the Active Directory domain controllers for a specified period of time. The full command required to enable the lockout threshold to a specific value is:
Set-AdfsProperties –ExtranetLockoutThreshold <value>
ExtranetObservationWindow. The value of the ExtranetObservationWindow parameter specifies how long AD FS stops communicating with the Active Directory domain controllers if the number of incorrect password attempts specified in the ExtranetLockoutThreshold parameter is reached. The full command required to enable the observation window to a specific value is:
Set-AdfsProperties –ExtranetObservationWindow <time period>
Test the AD FS lockout feature
To test the AD FS extranet lockout feature, use AD FS auditing in conjunction with entering invalid passwords into the WAP server authentication screen. The use of AD FS auditing provides admins with event-log information to detail the actions taken and allows them to understand the overall process as well as understand if the extranet lockout configuration is operating as admins require.
First, admins will need to ensure that auditing has been enabled using the Local Security Policy snap-in. They must then configure auditing settings within AD FS, which can be achieved by performing four configuration steps:
- Open the AD FS Management snap-in.
- From the Action menu, choose Edit Federation Service Properties….
- Click the Events tab in the Federation Service Properties window.
- Select the Success audits and Failure audits check boxes.
Once AD FS is configured to record success audits and failure audits in the event log, admins can then proceed to enter invalid passwords into the WAP server authentication screen until the account lockout threshold is reached or exceeded. They will then be able to check the event log for information as well as the account's properties to confirm that it's locked out.
About the author:
Neil Hobson is a U.K.-based Microsoft consultant with a background in the design, implementation and support of infrastructure systems covering Active Directory, Windows Server, Exchange and Lync. He is currently focused on Office 365 in technologies such as Exchange Online, Lync Online, SharePoint Online, Yammer and Office ProPlus. He is also focused on the associated areas of identity, networking, migration and service integration. Neil is a member of the Chartered Institute for IT (MBCS) and was also a Microsoft MVP for Exchange Server from 2003 to 2010.
Manage Office 365 identities with AD FS
Use AD FS to control Office 365 access