Forum Discussion
Failed log on (Failure message: Account is locked because user tried to sign in too many times with
My company has been experiencing an attack from China IP addresses (random) for a while and I can't seem to block them. I'm getting these errors "Failed log on (Failure message: Account is locked because user tried to sign in too many times with an incorrect user ID or password)" every few days on a few of my privileged users.
I've tried
Turning on Modern Authentication
In Azure AD Enabled Block legacy authentication
Turned off POP and IMAP access via exchange admin
Turned on MFA for the privileged users
The redacted (with *) source app connector data is below, I'm wondering if there is a way to block OrgIdWsTrust2:process or Unknown(CBAInPROD). Or if there is something else I can block to stop this.
Thanks for your help!
{
"UserName": "",
"MfaResult": null,
"DeviceInfo": "Unknown(CBAInPROD)",
"LoginErrorCode": 50053,
"DeviceTrustType": "",
"IsInteractive": false,
"Call": "OrgIdWsTrust2:process",
"LoginStatus": "Failure",
"MfaMaskedDeviceId": null,
"IpAddress": "182.38.105.229",
"UserTenantId": "****",
"EventType": "MCASLoginEvent",
"IsInteractiveComputed": null,
"ApplicationId": "***",
"CorrelationId": "***",
"ApplicationName": "Office 365",
"SasStatus": null,
"TimeStamp": "2019-07-02T01:11:36.4486831Z",
"HomeTenantUserObjectId": "***",
"MfaRequired": false,
"RequestId": "***",
"TenantId": "***",
"MfaAuthMethod": null,
"MfaStatusRaw": null,
"IsDeviceCompliantAndManaged": false,
"BrowserId": null,
"UserTenantMsodsRegionScope": "NA",
"DataSource": null,
"UserPrincipalObjectID": "***",
"Upn": "***",
"MsodsTenantRegionScope": "NA"
}
I have the same issue.
Did you get anywhere with a proper answer or solution ?
I have daily more than 500 login tries from China, US, Thailand etc. with failed login using IMAP.
Failure reason "Account is locked because user tried to sign in too many times with an incorrect user ID or password."
IMAP disable in exchange and Block Legacy Cond. Access is applied, how can I tell if we are not in trouble if I still get 50053 error when service is disabled ?
thank you
LilleLars As @Vasil Michev said the CA policies are only being applied AFTER succesful authentication through basich auth protocols (POP3, IMAP, SMTP, etc.). That's why you're seeing this behaviour.
To eliminate these spray attacks you need to disable basic auth in Exchange Online. Please have a look at the following article on how to do that: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online
Thank you Pavel, im testing now and this tenant did not have any "authentication policies" already.
Ive done this:
New-AuthenticationPolicy -Name "Block Basic Auth"
Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Auth"gives me below result which looks good.
I´ve waited 10 hours and stille I see IMAP error 50053 "account is blocked" in the Sign-ins log
Hope I did it correct?
AllowBasicAuthActiveSync : False
AllowBasicAuthAutodiscover : False
AllowBasicAuthImap : False
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook : False
AllowBasicAuthOutlookService : False
AllowBasicAuthPop : False
AllowBasicAuthReportingWebServices : False
AllowBasicAuthRest : False
AllowBasicAuthRpc : False
AllowBasicAuthSmtp : False
AllowBasicAuthWebServices : False
AllowBasicAuthPowershell : False
Are you looking at the MCAS logs? Those arrive with some delay, best check directly against the Azure AD sign-in logs. The settings you've configured should be enough to prevent this type of attack, which is usually brute-forcing credentials via POP/IMAP.
VasilMichevThank you for the follow up. Yes I am seeing the logs in MCAS, unfortunately we do not have a premium Azure AD subscription so I can't see the logs in there.
From my reading I thought is was through POP and IMAP as well but I've disabled that in the exchange mail boxes. Is there somewhere that needs to be set?
Even without AAD Premium, you can see it on the corresponding user object's details page.
Disabling POP/IMAP will not affect these entries, blocking legacy auth should however, so check whether you missed something on that front.
