Dynamic Geo-Location Zones and AD Account Lock-outs
We recently got the ability to create dynamic zones based on geo-location in the hopes of mitigating systemativ brute-force attacks to our Office 365 orgs (federated with Okta) originating from certain countries. These attacks are causing AD account lockouts and disrupting our users. However, as an academic institution, we didn't want to simply blacklist whole countries, as we have faculty and student legitimate access needs world-wide.
My hope was to be able to use group membership to block/allow access from these countries (perhaps an opt-in for those getting locked regularly or maybe the opposite, an opt-out for those that need access) but what I'm seeing is that the password attempt is happening before the deny policy is be evaluated so an incorrect password attempt is just that, and still locks out the account regardless of policy. A correct password attempt is actually a successful login (based on log entry) at first, then the policy is evaluated and the user is denied.
I guess I was hoping it would evaluate the other way around. So we've resorted to blocking two particular counties entirely even though we know legitimate users are being blocked as well. We're looking at options, perhaps requiring VPN access for user in these countries.
At Oktane this year, the theme was adaptive access (getting rid of passwords) and I *think* I saw an example of a new sign-in widget similar to what Microsoft and Google are using now, with the username being the only field and then leading to whatever factor(s) are required for access. This suggests to me (although I don't know this for certain) that the username might be evaluated before a password attempt is made, so the type of selective geo-location block based on group memebership I want to do would be possible.
Does that sound right? I saw the recommendation from an earlier similar question regarding AD lockouts to lower the Okta lockout to one less than AD, but so many of our services are in Okta now that doesn't really buy us much. Any other ideas on stopping these AD lockouts from these systematic brute-force attacks?
My name is Fabian from Okta Customer Support and I'll be helping out on this ticket. Looking at the Okta roadmap page (https://support.okta.com/help/OktaProductRoadMap) there is a 'Passwordless Authentication' feature in development. I think this is the one you saw at oktane, however I don't have too many details about it right now as it still is in development. This type of authentication should not trigger lockouts, but until it is fully developed, many changes can occur. I would suggest you to track the feature and when a beta opens for it, give it a try. As for any other ideas, you could set a lockout policy in AD that would not depend only on the number of attempts, but also on a time frame. As an example, if an end user is trying to login with invalid credentials 5 times in 30 minutes he would get locked, but if the user has 5 failed attempts in 40 minutes he would be locked. This could help you prevent users from getting locked out in AD at least.
Thanks Fabian, right now the attempts are coming in mere seconds apart... or in some cases once every minute, etc. No real way to avoid the lockout other than getting rid of the lockout policy. We'll definitely keep an eye on the passwordless authentication and sign for a Beta right when we can. Thanks for the roadmap link, I had forgotten that was there.