it blocks the attacker while allowing access for valid authentication attempts.
Any organization which publishes applications to the Internet is probably aware of the Lockout problem – an attacker can execute a denial of service attack by repeatedly requesting a login with an incorrect password, which eventually locks out the targeted account.
If the login attempts are backed by an on-premises core directory (Active Directory, in many cases) these attacks will cause affected users to lose access to internal applications. Executed against multiple accounts, these attacks are therefore a significant nuisance, at best. If mission-critical accesses are prevented, the attacks can be much more serious.
Active Directory Federation Services (ADFS) has had protection against lockout attacks since Windows Server 2012 R2 (TechNet article here). In this case, the attack is stopped at the perimeter after a maximum number of failed attempts, without the internal account being locked (if, as recommended, the internal lockout value is higher than the value set on ADFS!). This does mean, however, that a denial of service attack on Extranet authentication can still be successful – ADFS will no longer authenticate the user after the configured number of failed attempts in the configured time window.
With the Pass-Through Authentication (PTA) feature of Azure Active Directory, we can configure a familiar architecture, where the user logs in to AAD, but the authentication request is fulfilled by an on-premises Active Directory. (See the webinar recording by my colleague Chris Lloyd here, and Alex Simons’ blog post here for more details on PTA). In this architecture, the Lockout issue arises once again: repeated failed login attempts will result in account lockout in the on-premises Active Directory.
New Smart Lockout Protection
Microsoft have now released their Smart Lockout Protection for PTA to preview. This is similar to the ADFS protection described above (only a certain number of attempts are permitted in a time window), but smarter: AAD uses analytics, using past sign-in behaviour, users’ devices and browsers, and “other signals”, to block the attacker but not other authentication attempts (e.g. from the real user). This implementation, therefore, should not only protect Intranet activity from DoS, but also Extranet activity.
Details of the feature, and the configuration steps for both AD and AAD, are here.
At OCG, we are committed to providing the most effective solutions for our customers, and are of course staying on top of the new developments as they emerge.
Note that both PTA and Smart Lockout Protection are still in Preview at the time of writing – but absolutely worth evaluation! For assistance with this and other issues around identity federation and application publication, please contact Oxford Computer Group at email@example.com.