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 ADFS 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

ADFS Account Lockout

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

In order to mitigate this, the external firewall in front of the ADFS server could be set to only allow HTTPS traffic to the ADFS 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 ADFS 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 ADFS 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!

ADFS 2012 R2 Extranet Lockout

Apart from locking down the firewall, Windows Server 2012 R2 ADFS now adds a feature to natively allow the ADFS 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 ADFS 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 ADFS infrastructure. Some reasons include:

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

Requirements

As mentioned above, only ADFS 2012 R2 has the Extranet Lockout feature.  Thus the ADFS 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 ADFS server, you must also deploy an ADFS proxy.

Traffic must hit the ADFS proxy.  If you publish the ADFS 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 ADFS requirements and prerequisites are also documented on TechNet.

Testing Environment

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

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

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:

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

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 ADFS sign in page?

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

And we enter a bad password 11 times…

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

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

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….

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 ADFS 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 ADFS administrator will define a maximum number of failed authentication requests that the ADFS proxy will allow in a certain time period.  Once these authentication attempts have been used up for that specific user, then the ADFS server will go into <Seinfeld> soup Nazi --  no auth for you!!!  </Seinfeld>.  The ADFS 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 ADFS 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 ADFS proxy ceases to attempt authentication and enabling this on ADFS is pretty pointless!!

This is a global setting on the ADFS server, and the settings apply to all domains that the ADFS 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 ADFS server, and querying for the *Extranet* values we can see the default Extranet Lockout settings.  Extranet Lockout is disabled by default.

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 ADFS server so that the ADFS 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 | Fl *extranet*

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

Beware The Fiendish Syntax

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

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 ADFS 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 ADFS Extranet Lockout

After waiting a minute for the ADFS 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 ADFS 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.

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

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 ADFS proxy, the account is still active – boyashaka !

Just to prove what is in the security event log of the ADFS 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.

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.

Troubleshooting ADFS

In addition to the content and links in the previously published ADFS 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 ADFS 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 ADFS 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