We have several questions related to the information contained in the following portion of the KB article related to Conditional Access (e.g. "when is a location evaluated"):

docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-locations#when-is-a-location-evaluated

Question #1:
As described in the KB article, it appears that a user logon attempt from a blacklisted location such as "China" would be blocked, but only AFTER the user's credentials (username + password) were accepted as valid.

How is this an acceptable control considering the following scenario?:

A user's Azure account originates from an on-premises Active Directory. Their password is synchronized to Azure, providing SSO for the user. A bad-actor from "China" can repeatedly attempt logons against their Azure account until they succeeded. The "Azure Conditional Access" policies would of course block their access to any Azure-based resources, but the bad-actor would know at that point that they'd successfully logged on. Considering that it is trivial for someone to determine the IP addresses related to an Azure tenant's "on-premises" Active Directory domain, what's to prevent this bad-actor from accessing the compromised user's on-premises Active Directory account? Even if the on-premises Active Directory's related firewall was blocking remote access attempts from "China", a VPN service would be easy to use in order to get around any geographic conditional access rules at the on-premises firewall.

Our question for the development team is:

Why can't the "Azure Conditional Access" policies be applied to the Azure portal logon screen itself in order to prevent a logon "attempt" altogether? We know that Azure evaluates the UPN suffix of the user in order to deliver them to a branded/customized logon portal page. Why can't the combination of the user's UPN suffix along with the client's browser-IP address be used to evaluate an "Azure Conditional Access" policy (at the tenant level) in order to prevent a potential bad-actor from even being able to proceed to the point of entering a password in order to complete a logon attempt?

As things operate right now, a bad-actor is able to perform one logon attempt after another against an Azure account regardless of any Conditional Access policy. Because of this we're seeing that some of our accounts are being locked out by these bad logon attempts. Can Microsoft address this problem?

Question #2:
It appears that ALL Azure user accounts (regardless of licensing) can be affected by (benefit from) an "Azure Conditional Access" or "Azure Identity Protection" policy. Our testing with accounts with either a plain "E3" license, an account with an Azure P1 license and an account with an Azure P2 license are all identically affected by (benefit from) these policies.

Can you confirm that when Microsoft's documentation refers to the licensing requirements to utilize either "Azure Conditional Access" or "Azure Identity Protection" policies, it merely means that an "Administrative" user would need to have either an "Azure P1" or an "Azure P2" license in order to "configure and apply" these policies? Meaning, an "Azure P1" or an "Azure P2" license would NOT be required for each and every regular user?

Thank you for your time!