We configured it according to the following technet article and blog post:
http://technet.microsoft.com/en-us/library/dn486806.aspx
http://blogs.technet.com/b/rmilne/archive/2014/05/05/enabling-adfs-2012-r2-extranet-lockout-protection.aspx
You can enable Extranet lockout on any ADFS server in your farm since it is a global setting.
After you enable the Extranet lockout feature, you can check your settings by using the powershell command Get-ADFSProperties, as shown below.
Get-AdfsProperties | Fl *extranet*
After configuring Extranet lockout, I wanted to test the new feature. It worked great in not locking out the Active Directory account of a user after many unsuccessful login attempts. It would just deny you from logging into ADFS but not the internal network.
You could see the entries in the security audit logs of the DC's stop at 8 bad password attempts -- exactly what I have the feature configured for as shown above. Very cool.
The one thing I noticed that was undesirable when Extranet lockout was enabled was that if you put in the wrong username, instead of telling you that you had a bad username / password combo, it would result in an error and give you no chance to re-type your correct username.
This is what happens when you enter a username that doesn't exist in Active Directory with Extranet lockout is enabled. Instead of displaying "Incorrect user ID or password" (which is the behavior when Extralockout is disabled) you get "An error occurred" and have no way to correct the username field without refreshing the page.
This is what I would expect if I typed a wrong username:
Hopefully I'll hear back soon from Microsoft and we will get a hotfix to correct the issue. Until then, I am turning off Extranet lockout to ensure a good user experience for my customers.
