likely been active since the inception of these capabilities
wonder if the recommendation to "add randomness to resource names" is because of this (unrelated security by obscurity lol)
I am talking about the most basic capability of a professional presentation tool like exists in Webex, or GotoMeeting or Zoom. And requested...
https://learn.microsoft.com/en-us/answers/questions/4410610/...
by more than 2000 requests across different microsoft discussion boards, including 1044 on one request alone....
Federal Cyber Experts Thought Microsoft’s Cloud Was “a Pile of Shit.” They Approved It Anyway.
https://www.propublica.org/article/microsoft-cloud-fedramp-cybersecurity-governmentWell, when you're already paying Microsoft $/user/month for Intune, Teams&co. you might as well use Azure too.
Only one vendor relationship to manage, and I suspect you probably have to spend far less money than you do with AWS to get some personal attention.
Anyone that's had to deal with Microsoft will tell you this means nothing
If you can even get attention from someone, you'll be bounced between teams and people who barely know the products they are "supporting"
Don't get me started on the Azure and O365 management portals
The only worse support experience I've had was with Oracle where it could take days just to get the boilerplate "send us your logs" response on a Sev1 issue, despite the logs already being provided in the initial ticket
In both cases, this is while at F100 companies with millions of dollars of licensed software and premium support contracts
In relation to everything you said in your post, let's just say "trust me, I know".
But you missed the point I was making.
The GP said "Makes me wonder why enterprises still flock there".
And anyone who's had to deal with enterprise procurement knows if you've got a vendor on the list then its easier to deal with that one than push for multiple.
And then there's the whole budgeting thing. If management can see you're already buying every single employee in the org a Teams license, then getting extra budget for some Azure toys will probably be an easier sell then "yeah, I know we're paying Microsoft a lot of money, but can we have some AWS too". Since in their eyes Azure and Teams licenses is the same thing, "money for Microsoft".
Sadly the tech desk experience in enterprises tends to fall low down the list, if it is considered at all.
Sure, in theory, if you've got a good CTO to fight your corner then YMMV, but not everyone does.
Attention means an engineer who can fix the problem, not an off shore phone jockey paid to make you quietly go away.
With Microsoft that takes several people working full time. Corporations tend to not want more of those relationships to manage.
If anything, having only one vendor to choose from is a disadvantage.
Amazon doesn't and regardless nobody feels comfortable using Google, who knows when they'll discontinue a product we would rely on.
So not a lot left to choose from.
/s
Should have been addressed in the Geneva conventions.
[2026-10-02]
beginning of curent month feels like two years ago when multiple vulns drop daily
"… then put your little hand in mine…"
Reporting “theoretical” issues with validation as an Employee gets you a lot of questions as to why you were looking.
Oh well.
Microsoft still has employees ? ;)
(Sorry. Low bar. But in all honesty I thought they outsourced the majority of ops. I was surprised to hear in recent news that they actually had that many employees left)
That explains a lot.
Microsoft had an egregious cross-tenant vulnerability (really, how many cross-tenant vulnerabilities did other clouds have?).
Vulnerability was reported.
They fixed it - incorrectly. Reported again.
They fixed it this time... and broke the previous fix. So it's vulnerable again.
What a clown show.
[2026] Erosion of Trust @ Azure
https://news.ycombinator.com/item?id=47616242
https://isolveproblems.substack.com/p/how-microsoft-vaporize...
[2026] https://www.microsoft.com/en-us/security/blog/2026/05/18/sto...
[2025] https://www.cisa.gov/news-events/alerts/2025/07/20/microsoft...
[2025] https://www.securityweek.com/all-microsoft-entra-tenants-wer...
[2024] https://www.cloaked.com/post/microsoft-data-breach
[2023] https://www.reuters.com/world/us/chinese-hackers-stole-60000...
[2023] https://www.wiz.io/blog/storm-0558-compromised-microsoft-key...
[2022] https://www.spiceworks.com/it-security/cloud-security/news/m...
[2022] https://techcrunch.com/2022/03/23/microsoft-lapsus-hack-sour...
[2021] https://www.cpomagazine.com/cyber-security/microsoft-power-a...
[2021] https://www.darkreading.com/cloud-security/microsoft-azure-c...
And this is just the Azure / O365 stuff - there's been thousands of Windows client/server and Office software exploits across the same time period
The callback you're redirecting the user to at the end of that flow is forgeable if an attacker knows an azure tenant ID of a different customer, and putting a "Never use the tenant ID value of the tenant parameter to authenticate or authorize users" warning in the docs is only helpful as long as a way to authenticate users exists.
That’s the best new term I’ve learned in months!
When they offered to make me FTE I declined and moved on. Because it was an obvious absolute shit-show.
Sorry for those that are currently employed by MS.
Once I could reach the actual engineering team to look at the internal tool to look at the bug I had to report though, they were very responsive. The tool for communicating was cumbersome and made me feel like a vendor / customer relationship even though you are supposed to be the same team but once they realized it was an actual defect and not some harebrained feature request, they fixed it relatively quickly.
> The callback you're redirecting the user to at the end of that flow is forgeable
The redirect_uri is checked against the app registration. There's a general OAuth problem called "open registration redirects" that applies here, about which we've [blogged](https://www.microsoft.com/en-us/security/blog/2026/03/02/oau...) - but frankly, none of the industry solves this well.
In general, "I can create a link that goes to malware via X endpoint" isn't very interesting - you can also just create a direct link to the malware. Web browsers won't reliably show you the real destination of a link anyhow and even if they did, it's mostly just us hackers who understand URLs at all.
> as long as a way to authenticate users exists.
I'm lost. Entra supports [OpenID Connect](https://learn.microsoft.com/en-us/entra/identity-platform/v2...) for authentication. Most portals that surface admin consent authenticate the user with an OpenID Connect request either immediately before or after the admin consent request.
Client A connected their Azure env to my service. Now an attacker creates a different tenant at my service and goes through the integration flow. Then he sends a request to my callback that says "admin consent configured for client A's tenant" and wants to steal Client A's data. How do I protect against that? Should I validate that the user who started the flow belongs to the same Azure tenant id? In itself it's not enough, what if it's just a random user without actual permissions to go through admin consent? What if a client legitimately has multiple tenants in my service that need to connect to the same azure tenant?
Yeah. Basically, I'd expect most services are responding to the admin consent callback by saying "Admin consent flow complete. Redirecting to previous page" (usually some setup flow page). Then that page does whatever it normally does (presumably OpenID Connect sign-in with a cache in cookies / localStorage / sessionStorage) to authenticate the user.
So in a typical flow, the user is already signed in, and your service just reads their identity out of storage after the admin consent flow. If your service receives an unsolicited admin consent callback (and so there is no "previous page" and no user is signed in), I'd expect it goes to your service home page which either tries to sign the user in or shows an unauthenticated experience.
That's to say - most services setup flows are multi-step anyway. First the customer provides some information, then they sign a contract, then they pay, then they admin consent, then they configure your service's primary configuration. If admin consent is launced from /setupwizard/step4, then after admin consent, you go on to /setupwizard/step5. The normal thing step5 does (presumably, checking that the user is signed in, and then show the primary configuration user interface) should be good enough, just the same as if somebody randomly hit step5 without hitting step4 previously.
As I said earlier - validating that the customer controls an azure user doesn't necessarily mean that they have permissions to grant admin consent.
Further, I think you perhaps kind of implicitly assume that when I authenticate users I do that by their Azure identity. In practice that can be a whole spectrum - whether I have my own user management system, and whether I couple it to Entra or not is not something you can rely on. Customers expect their preferred IdP to work with your service.
Btw, I just found a short article referencing this issue, offering the same solution with the same "vulnerable to inside org privesc" gap: https://medium.com/@dipakkrdas/microsoft-adminconsent-can-le...
Making this inherently secure is just not that hard here - you could easily make this a bit more PKCE like with an additional service->azure call before redirecting the user to the flow or by adding a symmetrical signature to the callback and a new API to verify the signature.
Of course :)
> As I said earlier - validating that the customer controls an azure user doesn't necessarily mean that they have permissions to grant admin consent.
I think what I'm trying to say is: you don't really care if they have permissions to grant admin consent - you care if admin consent was granted. In step4, you show the link to the admin consent flow, and if they are an admin, they click it, and if not, they click skip. In step5, you check if an admin consent is present. It might have come from the prior step, but it also might have come from something else - who cares.
> whether I couple it to Entra or not is not something you can rely on
I think, if we're talking about the Entra admin consent flow, some degree of Entra usage can be assumed. The admin consent flow requires an Entra identity.
> PKCE
PKCE would actually not be a solve here. I don't know why so many people think PKCE solves problems that it doesn't solve, but it's very a common thing. Using browser dev tools, I can just change the tenant parameter with the appropriate cookies/state in place, and PKCE would verify fine. Even with confidential client PKCE, it just becomes a confused deputy based on the cookies.
> a new API
If you want to verify whether admin consent is present, the existing [oauth2permissiongrant](https://learn.microsoft.com/en-us/graph/api/resources/oauth2...) API exposes that information. Though admittedly I think we've left that thing in beta for a decade.
Don't get me wrong, I see what you're saying. We could OpenID Connect-ify it and emit an id token that has some sort of claim xms_adminconsent=1, which could be verified by the app. Actually, that's what the v1 endpoint does if you use the deprecated prompt=admin_consent parameter (minus xms_adminconsent=1, whose lack caused its own set of headaches). Directionally though, we felt that separating the auth flows from the provisioning flows simplified them both, and building special auth-ified variations for every provisioning flow (not just admin consent, but also sign-up, and authorize customer support guy, and ...) was over coupling. It's just unnatural to overload the authentication stack with all those random responsibilities. Having bog-standard REST+JSON APIs (i.e. MS Graph) for provisioning flows (and maybe also a default guided user interface like /adminconsent) provides a clean separation.
Edit: I think, if I were to make a change, it'd be a very small change - renaming `tid` to `tid_hint`. It's already a common practice to pass `login_hint` as a user indicator between services - and nobody gets confused and thinks that user is signed in, just because you have their username in a form post parameter. Maybe the explicit signposting of "hint" does the trick, socially.
Can confirm that we’re getting our money's worth. :D
The cloud:
Let’s see how their platform design holds up in the coming years, and if it can hold up to LLMs doing more of this same type of discovery and whether MSFT can fix it.
Such kindness & grace shown by the author. He/she could have ripped azure furthermore so easily.