Forum Discussion
Dealing with high number of failed log on attempts from foreign countries utilizing Exchange Online
- Dec 21, 2018
Not sure if any one has seen this. There is a new tool for your basket. This has helped us greatly.
A couple of months ago Microsoft released to preview and then has pushed forward 'Authentication Policies'.
These authentication policies are processed prior to being passed to AAD or ADFS saving the failed login against the account
And yes this can be applied to individual or small groups to test first (just remember to wait to assure the policy is applied to the user in question before calling it good or not)
See "https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online"
Basic outline
Assure you have modern authentication enabled for your organization
Create an authentication policy blocking basic auth for pop, imap and such (The biggest one we were seeing was imap)
If you have any user or service accounts that requires basic auth for any of the protocols you are disabling in the previous policy, create a second policy allowing the protocols
If you have any users that utilizing pop, imap or any other method you determine don't need basic authentication, get them migrated to some other form of client app or access
If there are any accounts that absolutely require basic auth (ie we have a ticketing system that utilizes imap with basic auth to connect to a specific mailbox), make note of them to exclude in your query for users to apply your restricted policy to
Query for and apply unrestricted policy to service account or user that requires the basic auth for the protocols disabled by the restricted policy
Query for and apply restricted policy to the majority of your users
Apply restricted policy as global default (for new users)
Either wait 24 hours for it to be applied or touch a user property on the user and wait approximately 30 minutes.
Note, the below worked for me. Make sure you research and adjust for your own needs. I take no responsibility for what you do to your environment. These are only examples
Exchange Powershell commands used
connect-exopssession -UserPrincipalName {exchangeonline admin}
New-AuthenticationPolicy -Name "Block_Basic_Auth_Selective”
{Blocks basic auth for imap, pop, smtp but allows for things like activesync}
(Adjust according to your needs)
Set-AuthenticationPolicy -Identity “Block_Basic_Auth_Selective” -AllowBasicAuthActiveSync -AllowBasicAuthAutodiscover -AllowBasicAuthImap:$false -AllowBasicAuthMapi -AllowBasicAuthOfflineAddressBook -AllowBasicAuthOutlookService:$false -AllowBasicAuthPop:$false -AllowBasicAuthReportingWebServices -AllowBasicAuthRest -AllowBasicAuthRpc -AllowBasicAuthSmtp:$false -AllowBasicAuthWebServices -AllowBasicAuthPowerShellNew-AuthenticationPolicy "Allow_Basic_Auth"
(Adjust according to your needs)
Set-AuthenticationPolicy -Identity “Allow_Basic_Auth” -AllowBasicAuthActiveSync:$true -AllowBasicAuthAutodiscover:$true -AllowBasicAuthImap:$true -AllowBasicAuthMapi:$true -AllowBasicAuthOfflineAddressBook:true -AllowBasicAuthOutlookService:$true -AllowBasicAuthPop:$true -AllowBasicAuthReportingWebServices -AllowBasicAuthRest -AllowBasicAuthRpc -AllowBasicAuthSmtp:$true -AllowBasicAuthWebServices:true -AllowBasicAuthPowerShellTo simplifiy things for my environment I manually set the users that required basic auth (I only had two)
set-user -Identity "User One" -AuthenticationPolicy "Allow_Basic_Auth"
To touch the user to make the policy get applied quicker
set-user -Identity "User One" -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)
For the rest of my users
$Users = Get-User -ResultSize unlimited | Where {$_.RecipientType -eq "UserMailbox" -and $_.AuthenticationPolicy -eq $null}
$users =$users.WindowsEmailAddress
$users | %{Set-User -Identity $_ -AuthenticationPolicy “Block_Basic_Auth_Selective”}
If you want to touch the users to apply policy quicker, since the query is already in memory
$users | %{Set-User -Identity $_ -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)}
Now the following command will apply the restricted policy as the global default. (Note, when I first implemented this, the unrestricted users did not have a policy applied and as such I thought they would have no policy applied, but once the default policy was applied to the global config, it affected the unrestricted unconfigured users.)Set-OrganizationConfig -DefaultAuthenticationPolicy “Block_Basic_Auth_Selective”
Remember, mileage will vary. Read everything you can find on Authentication Policy/iesFor us, for now, this has completely removed the issues we were having with illigitimate failed login attempts and account lockouts.
We ran into only the one issue mentioned above with the accounts that had no policy assigned and then the global policy being appliedRemember, it takes approximately 24 hours for the policy to be applied to a user unless one of the user's properties are modified
There is one thing I will mention, at this time, when this is applied, there is nothing logged for failed attempts that fall afoul of the blocked basic auth policy even in Azure Ad Sign-ins
-Gene
First of all, look at the AD FS extranet lockout feature: http://blogs.technet.com/b/rmilne/archive/2014/05/05/enabling-adfs-2012-r2-extranet-lockout-protection.aspx
For the protocol info, you can get some hints from the claims included in the AD FS events. Even audit failures contain some of the data, so look not only for 411 but the accompanying 403/410 events.
MFA is certainly an option, you dont need to use a company-sanctioned mobile device to use it.
and to add to what Vasil mentioned, ensure you have the lockout feature configured correctly:
https://blogs.msdn.microsoft.com/luzhao1/2015/06/24/demystify-extranet-lockout-feature-in-ad-fs-3-0/
Its also worth repeating that MFA only protects you against a compromised password, not from anyone attempting to make attempts and eventually locking the account. If the extranet lockout feature is enabled, external accounts can still be "soft-locked" out of their accounts until the extranet observation window passes. So what you are really protecting is the internal AD lockout.
I would also consider using a 3rd party product such as SpecOps https://specopssoft.com/product/specops-password-policy/ which can help enforce complicated passwords to a greater extent that what is built-in to AD.
- Eugene PinsonAug 02, 2017Copper Contributor
My apologies, thought I had mentioned that they are doing it sporadically enough it isn't triggering extranet lockout and it is enabled and configured. For the most part, they are spreading the logon attempts to one every 5 or 6 hours (only 4 sometimes 5 attempts a day). So even with my extranet lockout set at 5 they are flying under the radar. (badPWDcount resets to 0 on successful login from the user throughout the day)
-G
- Andy DavidAug 02, 2017MVP
So you are unable to surface the real IP addresses of the offending client via ADFS? Thats what we do.
- Eugene PinsonAug 02, 2017Copper Contributor
Oh yeah. That's how I have been able to determine it has been going.
Twice a day I go through and hunt for the 411 event ID's, export them as xml perform a couple of quick filters in excel, save as csv then use a couple of find replaces in notepad++ to get it into a usable state.
Then parse the IP addresses presented using geoiplocation command in linux shell to determine location.
Unfortunately, it doesn't really give me a way of trying to deal with it.
It looks like we may be going down the MFA route here in the near future to minimize possible account compromise. Although their are still a couple of issues we are running into, like powershell access to security & compliance center, but this really only affects admins, then there appear to be a few issues with mobile powerapps.
-G