Does Error 50053 Override Conditional Access Rules and Expose Passwords?

Question

As a follow up for further clarification questions related to the Microsoft provided answer on this post: Login attempts using Password Hash Sync

Can you clarify whether the error message "Sign-in was blocked because it came from an IP address with malicious activity" (error 50053) takes precedence over any conditional access rules you have set up, such as those blocking all legacy authentication protocols within Conditional Access Policies specifically?

If this is the case, the logs associated with this error might be misleading or concerning. Specifically, the "Authentication Details" logs show a failed Password Hash Sync attempt with a 'Result' of 'incorrect password'.

A key question is: If Microsoft identifies certain IP addresses as malicious and blocks them, why do the logs still indicate a password mismatch for SMTP Authentication attempts?

Why: If an authentication attempt is blocked due to malicious IP addresses but still reaches the authentication mechanism, and the system provides output results distinguishing between correct and incorrect passwords, this could expose valid passwords to attackers.

Even if a correct password guess is blocked, confirming valid passwords through such output can still enable hackers to exploit other vulnerabilities to try to gain access once they guessed it correctly. Thus, the block is not fully effective against brute-force attacks if this is the case as the logs indicate.

Answer 1

Hi @PJ Mahoney ,

The message "Failure reason Sign-in was blocked because it came from an IP address with malicious activity" will be displayed only after correct password is entered from a malicious IP address.

Conditional Access policies then apply after the user enters credentials. This is because Azure needs to identify who the user is first in order for the policies to apply. The user will need to authenticate first and then the Conditional Access policy will allow or block the user based on the conditions that you have set. This is noted in the Conditional Access guide as well:

Conditional Access policies are enforced after first-factor authentication is completed. Conditional Access isn't intended to be an organization's first line of defense for scenarios like denial-of-service (DoS) attacks, but it can use signals from these events to determine access.

After the login with username and password, the user is prompted for an additional form of identification via Conditional Access policy.Let me know if this addresses your question.

If the information helped address your question, please Accept the answer. This will help us as well as others in the community who may be researching similar questions.

Answer 2

Does Error 50053 Override Conditional Access?

No, events causing error 50053 do not override Conditional Access Policies, but smart lockout has precedent to block before the conditional access policies even apply. This error is part of Microsoft's proprietary algorithm and is associated with smart lockout mechanisms. Type error codes in: https://login.microsoftonline.com/error for more detail.

Furthermore, answers regardless of who it is that they come from specifying that you will only see "sign-in was blocked because it came from an IP address with malicious activity" is flat out wrong and very misleading per the way this works today August 2024.

Does Error 50053 Expose Passwords?

No, events related to error 50053 do not expose passwords. While allowing SMTP authentication could potentially expose passwords if a brute force attack is successful, smart lockout helps mitigate this risk.

If you need to enable legacy SMTP authentication and cannot disable it tenant-wide/globally, consider disabling the protocol on a per-account basis. This allows you to maintain legacy authentication only for the accounts that require it, while implementing a Block Legacy Authentication policy to restrict access appropriately.

Supporting Resources

• Clarify what 50053 really means
• Error code 50053 description #76807

View All M365 Authenticated SMTP Connections Report

• Navigate: Exchange Admin Center | Reports | Mail flow | SMTP AUTH client reports

List Account Specific SMTP Authentication Status (and disable per account)

Disconnect-ExchangeOnline -Confirm:$false; 
Try{Get-Mailbox $env:USERNAME}Catch{Connect-ExchangeOnline -UserPrincipalName "$(whoami /upn)"}; 
Get-CASMailbox -Identity "user1@domain.com" | 
	Select-Object Identity, SmtpClientAuthenticationDisabled;
Set-CASMailbox -Identity "user1@domain.com" -SmtpClientAuthenticationDisabled $true;

Disable SMTP Authentication Globally

Disconnect-ExchangeOnline -Confirm:$false; 
Try{Get-Mailbox $env:USERNAME}Catch{Connect-ExchangeOnline -UserPrincipalName "$(whoami /upn)"};
Set-TransportConfig -SmtpClientAuthenticationDisabled $true;