ADFS in Windows Server 2012 R2 (some call it “ADFS v3″) comes with a number of very cool features – one of them is “Extranet Lockout Protection”: http://blogs.technet.com/b/rmilne/archive/2014/05/05/enabling-adfs-2012-r2-extranet-lockout-protection.aspx, https://technet.microsoft.com/en-us/library/dn486806.aspx.
The idea behind that is that, if you expose your ADFS to the internet, which makes sense in many scenarios, and you use Web Application Proxy to do so, you want to protect yourself from Denial of Service (DOS) attacks. Clever attackers could try to brute-force logon to your ADFS servers, by simply trying out and testing username and password combinations – or worse, they now how your usernames are constructed and try out a number of passwords for a given username. If you then have Windows Active Directory configured to lock a user account after too many faulty logon attempts, it can happen that the attacker locks an account in Windows AD.
Now that an undesired behavior that Extranet Lockout Protection is trying to prevent. Once enabled, you configure a threshold, much like in the Windows AD Account Lockout Policy in Windows AD, to let ADFS observe these kinds of logons and, before the accounts gets locked out, stop forwarding the logon attempts to Windows AD.
I’ve found that the process of how ADFS determines this is not very well document (yet), and I’ve found myself have a wrong understanding of how this all happens. So to shed some light into this – here’s a little write-up of information I got from the Product Group and testing with a customer of mine.
The threshold for Extranet Lockout Protection should be configured to be lower than the Lockout settings in Windows AD, so ADFS can stop trying to log on before it’s too late.
The threshold is stored in the ADFS configuration database, so all ADFS servers can participate in Lockout protection – however, that’s all information that’s stored in regards to that feature in the ADFS config DB – the rest is all determined while talking to Windows AD and Domain Controllers – and that’s where you should make sure your DC connectivity supports this.
Assume you have ADFS installed included WAP servers and you have Extranet Lockout Protection enabled – after four attempts, the account is protected and no more logon attempts are sent to Windows AD, because the fifth attempt would lock out the Windows AD account. Here’s the flow of events:
- When a user is presented with the forms-based logon mask from the WAP and they enter a username and password combination, WAP sends the request to ADFS. ADFS first checks on a local* Domain Controller, whether the account exists.
- Once we’re sure the account exists, we’ll send a LDAP call to the user domain’s PDC emulator** to retrieve the user’s current badPwdCount attribute value. That’s where previous bad logon attempts are stored.
- To validate the observation window that’s configured with ADFS, we’ll consult the badPasswordTime attribute on the user’s account from the PDC – with an LDAP call again. Both badPwdCount and badPasswordTime give us all information we need to decide whether to try to authenticate the user against a local* DC or to protect from a lockout.
- If the badPwdCount is smaller than what we’ve configured as a threshold in ADFS, we’ll send the logon request to a local* Domain Controller to verify.
- If the badPwdCount is equal or greater than what we’ve configured as a threshold in ADFS, we’ll stop the authentication attempt here. We’ll send a “Username or password incorrect” message back to WAP, to notify the user.
Now – it should have become apparent that your ADFS servers (not the WAP boxes) need access to the PDC-Emulator FSMO role owner of all Windows AD domains you want to authenticate users at. Otherwise, ADFS will resort to just try the authentication, risking that the users will be locked out on the local* DC. The ADFS team might improve the algorithm in the future, to fall back to the local* DC for the badPwdCount, in case the PDC isn’t available – but for 2012 R2, we’ll have to make sure the PDC is available to the ADFS servers. So if you have firewall rules in place that prevent communication, you might need to loosen them.
You might also consider that this implies additional network traffic to and from the PDC-E FSMO role owner to your ADFS boxes. Especially if you’re looking at a globally dispersed ADFS farm(s) deployment – the roundtrip between the ADFS nodes and the PDC-E might slow down authentication.
Lu blogged about this on her blog at: http://blogs.msdn.com/b/luzhao1/archive/2015/06/24/demystify-extranet-lockout-feature-in-ad-fs-3-0.aspx
*= local as in “following the DCLocator process, finding a nearby/same-site DC.
**= The PDC is our authoritative source for this attribute here. A local DC might not necessarily have the correct count. badPwdCount is non-replicated attribute.