While trying to log in to Microsoft 365 with OAuth2, some customers are getting this error code, although the username and password is indeed correct.

This is because this error code appears to be returned for another error situation which is not related to the password that the user entered.

No matter the actual cause of the error, it is crucially important to properly pinpoint the actual cause of the error, so that the software can respond correctly. Different error cases need different responses from the software.

From the client software side, the perspective of a client software developer, we must unambiguously distinguish between a) an actually invalid password, where the user entered the wrong password, and b) some technical problem or incompatibility with the domain setup. The reason why it's crucial to differentiate is because the error recovery is very different. In the first case a), I tell the user that his password is wrong and he needs to enter it again. In the second case b), I either do some fallback code or tell the user that I cannot support his account. If I pick the wrong case, because the error code I get is wrong - as in this case -, then I'll keep asking the user to re-enter the passwords, which is completely useless, confusing, and might even lead him to enter other passwords, which is dangerous. In any case, it's a really bad end user experience.

The documentation for this error code AADSTS50126 specifically says that this error code means that is an invalid password. However, we see this code when the password is correct, so the error message is flat out wrong. In most configurations, the error code is returned correct, and really only for wrong passwords, but not in all configurations.

This causes serious problems for software trying to authenticate, because the software cannot know whether to ask the user to re-enter the password, or use fallback code to use another authentication path.

There's no way for us to fix this properly. The bug here is simple: The Microsoft servers return the wrong error code and message. The error message and code are flat out wrong. A MS developer was just re-using the wrong error code, instead of creating a new error code as he should. This must be fixed in the Microsoft software. That's the only place where it can be fixed.

This leads to hurt and setup pains for end users. Please fix it.

Many people ran into this. Please see comments and more details on
https://github.com/MicrosoftDocs/azure-docs/issues/30802

We are using Azure VPN client with Azure MFA, and the client requires the second factor (code via SMS) only when the user connects for the first time. After that, every time we click on the VPN icon, the VPN client connects automatically, ignoring the MFA requirement, even if we log off the user or turn off the PC. It seems that, after the first authentication with MFA, the client turns into a "one-factor authentication" access, requiring only userid and password. If someone obtains the Windows credentials for a user, an attacker with access to the laptop can connect remotely to the VPN using only the Windows credentials, what does not look like a secure solution for remote access. We would like to see a behavior more like other VPN solutions, where users have to enter the second factor every time they connect to the VPN. Thank you.

Currently Azure Active Directory is locking Office 365 user accounts based on the number of failed sign-ins. If the user credentials are entered incorrectly, it does not check or verify existing Azure Conditional Access Policy, whether this account can sign-in from that location (Country or IP address) or not, because the authentication was not successful.

To prevent Azure AD account lockouts, can you design the Modern Authentication system in Azure AD to check for existing Azure Conditional Access Policy for failed logins coming from blocked locations (Country or IP address)?

This will help Office 365 Admins prevent account lockouts, sourced from known brute force attack locations.

Need Payment history and total outstanding per subscription.

As a subscriber I can only see invoices at azure, but there is no payment history which tells me how and when azure has captured this payment.

It is our legal right to see the payments captured by AZURE. Tomorrow AZURE go and capture another payment from my card how I will reconcile which payment is for what.

If you are taking payment then you must show somewhere that we have captured this payment via this way against this invoice or for this purpose.

Also there is no way I can see what is my total outstanding. Say my card expired so what happened actually I must know.

If you are hiding payments then how I will come to know whether you are charging me double or any other fraud is happening with me.

Regards
Alok

properties: {

    title: This storage account was throttled because it exceeded Azure Storage partition request per second, partition bandwidth, or IP scalability limits.,

    details: null,

    currentHealthStatus: Degraded,

    previousHealthStatus: Available,

    type: Downtime,

    cause: UserInitiated

},

==========================

Storage account throttling can be caused by busy storage partitions on the server side which is not related to customers' usage.

The "UserInitiated" wording in the health event cause would lead to misunderstanding of reaching service limit when customers' traffic is not there yet. Maybe we can change the wording to "ClientInitiated".

More specific alert cause can help both customers and support team to identify the issue efficiently.

• Instead of “UserInitiated”, we should change the wording to “Responding with Errors” or “ClientInitiated” in this scenario.
• We should not provide a list of possible throttling errors. If we are able to identify the specific type of throttling that occurred. We had better to directly provide customer-ready contents to the client side.

Thank you.