Each and every built-in role has a specific definition at a specific time and it will gets changed as the new features are available. Does Microsoft logs these kind of activities under azure activity log if there is a change to the built in definition in the future? Or is there a place that we could subscribe it to get these changes?

For building Custom role, we general copy a specific role definition that closely matches to on what we want to accomplish, from time to time, this built-in role definition will gets changed and all the custom roles that were created from this will be obsolete. It would be nice, if MS provides some kind of tracking to the built in role definition changes!

Password aging is one of the basic requirement for LDAP user management. Since this feature is missing it is creating Non compliancy in audit on how users data are stored and managed within Azure AB B2C. Please treat this as an enhancement request so that this feature is available within Admin GUI and following parameters can be set.

1: MAXIMUM PASSWORD AGE

• Passwords must expire after a maximum of X days (ex: 90).
• Users should receive system prompts in advance of this expiry date to remind them that their password is due to expire.
• If a user attempts to logon with an expired password within a 10-day grace period the system should permit access, but only after forcing the user to change their password.
• After the expiry of the 10-day grace period, the expired password should not work, and needs Admin intervention in reinstate the access .

2 MINIMUM PASSWORD AGE

• Passwords must have a minimum duration set of 1 day. This is to prevent users cycling passwords back to their old password (by running out the password history).

We are using New-AzureRMSubscription to automatically create subscriptions. After creation we see that the Account Owner is made Service Administrator of each subscription that is created via this way.
There is a risk that, when the credentials of this account owner are confiscated, the attacker takes over control, as service administrator/ (service owner), of all the subscriptions.
This risk can be mitigated by having the possibility to assign a different identity as service administrator for each subscription created.
If we create such an subscription via the enterprise portal, we already have the possibility to assign a different identity as service administrator.
It wwould be of great importance to us when we also have the same possibility to specify a different identity as service administrator when using the API's.

We are looking for a Global Router Solution for Billing-Sensitive API Use Cases and we worked with multiple parts of Azure support (namely Front Door, Azure API Management or APIM, as well as Networking) to check whether our use case is supported.

We found out, working with multiple support teams that such use case is not really supported right now and we were strongly encouraged to submit this idea as soon as possible on this feedback forum for potential review by the global community and the respective Microsoft teams. (Initially submitted on this forum, as of 7/21/2020)

In current model as of July 21, 2020. rules blocked by WAF in Azure Front Door charge the inbound rate even if the WAF rule blocked it. This is because the request is passing through Azure Front Door + WAF as one single unit for the purposes of billing. This is similar to how Azure CDN and all other global Layer 7 routing solutions Azure has currently works and bills when they are at the global level. This is confirmed by Azure Support as of 7/21/2020.

Either by changes or features in Azure Front Door, or via another way, this idea submission requests the implementation of a global router functionality that does not charge for inbound traffic that is blocked at the "edge" or perhaps a better term with be the "rules" level. In other words, functionality to support rules that if/when they define a block or deny state, that inbound ingress (especially) is not charged, and preferably not the egress either if possible for the blocked traffic triggered in this way (perhaps with option of a mode whether to respond to the connection, which would incur a small charge, or not respond at all, which would incur no charge. This idea submission is focused more on just the version that would not respond to the connection at all, as existing functionality in current products already processes and bills all requests and returns responses already all the time as-is – however, this nuance is mentioned in case it could still be relevant for this kind of functionality to offer the option of the two at that level of the rule ).
Also, we would prefer not charge by how many times the rule was triggered per period, instead we would rather prefer to pay for each definition of these kinds of rules themselves on a per rule per hour basis or something like that (however, hopefully a reasonable pricing either way).
The preferred way of blocking this kind of traffic would be to have the option to simply hang the connection and not return a response if possible (sort of like NSG's can do at the Virtual Network level, except to apply this at the top global level somehow), since existing functionality already can block and return a response e.g. APIM policy, even to some extent Front Door rules, etc. It is desired that this specific kind of "blocking" actually be somewhat similar to perhaps the way NSG's block traffic on Virtual Networks (for example) that don't match an NSG allow rule or that matched an NSG deny rule - the infrastructure just doesn't return any response at all and there is nothing that processes the request directly when the rule doesn't match. This is for purposes of only high level illustration and this specific example may or may not be based on exact specific working models of current Azure products, and we do not necessarily imply a specific implementation methodology in this idea submission, this specific paragraph would be intended more as a general conceptual reference and there could be likely more than one approach here.

There is more to this idea but it exceeds the description max length - the full idea is attached here as a text file.

Thanks for considering this idea.

The Discover service tags by using downloadable JSON files links go to Microsoft.com download pages. These pages initiate downloads of files with a different name for every update.

This is not useful for staying up-to-date with the service ranges. Either a human has to go click on the downloads, or some screen-scraping tactic needs to be used to get the actual file location.

Better would be to link to a URL that always has the latest JSON file.

The REST API is not a useful alternative, as "the Discovery API might return information that's less current than information returned by the JSON downloads."

https://github.com/MicrosoftDocs/azure-docs/issues/52181