azure.com onedrive.live.com admin.microsoft.com microsoftonline.com office.com office365.com onedrive.com onmicrosoft.com sharepoint.com windowsazure.com
Each one of those portals take you to SOME view of your account with a gazillion settings. Many of them are repeated, and changing it on one portal doesn't necessarily reflect in others. For example, I enabled 2FA somewhere (and it worked), but going to admin.microsoft.com showed 2FA disabled.
Even payments, which every other website seems to have figured out, is broken. There was a recent change in regulations in India for subscriptions on credit cards that allow the customer to control the period of subscription, enabling/disabling, etc. Microsoft of course, hasn't implemented the changes (despite the regulations being notified in August 2019), and because of that, transactions are being declined.
So can I go and make that payment online? Well, no. Your subscription shows up as "expired" because it couldn't charge your account, and the only option it gives is for you to "reactivate" the account. Great, so I'll just reactivate. But no, it doesn't allow you to pay when you reactivate - it's going to try and charge your credit card again, itself, as a subscription, sometime. And of course, that's going to fail again. Loop!
So somehow, with the help of Microsoft support, I manage to sign-up for another subscription with the same licenses for the same cost, and they disable the old one. Great. So this time, it tries to charge my card, fails, but then allows me to "settle" the "overdue" amount manually. I do that, and my account is "active" again!
Do they send me a mail saying they've received the amount? Nope. Does my Microsoft account billing page show that I've made any payment to Microsoft? Nope. The only indication that I've made a payment is that my account is active with an expiration date in the future.
MFA enable/disable: there are multiple places and methods to enforce MFA for users in a Microsoft tenant. So yeah, it can be disabled in one place, and enforced in another place. For example, conditional access policies may require it while the older deprecated interface for enforcing MFA may show it as disabled. For better or worse, this is common to many topics in Microsoft-land, a combination of there being three different ways to accomplish the same thing (which is probably most often a feature, honestly), and the relatively rapid pace of change (a double-edged sword) that deprecates terminology, branding, and tooling frequently. It does require you to actively work to stay informed about how the platform evolves over about a 18-24mo period.
Payment History/Billing: It honestly does benefit most business customers to work through a Microsoft partner rather than a direct relationship, oddly enough. A partner will often have far more flexible license commitment terms, more flexible payment methods, occasionally have better pricing, and always have better invoicing and reporting capabilities than are offered in direct relationships. Microsoft's cryptic payment history and invoice reporting is pretty offensive - it works great as long as you never have any questions.
All that said, direct relationships are for customers that just need the basic services without any special requirements; partner relationships are for businesses that have more mature requirements but don't want to be experts on the rabbit hole that is Microsoft-land. Many SMB Microsoft customers attempt to go it alone thinking it's easy (in no small part due to MS marketing) but the minute a business wants to get more than ankle-deep in any technical domain such as endpoint management, data loss prevention, compliance management, threat management, etc., they will quickly find themselves underwater - not because it's complex (it's all easy) but because it requires a lot of deep-quirk knowledge and ongoing maintenance and monitoring. This isn't necessarily particular to Microsoft, though I think a lot of marketing has gone into creating the impression that IT can be 'easy'. But just like a IDS/IPS, buying the tool is the easiest step - it's the care and feeding that really saps your labor force and makes most solutions fail. Policies need to stay relevant, state need to be monitored, deviation needs to be remediated, changes need to be incorporated. It (IT) takes constant work to do it right.
That's a bit of a problem, because the sign-up mail they sent me, had a link to onmicrosoft.com, and the billing was on admin.microsoft.com. I had no idea that office.com was the place to go to, to have all the nice things in one place.
I wanted to create a form. So I google for "microsoft forms." First link takes me to forms.office.com, that redirects to a microsoft.com forms landing page that has a sign-in. Great. Click on the sign-in. Get redirected to login.live.com. Try to sign in with my microsoft business basic account.
"That Microsoft account doesn't exist. Enter a different account or get a new one."
Hmm... but I can see a forms license enabled on admin.microsoft.com... Turns out that live.com is only for personal accounts, not business accounts. The microsoft forms landing page says NOTHING about where business accounts should login to access forms.
Ok, so now I want outlook. So, outlook.com? Takes me to outlook.live.com - again same problem. So turns out you've to go to outlook.office365.com to get to the business sign-in. After sign-in, it redirects to outlook.office.com.
outlook.office.com redirects to login.microsoftonline.com (that allows business login), but forms.office.com takes you to login.live.com that doesn't allow business login.
The payment issue the original comment was talking about, is super basic. I've faced the same issue for months it's not even funny.
Nobody is doing anything complicated. We're just trying to manually pay an overdue bill. Super straightforward in AWS, GCP and DO. In Azure, you don't even know where the "Pay now" button is given that automatic charges are declined due to a new law.
I'm tired of the "It's not just Microsoft, other companies are equally worse" argument.
I'm a single person running a web app on Azure App Service. I don't need an MS Partner. The direct relationship sucks. MS sucks. Stop defending them.
Also, you may want to consider switching to 'pay by invoice' rather than setting it up to pay by credit card, which is going to auto-bill by default to my knowledge. It sounds like you're trying to use an autobill payment method from a country that doesn't allow auto-billing. I predict problems. It's entirely fair to be upset that Microsoft's validation does not anticipate this, but there it is.
Sorry but using a partner or becoming one for running a single fucking web app is absurd. End of the month, I'm moving everything over to DO - solved!
I submitted a request for pay by invoice last year to which I was told I can pay by Credit card. I told them I WANTED to switch again and a representative told they'll get back to me. Nothing ever happened again. I left it at that.
This time however, I got an email from MS stating due to a law that declines automatic payments I'd have to pay the bill by clicking the Pay Bill button on the billing console, which is simply not there. Trying to go through the documentation for it is bizarre since it never tells you where exactly the "Pay bill" button is.
I'm not even mad today cos Azure throws a random error when I go to the billing page. Fuck this.
Becoming a partner gives you free Azure credit each month, as well as internal use licenses. That’s something many developers can benefit from relative to the minor annual cost. That you would also be able to set up a distributor relationship to get more flexible payment terms directly instead of through a different partner may be more palatable to your go-it-alone approach. I don’t care what you do one way or the other, again, just giving you more information.
DO is a great hosting option, often cheaper, though with trade offs that may or may not make sense. Anytime you’re on the phone with support, whether MS or DO, you’re already in a bad position. Been there. At some point, because of dependencies, you need to learn the constraints of the platform (whichever one) and work within them.
Sure but all of them should fit under a single microsoft.com. As it is, I won't be able to tell if some third party has maliciously created office366.com or if it's actually owned by Microsoft. What's the difference between office.com and office365.com? It doesn't matter: both aren't microsoft.com and therefore both are malicious. And microsoftonline.com? That also looks very suspicious. Wanna redirect from one site to another? Oh man all that you're really wanting to do is to train users to allow cross-site forgeries.
So, respectfully, you have no idea how to make a secure product.
If you're trying to secure your consumption of their product by explicitly allowing communication with only pre-authorized domains, they are still finite in number. The quantity is more than 1, but less than infinity. You can build such a list if you want to, which would exclude office366.ru. I'm not sure I understand the problem - that you must authorize thirty domains instead of one? Or are we arguing a principle here that one domain should be all that the entire Microsoft product catalogue ever uses?
I confess, I may fail to see how one domain vs two vs twenty-two known domains is going to matter, but I am curious to learn more. What are you attempting to do on that domain front?
1. Use pihole
2. Use Firefox.
3. Install umatrix. Open its ruleset and add a rule:
* * * block
5. Then start adding domains as needed -- first on umatrix, then on the pihole, then on noscript
Nearly all sites will be readable with only their domain enabled (and all else including cookies, CSS, images, scripts, etc) blocked. Most sites work great with only CSS and images unblocked. This is literally the way that the internet is supposed to work. But a few bad actors, such as Microsoft, have made necessary the complications of cookieblocks, scriptblocks, adblocks, dnsblocks, and etc.
You can't log in without cookies. So those are the first things to enable on sites that you need to log in. Some sites work great with just cookies, CSS, and images.
Some sites use cross-site requests to do account lookups though. In those sites, you can't log in without XHR. So those are enabled next.
And in some few places, like Microsoft, you can't login without scripts and "other". Microsoft wants to fingerprint your device for "security". But that security is, at best, broken. I argue it's much more malicious.
Further, in most websites, you only need to enable these things for one or two domains to be able to log in. Google requires three or four depending on the login workflow. Stackoverflow requires two.
Microsoft? Hahaha, I gave up after six. Now I exclusively use Microshit's sites in its own dedicated virtual machine isolated from everything else with its own pihole and separate lookup rules because I can't trust that it won't add yet another domain that's "needed". I can't trust that a third party won't abuse a wide open system like that to sneak in some additional requirement while trying to figure out what works to get logged in.
What am I attempting to do on that domain front? I am attempting to demonstrate that a site doesn't talk willy-nilly to every fucking body else and provide fifty million avenues for:
* cross-site request forgeries
* cookie hijacks
* script injections
* encryption certificate expiration/hijack
* domain name expiration/hijack
* look-alike/typo names "office365.com" vs "0ffice365.com" vs "office-365.io" vs "office-365.azure.com" vs "ms-office-365.cloudfront.net" vs ...
* there's no way I can write an exhaustive list for you
Well, have fun with that. I guess I still don't understand why you're worried about office366-type domains if you're whitelisting allowable domains to begin with. Anyway, everyone's risk analysis is different, sounds like you're managing yours accordingly.