<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
0D50Z00008S5O7DSAVOkta Classic EngineMulti-Factor AuthenticationAnswered2024-11-16T09:01:18.000Z2018-10-17T21:42:29.000Z2021-01-20T07:30:12.000Z

TomF.32212 (Customer) asked a question.

Prevent Account Lockouts from Brute Force Attacks

Hi everyone,

 

Since using Okta to protect O365 we have been detecting a lot of brute force password attacks. It appears that bots, from all over the world, are trying to log into O365 by guessing the users password. This is leading to the user and the Okta admin receiving lots of emails from Okta saying their account has been locked out due to too many failed login attempts.

While it is great that Okta is detecting and protecting against this, it is also becoming annoying for the user who is constantly getting their Okta account locked out and email alerts. We have set the Okta lockout threshold to 1 attempt lower that AD so the AD account never gets locked out.

When it started, I used Okta's 'Blocked Countries' feature to blacklist the countries it was coming from. Unfortunately the attacks appear to come from pretty much every country in the world now and this approach doesn't seem practical.

Does anyone have a better way to deal with this? We have MFA enforced and we use behavioral analytics, so the attacker will (hopefully) never gain access to the users mailbox. It doesn't stop them form attempting to guess the password and causing account lockout though.

 

Any advise would be appreciated.

 

Thanks,

Tom


