0

Enabling AD FS 2012 R2 Extranet Lockout Protection

Security is an integral aspect of running modern IT operations.  There is a clear understanding that we need to protect our IT assets, company data and personal identifiable information.  So when we discuss a migration to Office 365, security is an inevitable topic.  One aspect that we need to discuss is around account lockout, and how to protect our Active Directory accounts as part of the overall cloud solution.

Methods to protect user accounts can be broken down into a few categories that include:

  • Password complexity
  • Password length
  • Account lockout policy
  • Providing multi-factor authentication solutions

Customers wish to look at such options to mitigate the impact from:

  • User incorrectly entering password
  • Brute force attack on user accounts
  • Malicious account lockout

In a future post I'll circle back on the underlying account lockout policy discussion, so let's park that one for right now.  What I do want to cover in this post is AD FS and how it can impact account lockouts should you have an aggressive lockout policy enabled.

Update 3-9-2014: Please also review this post for an issue requiring a hotfix to resolve with Extranet Account Lockout Protection

AD FS Account Lockout

In the previous versions of AD FS there was no native mechanism within AD FS itself to prevent brute force attacks upon AD FS.  If AD has a password lockout policy set, then an external entity hammering the AD FS logon page could then lockout  an AD account.  If an entity knew the user account name, they could access the AD FS proxy page and enter a bad password for the user account.  The below is an example for AD FS 2.0 running on Windows 2008 R2.

Windows Server 2008 R2 ADFS Sign In Page

In order to mitigate this, the external firewall in front of the AD FS server could be set to only allow HTTPS traffic to the AD FS endpoint from the IP address ranges that are part of Office 365.  Since this is a manual configuration, the onus is on the on-premises firewall administrator to keep the IP ranges up to date else authentication may fail.  In the traffic flow, the HTTPS traffic coming to the on-premises AD FS proxy server is initiated from Office 365.  As discussed at MEC, this will have to be a planning point for the upcoming OAuth changes in Q2 this CY.  As part of the authentication changes, by default clients will connect directly to the AD FS servers.  Either the firewall rules will need to be changed, or modifications made to the clients to use the legacy behaviour.  More on that when the team announces the details later this year!  This was discussed publically at MEC in the What’s new in Authentication for Outlook 2013 session.

If you did not get to MEC, then the content is available here for your viewing pleasure!

AD FS 2012 R2 Extranet Lockout

Apart from locking down the firewall, Windows Server 2012 R2 AD FS now adds a feature to natively allow the AD FS proxy to prevent AD DS accounts from being locked out!  This is the Extranet Lockout feature.  This is similar to the TMG 2010 Soft Account Lockout feature that was introduced in TMG 2010 SP2.  It is said to be "soft" as the AD DS account is not locked, and after a period of time the AD FS server then automatically allows the account to retry the authentication.

Only Windows Server 2012 R2 has the  Extranet Lockout feature.  For this and other reasons you want to look at deploying Server 2012 for your AD FS infrastructure. Some reasons include:

  • Highly customisable pages
  • No more IIS dependency
  • The AD FS product team are heavily invested to make this the best release of AD FS
  • AD FS page dynamically responds to client type, e.g. mobile

Note that in Windows Server 2012 R2 AD FS the Extranet Account Lockout feature has a hard requirement on availability of the PDC Emulator role.  If the PDCe is not available, then the user cannot authenticate.  Please review this outstanding post by Pierre -- AD FS extranet lockout and PDC requirement.

Requirements

As mentioned above, only AD FS 2012 R2 has the Extranet Lockout feature.  Thus the AD FS infrastructure must be upgraded or installed as this version.  For upgrade steps, please check out the excellent ASKPFE PLAT blog!

While the Extranet Lockout feature is enabled on the AD  FS server, you must also deploy an AD FS proxy.

Traffic must hit the AD FS proxy.  If you publish the AD FS server instead or your network misroutes the traffic and bypasses the proxy, the Extranet Lockout feature will not work as expected.  Trust me, I’ve been there – but more on that later in a separate blog post!!

The other base AD FS requirements and prerequisites are also documented on TechNet.

Testing Environment

As with the other articles in the recent AD FS posts, this is again in the TailspinToys.ca lab.  The AD FS namespace is adfs.tailspintoys.ca.  The environment looks like the diagram below.  The AD FS server is deployed on the internal corporate network and is joined to AD.  The AD FS proxy is deployed in the DMZ, and is in a workgroup.  Since we are using AD FS 2012 R2, the AD FS proxy uses Web Application Proxy (WAP) rather than a dedicated AD FS proxy role as in older versions.

For the details in building this lab please see the previous series of three posts.

Simple ADFS Lab Deployment

The diagram was drawn with the April 2014 Visio Stencils for Office 365.

AD DS is set with a domain account lockout policy that states an account will lock out after 10 invalid logon attempts.  This can be seen in the GPO Management Console:

