<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
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D50Z00008S2l1qSABOkta Classic EngineMulti-Factor AuthenticationAnswered2024-04-17T09:29:12.000Z2018-10-08T16:24:06.000Z2018-11-14T19:59:55.000Z

idcp0 (idcp0) asked a question.

October 8, 2018 at 4:24 PM
Brute force locking out accounts.

Good Morning,

 

I'm seeing brute force attacks for various people in out company, and the problem is the IP's are constantly changing, which causes accounts lockouts.

 

I'm curious what other people are doing to prevent this?

Below is a list that we have tried which helps, but does not resolve the issue.

 

Prevent AD accounts from locking out while locking out Okta

Using Zones to prevent access from certain geographical locations.

Manually add IPs to block logged attempts.

 

Please note:

Manually adding IPs is manual and is constantly changing.

Zones does not work for multinational companies that have offices in that location. It is applied at the Organization level and not group level.

 

The suggestion I was given was to manually add the IPs to block them, but I feel there has to be a better way to this.

 

Perhaps I maybe missing features like -

Does Okta have a captcha if x amount of password tries have been attempted?

Does Okta have a soft IP block for x x amount of password tries have been attempted?

 

Please let me know if there is something i missed in this list.

*Frustrated Admin*

  • 8 answers
  • 5.38K views
d9bj6, adminj.24061, and 3 others like this.

  • 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
    Selected as Best

  • fooheantee (Customer)

    same issue here.

    Previously the attack came from 1 or 2 IP Address, then since last week, the attack evolve with different IP addresses.

    Camping here to see if there's any solution from OKTA or other community members.

  • idcp0 (idcp0)

    I was just in another thread, and was discussing another workaround actually, which I am not sure why it is not implemented in Otka which was Captcha.

     

    I still haven't found the time to dig deep into it but it looks like you can implement this using:

     

    Utilizing custom widgets in Okta - https://developer.okta.com/code/javascript/okta_sign-in_widget

     

    and then using reCaptcha v2/v3 - https://developers.google.com/recaptcha/docs/v3

     

     

     

     

     

    The problem is that I believe the captcha is always shown. This should be a standard feature that could be configure as x/2 where x is the defined lockout thresholds.

     

     

     

     

     

    Just random thoughts.

    Expand Post

  • idcp0 (idcp0)

    I just wanted to update my findings since I am answering my own question.

     

    TLDR;

     

    In short, we do not have the option of captcha from Okta, out of the box.

     

     

     

     

     

    This solution did not work for us because it required the implementation of customized url.

     

    (https://help.okta.com/en/prod/Content/Topics/Settings/custom-url-domain.htm)

     

     

     

     

     

    The limitation of using a customized url:

     

    Okta Mobile for iOS. (Custom URLs are supported on Android devices running Okta Mobile for Android version 3.8.0+.)

    Okta Secure Web Authentication browser plugin

    Okta IWA web app for Desktop SSO

    Okta Active Directory agent

    Okta LDAP agent

    However, I used a test domain and was able to implement the widget as far as having it show up, but I needed a server to hold my private key to send and confirm the recaptcha actions (This is as far as I understood).

     

    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.

  • 6iga1 (6iga1)

    I believe a Captcha in any case would not be effective. If you dig in to your logs, you'll likely see that these failed attempts are wsfed/active (legacy auth). I have opened several tickets to no success. The most effective course of action was to block every country except the US where we're located, but this was turned off because to many students and faculty traveling abroad were affected. That slowed up the invalid attempts since only US based attempts made it through. Client Access Policies for specific apps never get evaluated until after you successfully log in (which these bad actors never do). And Okta doesn't appear to currently support a blanket Sign-in policy based on behavior detection ("At this time, access cannot be denied if a behavior condition is selected" error message trying to create). Frustrating to say the least. Open to any ideas although I think I've heard them all and none are viable.

    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
    Selected as Best

  • idcp0 (idcp0)

    I haven't been keeping up outside the realm of work.

     

    I can confirm Ryan's last post.

     

     

     

    Last week,, we had turned off pop3 and imap, and while it did solve a number of attacks we saw, there were still attacks coming in. My exchange admin took the initiative and turned off SMTP Auth and said the attacks have died off. There are still a couple accounts they may need more attention to resolve, but the bulk of the attacks seem to have died out.

     

    For those that are using Okta and Office 365, and are trying to combat this issue as well (also refer to Ryan's post as well!),

     

    Turn off (legacy authentication) if you can -

    POP3

    IMAP

    SMTP

     

    Also soft lock is definitely worth looking at.

    https://support.okta.com/help/s/article/How-does-the-password-policy-soft-lock-functionality-work

     

     

     

    Expand Post
This question is closed.
Loading
Brute force locking out accounts.