SammyL.73262 and zsmos like this.
  • FredericoH.96978 (Customer)

    Hi Sammy, Ryan, and Tom,

    Hope everything is going well.

     

    Okta recently released a product feature – pre-authentication sign on policy evaluations – that helps applies the Sign-On policy before authentication.

    You can enable the feature on the feature manager (On the admin console, click Settings > Features, and switch on "pre-authentication sign on policy evaluations").

    Image: https://imgur.com/a/8QxVHes

    With the feature is enabled, all the existing Sign-On policies are evaluated by Okta before the password validation. After that, you can write sign-on policies to deny access.

    Another thing you can do is granularly deny suspicious access for specific users/groups, reducing the number of blacklisting rules you end up writing. Examples of Policies/Rules you can create:

    > Users from Brazil cannot login outside of South America.

    > Users from the Operations team cannot login outside the office. 

    Image: https://imgur.com/a/FkE871c

    The "pre-authentication sign on policy evaluations" mitigates lockouts on modern authentication to Okta (when the O365 login shows the Okta UI).

    For mitigating lockouts legacy O365 authentication (basic authentication over SMTP, POP, IMAP, and ActiveSync), you can create an Authentication Policy on O365, like Ryan suggested.

    Here's what I got from MSFT official O365 doc: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online

    To setup a new policy, you can use the following command (it automatically sets the policy without basic auth):

    New-AuthenticationPolicy -Name "Block Basic Authentication"

     

    Image: https://imgur.com/a/79NRgAT

    Then, you can use PowerShell to add one user to test the policy:

    Set-User -Identity <UserId> -AuthenticationPolicy "Block Basic Authentication"

    Set-User -Identity <UserId> -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

     

    If you like the results, you can to add more people to the policy (still on Powershell. This is another example from Microsoft:

    $Engineers = Get-User -ResultSize unlimited -Filter {(RecipientType -eq 'UserMailbox') -and (Title -like '*Engineering*')}

    $EngId = $Engineers.MicrosoftOnlineServicesID

    $EngId | foreach {Set-User -Identity $_ -AuthenticationPolicy "Block Basic Authentication"}

    $EngId | foreach {Set-User -Identity $_ -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)}

    Finally, you can set the new policy as the default for all the new users:

    Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Authentication"

    With that, all new users will end up in the new policy.

    Hope this helps. Ty,

    Frederico

     

    Expand Post
    Selected as Best
  • My name is Vasi from Okta Support and I'll be handling your case. 

    We do recommend to get in touch with Okta representative and ask for Adaptive MFA . This will help to protect yourself against Brute Force Attacks

     

    Hope this helps

     

    Expand Post
  • TomF.32212 (Customer)

    Hi Vasile,

     

    We do have Adaptive MFA and it gives us the ability to create sign-on policies based on context, such as location. These policies get applied after the user has logged in though. How do we use it to stop brute force attacks please?

     

    Thanks,

    Tom

    Expand Post
  • ChrisY.69621 (Customer)

    I have the same exact problem. So far Okta's response has been lack luster. They told me to reach out to Microsoft and ask about their security offerings. I hate to say it, but i going to evaluate o365's MFA and IDP per Okta's advice. Okta's IDP is great, but there are big holes are around it's security offerings and reporting.

  • zsmos (zsmos)

    We've been experiencing the same as well and would prefer a solution within Okta instead of needing to do policies in Okta and Office 365/AzureAD

  • ispgd (ispgd)

    I just want to add on to this. It is a real problem that Okta does not seem to offer a good solution for, as you cannot block login based on behavior. We also have been leveraging the Country Blacklisting, but now the LAT/LON database seems off as we are getting lockouts from Des Moines IA now, but the IPs are from countries all over the world.

     

    I will open a ticket for this specific issue, but please provide a valid direction for supporting Brute Force Lockouts.

    Expand Post
  • 6iga1 (6iga1)

    I've been going round and round trying EVERYTHING and nothing short of blacklisting every country on earth besides the US where we're located "sort-of works". But we can't do that because we have students and faculty in just about every country on earth and we can't just cut them off. Sign-on policies for the O365 app don't ever appear to come into play until AFTER you successfully log in which these bad actors obviously never do. Okta has told me to turn off our acount lockout policy giving the bad actors free reign to brute force attack, but that would put us out of NIST compliance and is not an option.

     

    So I just tried a Sign-in Policy to Okta that blocks based on behavior and I get "At this time, access cannot be denied if a behavior condition is selected". Why? What am I supposed to pick if not behavior? I guess this means another ticket to Okta.

     

    This is incredibly frustrating.

     

    Expand Post
  • 6iga1 (6iga1)

    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.

    Expand Post
  • SammyL.73262 (Customer)

    I'm with Ryan and Tom on this. I've been dealing with this for quite some time and IP blacklists are not the answer. That is unsustainable. Country blacklists are great as long as you don't have employees working in the countries specified in the country blacklist! Turning off IMAP, POP3 and ActiveSync via PowerShell simply decrease the number of attacks you get.

     

    The real answer is for Okta to fix their Authentication sign-on policies so that the rules in the policy are applied up front based on the source IP before the authentication against AD is attempted!

     

    The ability to blacklist connections from TOR exit nodes needs to be addressed as well.

     

    Thank you Ryan and Tom for getting me motivated to post this!!! 

    Expand Post
  • FredericoH.96978 (Customer)

    Hi Sammy, Ryan, and Tom,

    Hope everything is going well.

     

    Okta recently released a product feature – pre-authentication sign on policy evaluations – that helps applies the Sign-On policy before authentication.

    You can enable the feature on the feature manager (On the admin console, click Settings > Features, and switch on "pre-authentication sign on policy evaluations").

    Image: https://imgur.com/a/8QxVHes

    With the feature is enabled, all the existing Sign-On policies are evaluated by Okta before the password validation. After that, you can write sign-on policies to deny access.

    Another thing you can do is granularly deny suspicious access for specific users/groups, reducing the number of blacklisting rules you end up writing. Examples of Policies/Rules you can create:

    > Users from Brazil cannot login outside of South America.

    > Users from the Operations team cannot login outside the office. 

    Image: https://imgur.com/a/FkE871c

    The "pre-authentication sign on policy evaluations" mitigates lockouts on modern authentication to Okta (when the O365 login shows the Okta UI).

    For mitigating lockouts legacy O365 authentication (basic authentication over SMTP, POP, IMAP, and ActiveSync), you can create an Authentication Policy on O365, like Ryan suggested.

    Here's what I got from MSFT official O365 doc: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online

    To setup a new policy, you can use the following command (it automatically sets the policy without basic auth):

    New-AuthenticationPolicy -Name "Block Basic Authentication"

     

    Image: https://imgur.com/a/79NRgAT

    Then, you can use PowerShell to add one user to test the policy:

    Set-User -Identity <UserId> -AuthenticationPolicy "Block Basic Authentication"

    Set-User -Identity <UserId> -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

     

    If you like the results, you can to add more people to the policy (still on Powershell. This is another example from Microsoft:

    $Engineers = Get-User -ResultSize unlimited -Filter {(RecipientType -eq 'UserMailbox') -and (Title -like '*Engineering*')}

    $EngId = $Engineers.MicrosoftOnlineServicesID

    $EngId | foreach {Set-User -Identity $_ -AuthenticationPolicy "Block Basic Authentication"}

    $EngId | foreach {Set-User -Identity $_ -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)}

    Finally, you can set the new policy as the default for all the new users:

    Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Authentication"

    With that, all new users will end up in the new policy.

    Hope this helps. Ty,

    Frederico

     

    Expand Post
    Selected as Best
10 of 17
This question is closed.
Loading
Prevent Account Lockouts from Brute Force Attacks