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.



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


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



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



Comments (50)

  1. anonymouscommenter says:

    When discussing and reviewing Office 365 with customers, I wanted to have a series of posts to illustrate

  2. anonymouscommenter says:

    Awesome stuff(as always)
    thanks alot of sharing
    jokes aint bad either:)

  3. Great post R! QQ on the functionality: Is the lockout count per source IP or all up regardless of source? I’m thinking that if a malicious user is coming from and the real me comes from, that his IP should be blocked from sending further requests, but not mine. Otherwise he is successful in locking out my account when accessed by federation, but only for the duration of the observation window.

  4. Hey Craig!

    I tested this right now from two separate machines, both are on totally separate networks with different real world IP addresses.

    Tried two auth attempts from each. As expected there are four audit fails, as shown above.

    When I then try a third attempt from one of them (5 attempts in total now), there are no more audit fails and the account is in the adfs lockout state.


  5. Thanks Meagain – I’m tying to work on the jokes, but that part’s pretty painful…………

  6. anonymouscommenter says:

    Pingback from NeWay Technologies – Weekly Newsletter #94 – May 8, 2014 | NeWay

  7. anonymouscommenter says:

    Pingback from NeWay Technologies – Weekly Newsletter #94 – May 9, 2014 | NeWay

  8. anonymouscommenter says:

    Pingback from Weekly Newsletter #94 – May 9, 2014 | Just a Lync Guy

  9. anonymouscommenter says:

    Pingback from Weekly IT Newsletter – May 5-9, 2014 | Just a Lync Guy

  10. anonymouscommenter says:

    Pingback from Weekly Newsletter #94 – May 9, 2014 | Just a Lync Guy

  11. anonymouscommenter says:

    Pingback from Interesting things that i see on the internet, may 2014. | 503 5.0.0 polite people say HELO

  12. anonymouscommenter says:

    Pingback from Better Password Management Using Windows Security Policy Console | Zahal IDF Blog NewsZahal IDF Blog News

  13. anonymouscommenter says:

    Thanks for the writeup, very helpful. I have a bug to report with the Extranet Lockout Protection feature. What is the proper channel to do so?

  14. Hi Phil,

    That should go through a support case, so it can be triaged and get to the product group. Can you click onto the contact blog author link on the right hand side and let me know what you are seeing please?


  15. anonymouscommenter says:

    Although this solves a problem, I wonder if it creates a new problem in its place.

    Does this feature prevent timing attacks from leaking usernames? e.g. suppose the first 10 attempts on a username responds on 5 ms each. Then after lockout the "denial" is 1ms…. that effectively tells the attacker how many attempts they can run, and the window
    it’s in.

  16. anonymouscommenter says:

    Thanks for the post!
    I’d like to ask a question about the topic: where does it store the information about a user being locked out?
    Is it in AD? In the Database? When DB, what about farm vs. non-farm and standalone sql vs. integrated sql?

  17. anonymouscommenter says:

    I’m seeing issues with this feature where if ADFS happens to talk to a DC that has badPwdCount ‘unset’ for a particular user, they’re unable to authenticate. ADFS auditing logs the following exception to the security log:

    Exception details:
    Microsoft.IdentityServer.Service.AccountPolicy.ADAccountLookupException: Exception of type ‘Microsoft.IdentityServer.Service.AccountPolicy.ADAccountLookupException’ was thrown.
    at Microsoft.IdentityServer.Service.AccountPolicy.AccountLockoutPolicy.IsAccountThrottled(String userName)
    at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)
    at Microsoft.IdentityModel.Tokens.SecurityTokenHandlerCollection.ValidateToken(SecurityToken token)
    at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.GetEffectivePrincipal(SecurityTokenElement securityTokenElement, SecurityTokenHandlerCollection securityTokenHandlerCollection)
    at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)

    Is this a known issue? Thanks in advance.

  18. anonymouscommenter says:

    The badPwdCount attribute as "unset" is fixed in hotfix

  19. anonymouscommenter says:

    ADFS 2012 R2 provides an interesting feature called Extranet Lockout Protection, where the intent is

  20. Thanks Brian!

    That update is interesting as it talks about the GMSA – so I played with it here :



  21. anonymouscommenter says:

    So, how to recover if an account is ‘soft locked-out’ by means of ADFS? Is there an ‘unlock’ checkbox somewhere?

  22. Ronny – there is no unlock button.

    wait the prescribed time
    reset the badPW count on the user object.
    Or change the password


  23. anonymouscommenter says:


  24. And the badPwdCount isn’t replicated. So if you want to go that way, you need to do on the DC used by the ADFS server from which the lockout has been triggered…

  25. Thanx Pierre! Totally agree.

    An example of looking at the badpwdCount is in this related post


  26. anonymouscommenter says:

    Ronny -"So, how to recover if an account is ‘soft locked-out’ by means of ADFS? Is there an ‘unlock’ checkbox somewhere? "

    Use the unlock checkbox in ADUC to reset badPwdCount

  27. anonymouscommenter says:

    When do we get the related feature called logging ?
    We are many that work in companies with more than 10 users, and where users has more than 1 device. Most users has at least 1 iPhone and 1 iPad checking mail with O365. When their account gets locked out, we have nowhere to go to get the IP address of the client
    with the failed login attempt.

    Please give us logging of the client IP address. I do not understand why this feature is not there yet ? Is nobody apart from us using ADFS in real life ? When looking for a solution, I found only questions. And MSFT employees saying that this is a feature
    request. Nobody af MSFT ever though anybody would want the IP address of the bad device / Hacker.

  28. anonymouscommenter says:

    This is a link throw-down for the items that we discussed during a recent Office 365 workshop that I

  29. anonymouscommenter says:

    Is there a way through the ADFS customization to customize the errors that are returned to the user when their account is in a locked out status?

  30. anonymouscommenter says:

    Just in case if you haven’t seen this series, I’ve been writing an ADFS Deep-Dive series for the past

  31. anonymouscommenter says:

    Hi Rhoderick!

    Thanks for writing down everything in such simple and understandable language. I really appreciate it.
    I am stuck at something similar. I posted the question on stackoverflow but I feel you’re the best person to help me. Do you mind looking at this?


    Thanks again!

  32. Hi Anvesha,

    You are trying to implement this on ADFS 2 on Server 2008. You need to upgrade to ADFS 2012 R2. The extranet account lockout feature is not present in any builds prior to that.


  33. anonymouscommenter says:

    Very nice article in simple language. I have a question where you said firewall rule with O365 IPs for https can also solve this issue. However my understanding is even when we enter portal.office.com and type user@domain.com, it redirect us to adfs proxy
    where we enter password. If someone enters password multilple times here it will block also regardless of http request coming from O365 so firewall rule will not be able to save us here(Expect any direct brute force to adfs proxy) , is my understanding correct?

  34. anonymouscommenter says:

    Great article with a lot of excellent details! Does anyone understand how this interacts with Fine grain Password Policies? Does ADFS Proxy understand these values, or should the ExtranetLockoutThreshold  just be shorter than any account lockout policy
    defined in the domain? Thanks

  35. MattHudson says:

    Very useful and well explained, thanks!

  36. anonymouscommenter says:

    The Extranet Lockout is a new feature available on Windows Server 2012 R2 ADFS when the Web Application

  37. anonymouscommenter says:

    I have one server running ADFS and one running Web Application Proxy. I am investigating several accounts that are being locked by Kerberos Pre-Authentication coming from the ADFS – it registers a bad password every 5 minutes for some users. I was looking
    to implement the extranet lockout feature and was informed by the third party that configured ADFS for us that I should do this on the proxy server. However, the proxy server doesn’t have the ADFS service installed, just the Web Application Proxy. PowerShell
    on the proxy server does not recognize the get-adfsproperties command. Do I run this on the internal server to set the Extranet Lockout feature, or does it have to be done on the proxy server?

  38. On ADFS itself Eric.

    This is in the section:
    Configuring Extranet Lockout

    Opening up PowerShell on the ADFS server


  39. anonymouscommenter says:

    How do you reset the badPW count on the user object?

  40. anonymouscommenter says:

    Tracking down the devices locking out accounts on an ADFS deployment is quite challenging. From an ADDS

  41. Jonty says:

    Our issue is with WAP proxy and how it just cannot scale to our needs. Certificates expiring all the time becomes a nightmare when you use hardware load balancers. All I want is “extranet protection”, is there any way I can build a custom WAP proxy in C# or even on our hardware load balancer so I can avoid WAP proxy!?

    1. There are some third party solutions that will do that. But why are your certificates expiring, is that load balancer terminating SSL and not allowing the WAP to talk directly to the ADFS server?


  42. Vinay Kumar says:

    Hello There,

    This is really great to know that ADFS 3.0 has much more secured concepts and I would like to appreciate you for providing Extra-net Lockout Protection very clearly.

    I am looking for ADFS 3.0 password Complexity Get and Set power shell commends as you mentioned for Lockout Protection..

    looking forward for your reply on this.

    Vinay Kumar

  43. Gopi says:

    Hello ,

    Thanks for information . If AD account locked , User will get notification as reference account is Locked when logs in computer.

    Can we get such error message in ADFS page also ?

    K Gopi

  44. Masood says:

    Hi Rhoderick,

    I have been following you for ADFS related article for quite some times. Really great writings. AD FS Extranet Lockout is what I’m looking for these days.

    What If my environment has Windows 2012 instead R2. How do I secure Extranet Lockout

    1. Hi Masood,

      As noted above this feature was introduced in Windows Server 2012 R2. If you have an older version of AD FS, then you will need to upgrade fully to either 2012 R2 or 2016 AD FS to be able to use Extranet Account Lockout Protection.


  45. Mike says:

    Our users use company Microsoft accounts on Windows Phone Mobile – for example john.doe@company.com.
    If we migrate to Office 365 and use federated identities, I am suspicious that this could cause AD account lockouts since john.doe@company.com will exist in Office 365 and authentication will be forwarded to ADFS. Could this be an issue or is there a seperation between private Microsoft accounts and Office 365 accounts?

    1. I’m a bit confused with the question statement Mike. Is the issue related to lockouts on the AD account or the interaction between consumer / corporate accounts?


Skip to main content