AD DS Account Lockout Policy

And for those LAN Manager freaks out there the command prompt too!

Verifying AD Account Lockout Policy Using CMD - Hardcore!

PS -- This was taken from a DC that does not have the PDC emulator role

So we know that after 10 attempts the account will lock out.  What happens if we launch a mini-DOS attack on some guy called user-1@tailspintoys.ca via the AD FS sign in page?

Browse to the AD FS sign in page in IE11 at https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm

Tailspintoys AD FS Proxy Signon Page

And we enter a bad password 11 times…

OOPS! Logging On To Tailspintoys ADFS Page With Bad Password

Staying with the LAN Manager freak show, look what happened to that poor user, their account is now locked out.

AD Acount Locked Out

On the AD FS server we see the  10 failed logon attempts before the account locked out:

10 Failed Authentication Attempts on AD FS Server

Zooming in on one event we see that the response from AD is that this is an unknown user name and bad password.  Well, that’s the generic text string.  If we really want to know what is going on, then we look at the status and sub status codes.  In this case 0xC0000006D maps to the bad user name response but  0xC0000006A tells us that the password was not correct.  Well, that’s because I was making like Jean Michel Jar on the keyboard to make up a random string in the password entry field.  Well, less the light show….

Authentication Attempt on AD FS Server - EventID 4625 Bad Password

Not good!  A malicious person ( moi ! ) managed to do a denial of service on this account.

AD FS Extranet Lockout to the rescue!

Extranet Lockout Feature Details

In the context of AD FS in Windows Server 2012 R2, Web Application Proxy functions as a federation server proxy. Web Application Proxy also serves as a barrier between the Internet and your corporate applications.

Web Application Proxy provides a number of security features to protect your corporate network, such as your users and your resources, from external threats. One of these features is AD FS extranet lockout. In case of an attack in the form of authentication requests with invalid (bad) passwords that come through the Web Application Proxy, AD FS extranet lockout enables you to protect your users from an AD FS account lockout. In addition to protecting your users from an AD FS account lockout, AD FS extranet lockout also protects against brute force password guessing attacks.

There are three AD FS settings that we need to look at with respect to the Extranet Lockout feature.

  1. ExtranetLockoutEnabled -- To enable/disable.
  2. ExtranetLockoutThreshold  -- Defines the maximum number of bad password attempts.
  3. ExtranetObservationWindow – Defines the time period where AD FS does not attempt to contact the domain controller to validate the username + password ad immediately rejects the request from outside.

The intent is that the AD FS administrator will define a maximum number of failed authentication requests that the AD FS proxy will allow in a certain time period.  Once these authentication attempts have been used up for that specific user, then the AD FS server will go into <Seinfeld> soup Nazi --  no auth for you!!!  </Seinfeld>.  The AD FS proxy server will then cease attempting to log the user on.  By doing so, it does not hammer on the AD account thereby locking the AD account out.    This protects the AD account from losing access to all resources, i.e. it is still functional on the corporate network and can get to file and print resources etc.

One thing to note.  The value for the ExtranetLockoutThreshold on the AD FS server must be set to a lower value than the AD DS account lock out threshold, else the AD DS account will lock out before the AD FS proxy ceases to attempt authentication and enabling this on AD FS is pretty pointless!!

This is a global setting on the AD FS server, and the settings apply to all domains that the AD FS server can authenticate.  Please plan accordingly.

To configure the AD FS extranet lockout, you must set three properties on the AD FS service object.  To set the configuration, use Set-ADFSProperties and Get-ADFSProperties to verify.

For example, you can use the following oneliner PowerShell command to set the AD FS extranet lockout:

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (New-Timespan -Minutes 30)

(The command is one line, please ensure that it does not word wrap)

You could split it out into multiple commands if desired:

$Timespan = New-TimeSpan -Minutes 30
Set-AdfsProperties -EnableExtranetLockout $True -ExtranetLockoutThreshold 15 -ExtranetObservationWindow $Timespan

Get-AdfsProperties | Format-List *extranet*

(Each command is one line, please ensure that it does not word wrap)

Configuring Extranet Lockout

Opening up PowerShell on the AD FS server, and querying for the *Extranet* values we can see the default Extranet Lockout settings.  Extranet Lockout is disabled by default.

As noted above, we enabled Extranet Lockout on the AD FS server NOT on WAP.

Server 2012 R2 AD FS Default Extranet Lockout Settings

Where is the default value for the lockout threshold coming from?  Since it is disabled, 2147483647  is the maximum value in an Int32 data type.  Run [int32]::maxValue in PowerShell to see.

Let’s now configure the AD FS server so that the AD FS proxy will lock out after 4 bad attempts in a 60 minute observation window.

$Timespan = New-TimeSpan -Minutes 60

Set-AdfsProperties -EnableExtranetLockout $True -ExtranetLockoutThreshold 4 -ExtranetObservationWindow $Timespan 

