6iga1 (6iga1) asked a question.
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?
We finally hit upon something that works, but are still deciding if we can make this default in our Office tenant (and turn it back on for users who request it and certain service accounts that require it) or if we are just going to turn this off upon request. It seems the vast majority of our account lockout problems are originating from legacy SMTP Authentication requests (only POP and IMAP appear to use this, as shown in this very recent article):
https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online
We tested this in real time by finding a user getting hit every 15 seconds and flipping SMTP Auth off. The attacks stopped almost immediately. We then turned it back on and the attacks resumed. To do this on a per-user mailbox, you connect to your Office 365 tenant via PowerShell and run this command:
Set-CASMailbox -Identity user@domain.com -SmtpClientAuthenticationDisabled $true
You can also turn off SMTP Auth globally via a transport rule, then re-enable on a per-mailbox basis if needed.
Just turning off POP and/or IMAP in the Office 365 admin GUI doesn't turn off SMTP Auth, we found we could actually leave them on and just disable SMTP Auth (not sure why you would want to do that but it did explain why turning off POP and IMAP in the GUI didn't get the results we wanted).
No guarantee this is totally effective, but it's definitely stopping the bulk of our lockout problems for the mailboxes we have tested on, at least for the time being.