4 ms·

Everything about Microsoft cloud and its ecosystem is broken. I recently signed up for onedrive (microsoft business basic, actually), and I didn't even know whi

• aksss 5y ago
  Domains: Respectfully, you don't need to know all the permutations, just the ones that get you what you need. Office.com is an easy one to remember, from which you can get to everything else. Who cares about the redirects? If you're trying to default deny new outbound connections and build an allow-list for MS resources, you'll have your work cut out for you though. They have a downloadable cross-reference of subnet/service/apps somewhere that seems about 85-90% accurate at any given time. 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.
  • inetknght 5y ago
    > Domains: Respectfully, you don't need to know all the permutations, just the ones that get you what you need 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.
    • aksss 5y ago
      As stated, "If you're trying to default deny new outbound connections and build an allow-list for MS resources, you'll have your work cut out for you". 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?
      • inetknght 5y ago
        > 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 4. Install noscript 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
• bvm 5y ago
  I've run into the payment issues before, for some reason it said we were domiciled in the US (we're not) and then I wasn't able to add a new card to our account when the previous one expired. So somehow it doesn't alert me to the fact payments are failing, and just cuts off all access to our entire org. Then after several frantic support calls, the support rep somehow hacks together a configuration that doesn't immediately fail. Only to discover a year later that we're being pursued by a debt collection agency for the previous unpaid bills, which were not viewable on my account. It is truly amazing how held together with string the whole thing is.