Get-AdfsProperties | Format-List *extranet*

(Each command is one line, please ensure that it does not word wrap)

Configuring Server 2012 R2 AD FS Extranet Lockout Settings

Beware The Fiendish Syntax

When I first tried to configure this feature, I ran into this wonderful error:

Configuring Server 2012 R2 AD FS Extranet Lockout -- Beware Syntax

Set-AdfsProperties : A parameter cannot be found that matches parameter name 'ExtranetLockoutEnabled'.
At line:1 char:20
+ Set-AdfsProperties -ExtranetLockoutEnabled $True
+                    ~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidArgument: (:) [Set-AdfsProperties], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.IdentityServer.Management.Commands.SetServiceProperties Command

Huh???

As we saw above, there is definitely a property on the AD FS object that is called ExtranetLockoutEnabled – so why was I unable to set it?

This is probably because I have been spoilt with Exchange PowerShell since 2006.  The attributes are carefully thought out and after running a get cmdlet we just change it to a set cmdlet and change what we need.  For that reason I get frustrated with Windows PowerShell, especially the AD cmdlets.  Why do I have to have a separate cmdlet for each tiny task?  Anyway  I digress…

In this case the developer changed the parameter that we use to set ExtranetLockoutEnabled.  To set it we have to use the EnableExtranetLockout parameter.  The two values are different:

  • ExtranetLockoutEnabled – to review setting
  • EnableExtranetLockout  - to change setting

It’s always the little things that get me……

Testing AD FS Extranet Lockout

After waiting a minute for the AD FS proxy to pickup on the change, we can test to make sure this is working!

Remember that AD DS is set to lockout after 10 invalid logons, and AD FS will cease after 4 failed authentication attempts.

Again we browse to the AD FS sign in page in IE11 at https://adfs.tailspintoys.ca/adfs/ls/idpinitiatedsignon.htm

This time we will pick on user-2@tailspintoys.ca, just so that it is easy to distinguish the two scenarios in the event logs.

Again, the account is hammered with 11 bad logon attempts.

Sign In To Tailspintoys ADFS Authentication Page

This time however, there are only 4 failed audit events on the AD FS server:

4 Failed Authentication Attempts For User-2

Please note The events at from 02:10 to 02:11 were the user-1 logon attempt at the top of this blog post.

Let’s check the status of the User-2 account

Even after 11 bad logon attempts via the AD FS proxy, the account is still active – boyashaka !

User-2 Not Locked Out After 11 Bad Logon Attempts

Just to prove what is in the security event log of the AD FS server, let’s look for audit failure events over the last day for each of these test accounts.  To look for this data, PowerShell will be the weapon of choice.  Note that Get-EventLog is not used as it lame when it comes to filtering so we will use Get-WinEvent which is way more powerful.  Why the difference?  Get-Eventlog was in the initial PowerShell release and Get-WinEvent was added in PowerShell 2.0…..

The code used below is:

$StartTime = (Get-Date).AddDays(-1)

Get-WinEvent -FilterHashtable @{Logname="Security"; ProviderName="Microsoft-Windows-Security-Auditing"; Data="user-2@tailspintoys.ca"; StartTime=$StartTime} | Measure-Object

Get-WinEvent -FilterHashtable @{Logname="Security"; ProviderName="Microsoft-Windows-Security-Auditing"; Data="user-2@tailspintoys.ca"; StartTime=$StartTime}

The $StartTime variable goes back 24 hours from when it was created, i.e. a day.  We then create a hashtable and look for only failure security audits for accounts that match the given username.  In the example above this is the user-2@tailspintoys.ca account.    Measure-Object is used to save us having to count….

First up is user-1.  Note that there are 10 failed logon attempts which corresponds to the AD DS account lockout policy.  The timeframe of the "attack” was 02:10 – 02:11.

Using Get-WinEvent To Retrieve Audit Failures For User-1

For User-2, note that there are only 4 failed logon attempts.  This correlates to the AD FS Extranet Lockout protection setting.  Also note that since the AD FS lockout setting is lower than the AD DS account lockout policy the AD DS account is not locked out.

Using Get-WinEvent To Retrieve Audit Failures For User-2

Troubleshooting AD FS

In addition to the content and links in the previously published AD FS blog posts there is also the following:

Troubleshooting AD FS

Summary

AD FS 2012 R2 Extranet feature lights up a new feature to make it very easy to provide protection from AD DS account lockout scenarios where the internal AD account is locked out due to malicious or fat-fingered end user logon attempts.

One thing to note is that applications that require AD FS to federate the authentication request will not be able to do so whilst this account is in a state of Extranet Lockout. Because of this some organisations may still choose to restrict access to their AD FS proxy via firewall rules and to set “reasonable” AD account lockout policies. We can talk more next time about why locking an AD account out after 3 bad attempts is not so good…..

Cheers,

Rhoderick

Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *