I know how we feel about the Microsoft Death Star consuming all in its path, but there are some upsides to statistics like this.
For instance, we are a B2B software vendor in the banking space, and we have to survive all kinds of audits regarding the nature of our code & vendors. By keeping nearly all of our 3rd party items under the Microsoft umbrella, we can automagically skip over vast chunks of our due diligence process (according to the mutual trust equation).
None of our customers is F500 (so far), but we have yet to encounter one who didn't already have AAD, or a willingness to set this up. From a product development perspective, we really prefer having a few known-good ways to do things. Authentication & authorization is one area that I strongly dislike having a large variety of flavors on. Especially considering the nature of our business and ever-increasing demands for complex MFA flows (e.g. SAML). There's been so many fly-by-night operations in this space, and our customers do not have patience for trying new things.
Sorry your comment is not helping. You could be working alone or in a 5-people startup and totally have not used anything Microsoft (and your comment does not clarify that), in which case nobody cares whether you want to set up AAD.
The article says that there may be other domains that it didn't catch because it wasn't the first result in google or the company has the server on a different domain, so it's likely a slight undercount.
That 417 is probably low. It’s hard to prove that nobody in a giant organization is using some tool, but conversely that undercuts the such statistics. If say 0.01% of Walmart’s employees are using X because of a recent acquisition then that’s hardly an endorsement of X by Walmart.
"If the title contains a gratuitous number or number + adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."
Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize."
This is directly against the guidelines and how article titles should be submitted. Editorialization of titles is heavily discouraged and here it even says something the article doesn't. Not at all a nitpick imho.
The article could use significant figures better at least. No reason to not say 83% or even "at least 80%" (would be my pick, to reflect the roundness of the number).
> However, if we say that a company does not have a tenant, we are not necessarily correct. It is possible that the google result did not point to their actual domain name, or they are using a different domain name for their AAD Tenant
For the HN B2B startups here supporting Google Workspace SSO and not Microsoft Azure SSO, or offering Sign in with Google and not Sign in with Microsoft... why?
85% of big businesses are on the one you don't support.
"Results for the Fortune 500 [to see who's on Azure AD using a] CSV with a list of all the Company Names for all 500 companies. Running it through this script, I find that 417, or 83.4% of companies have AAD, which is just a little off from Microsoft’s public claim of 85%."
There are legions of people who swore off anything M$ years ago when they found alternatives that worked better for them, and they stuck to it.
Here's the perspective from the outside: M$ has billions of lines of code, or more, and they just keep patching their software. They established their way of doing things years ago with DOS and have built on top of that since. That's how the entire industry has done it, but since M$ got so big they can't just refactor things and drop support without a billion people yelling at them, so they keep the old code and just keep patching.
They have so many people banging on their software that most of the failures are caught pretty quickly, but then there are the edge cases that don't fit into daily business activity and M$ gets pwned in that space. Their software is so vast that it doesn't cover their entire decision tree, so on the edges people begin to play around and find things not covered by testing. They might be complicated exploits that tie many things together, but it's not beyond the general public to find them with a little digging. This opens up a full exploit on M$ systems or infrastructure, then they get around to patching it a month or two later.
From the perspective of a CISO this is unacceptable. I prefer my auth software to be explicitly precise.
This might sound crazy to someone who is in an industry where "everyone is doing it", and there appears to be no other way to integrate but with M$. I'll let you know we both feel the same way because it's crazy to use (and pay for) such slovenly designed software.
azure AD presence does not imply they use msft sso as their sso.
sso integration when interacting with a fortune 500 will be a minuscule aspect of the arrangement should you get there. an f500 does not simply decide to use your product and do an sso integration et voila. they want a compliance regiment, a custom crafted legal arrangement, risk assessment, probably an onprem discussion, if you’re small enough a straight out purchase discussion. months if not years of negotiation. basically the sso button is the least of your concerns.
Even if they don't use Azure AD as their primary SSO you can often federate indirectly via Azure. For many large corporations, an auth against Azure redirects to Microsoft, then to whatever enterprise SAML2 service they're running, then back to Microsoft to pick up an OIDC token or SAML transformation, then back to your app. Instead of supporting however many SAML 2 providers with custom claim mappings you get Azure's reasonably straightforward token. You can also pick up Azure group membership (which many companies maintain or sync from on-prem AD) which is nice for mapping application roles.
It sounds like this is exactly a path you have taken with B2B PLG. Mind throwing the rest of us a bone and giving a sense of what your seats/month and/or growth in seats/month looks like?
AADInternals[0] is an excellent set of PowerShell modules for pentesting and performing recon against Azure AD as both an outsider[1] and for someone who has been invited to a tenant.
It has similar functionality integrated for discovering if a domain has an associated Azure AD Tenant and enumerating information about users in the tenant, who the "Owner" is and their contact information. As with many Microsoft products there are many configuration options and plenty of them aren't secure by default.
Doesn't the end point show up once you have SSO with your own identity provider enabled for any Microsoft services? Maybe technically this means that you have an Active Directory tenant as well, but it doesn't necessarily imply that you are using those Active Directory services for anything beyond that SSO capability.
Yes, it means that you have a tenant in AAD that's usable for signing into SaaS products and Office. May not have many or any users in it, but it exists.
Having Azure AD does not prevent clients from also having Okta or any other 2FA provider for 2 factor authentication. In fact, I have worked with at least 10 clients in the last 2 years that used Azure AD for authentication but then something else for 2-factor depending on the type of apps.
Sometimes even within one company, there are multiple 2FA protocols, e.g. using Oracle single sign on for ERP apps but Okta for Citrix and other external facing apps.
I've actually created this setup (in order to ditch Okta as it is far more expensive than AAD P1 if you want MFA).
You federate AAD and Okta. Sign in to Okta and it's smooth sailing into AAD-based resources like M365.
Okta puts on a good dog and pony show for execs. From a technical perspective, they're no better for corps (at least in first party auth or B2B -- I don't get into the B2C space). We found, for the apps we used, AAD as of ~4 years ago had better SCIM support (!) than Okta.
On top of getting O365 E5 + Ent Sec (I think they're just now called M365 E5) which gave us AAD P2 licenses, overall it was much cheaper than Okta. The goal was to just get MFA, which Microsoft gives away for free (with limited toggles) or in P1 licenses (with more toggles) where-as Okta wanted $6/user/month _just for_ MFA.
Microsoft puts on a terrible sales pitch, though. We were fortunate enough to have an _awesome_ Principal Program Manager spend days with us in-person answering all of our questions and explaining AAD to our IT management.
I don’t know the specific setup, but the app passes you to AAD which passes you to a SAML source (Okta in this instance, but we use Cisco Duo). The SAML provider authenticates you, sets a cookie, then sends you back to AAD, which sets its own cookie, then passes you back to the App. (Or something like that.) if the next app you sign into is an AAD app, you pass through quickly, but if the next app you sign into uses SAML directly you have a cookie set for that as well.
We use AAD for O365 and the few apps that won’t use generic SAML, but everything else uses Duo directly. The reason for this is at our O365 license level we don’t get the ability to restrict access to applications by AD group—everyone or we have to manually manage access account by account.
Identity federation can be pretty complex to set up and administer, but once the trust relationship is configured and the identity mapping set up, it's pretty transparent to use. Source: I do this for a living.
Signing up for Office 365 gets the company in AzureAD as it is used for logging into 365 on the back end. And all the user accounts etc. You can have another identity solution and also Azure AD. Its just why would you when everyone needs an email and they are already in AAD
Absolutely nothing came of Microsoft bundling IE with Windows in the 90s in the US. There was never a day since IE came bundled with Windows that it wasn’t bundled with Windows . There was never s browser choice initiative - nothing.
Out of all of the anti trust allegations, bundling was the nothingburger. MS was forced to stop making OEMs pay for licenses for all of their PCs whether or not they came with Windows and they were forcing OEMs to not include Netscape, share APIS, and document file formats.
Microsoft Office (bundling) has been a thing since 1990 and today, every single major company bundles products together - Apple, Amazon (Prime), Microsoft, Google, Adobe, Salesforce (SFFC and Concur), etc.
Next up: no, “cable was not ad free when it was introduced”
The whole Windows/IE bundling fracas has to be looked at in the context of Microsoft not only having a lot of unsavory business practices--as did it's welded together at the hip partner Intel--but also it was seen in the eyes of a lot of people as on the way to utterly dominate computing once Unix got pushed out of the way.
Add in the dominance of Office and Microsoft's presumed dominance of mobile once that became ubiquitous and a lot of people were looking for any lever to use against the company. All this activity probably made Microsoft back off a bit in some areas and likely tarnished its aura of inevitability a bit--but it's not entirely clear that it made much difference in the end. (And there were certainly people at the time arguing that the Microsoft winning over all narrative was deeply flawed.
The nuance that you’re missing is that Microsoft was a monopoly found guilty of antitrust violations. Bundling has different consequence for them than non-monopolies or monopolies that that have not had antitrust convictions.
Yes, there was a version of Windows that did come unbundled, Windows N <level> that was targeted for EU users to comply with EU antitrust agreements. And there was a browser choice selection during OOTB configuration with the top 4 or 5 browsers in the marketplace.
Microsoft absolutely dominates corporate IT. Their Office 360 delivers to much values at a low cost that the corps suffer from mediocre MS products because it's all there through a single subscription.
Same for the Google options; except the Google options tend to make non-backward compatible changes and often only go 90% of the way to meet the competition in terms of features. Even their spam detection is not where postini had it years ago.
A CIO needs to see significant upside in choosing a non Microsoft solution to take the risk of not going with on-prem /cloud AD.
Very few enterprises, this is an understatement, use Workspace exclusively.
They need Active Directory Domain Services (on-prem AD) regardless and it is their source of truth (typically syncing to Workdpace for users/roles). The tooling and expertise is in AD. Azure AD will always have a better on-prem to cloud story than Workspace (or any competitor). Plus their licensing makes it a no brainer. It’s a very strong moat.
Jira, and the whole of Atlassian Cloud services, bundle SSO as a separate service you pay for. It's called Atlassian Access and it costs $4-$2 depending on number of users, so many companies skip it because it easily doubles your Jira/Confluece costs.
They are insanely good at onboarding people onto it as well. I have a small startup just me and a cofounder right now and we pay $12 a month for 365 which includes all of Azure AD. Can start doing full integrations right away to lock us in.
This is awesome! I went 6 times to Microsoft AD’s pricing page and I could never figure out how much it would be! Then I remembered it would be bundled with Azure, which, like any cloud, has the “It’s 0.0062$ per unit of consumption, so sometimes it’s 2€ per month, sometimes it’s 647€, we never know ourselves, good luck!” effect.
Has anyone else sometimes avoided a cloud service because the pricing was opaque?
Basically if you have a Microsoft Office 365 Enterprise license (E3 or E5 license – which you need if have business people in your company who can't live without Excel on desktop), you get Azure AD Premium (P1 or P2) bundled for free.
As I was writing this comment I just went looking at their AD page and found they have launched a new thing called Entra which includes Decentralized ID. And there's a white paper – interesting.
> you get Azure AD Premium (P1 or P2) bundled for free
Last time I checked what was included with Azure AD the activity logging data was where it looked like things could get expensive. Exporting your authentication logs and/or keeping them for more than a week was a premium add-on.
Be sure and look into Microsoft for Startups at some point: https://www.microsoft.com/en-us/startups. It gets you Office and GitHub Enterprise for free, among other things.
This is assuming the domain has it, but it's even easier actually - you can just DIG DNS records and see if what they run as MX, cnames, etc, if there is teams DNS records and the MX record points to *.onmicrosoft.com or $tenantname.mail.protection.outlook.com there you go, even easier than "querying" google and seeing what's index.
What I can’t understand is why Azure AD doesn’t have a stronger position in the consumer space. Authentication via Google, Apple, and even still Facebook are nearly always supported on customer-facing logins. I rarely see an option for Microsoft.
They have a commanding position in the enterprise. What’s keeping them from crossing those enterprise boundaries?
They were an early mover in this area twenty years ago with the original Hailstorm / .Net Passport which was skeptically received and wasn’t helped by some spectacular outages. Google and Facebook leveraged their apps and especially GMail - Apple had the leverage from their App Store to force everyone that mattered to at their service too.
Incidentally, a Microsoft Passport login still works on any site with today's "Login with Microsoft" ... and there are starting to be more along side "Login with Google" or "Login with Apple".
These days, a consumer + biz page login page can look like this:
There's almost no good reason to require emails/password rather than let users use their preferred IdP.
I think the reason it's less common is simply that indie devs assume everyone uses free Google Workspaces. This year we're seeing more Microsoft Logins. Perhaps one reason is that now Google Workspaces is no longer free and startups are realizing they can get actual Office with actual apps at the same per $6 to $12 per user cost. Then in turn, supporting that login.
Do enough people still use consumer Microsoft accounts? Except for myself, it has been a long time since I have encountered a hotmail address or live address or outlook address in the wild.
I've gotten career advice several times to get a GMail instead, because Microsoft was considered out of date and backward (not so much anymore).
There are lots of very popular Microsoft services for consumers including Xbox and Office 365. Combined, these have hundreds of millions of paid subscribers.
I'd expect this to grow now that Windows pushes more aggressively to use an MS account to login.
Plus, if this works as well as it does with the "corporate" AzureAD, it would be a better experience for users. Just "log on with your Windows account".
Not saying that's necessarily a good, thing, mind. Only that I expect support to broaden.
Anyone that uses Minecraft (edit: or Xbox) I'm sure it is only a matter of time until some middle manager stakes their promotion on merging it with github and/or linkedin.
Microsoft is the only company I deal with where I cannot reliably authenticate. I wish they'd just stop trying to run consumer accounts.
You can link your GitHub account to a Microsoft account and log in to Microsoft with your GitHub account, not sure if you can log in to GitHub with your Microsoft account tho.
How times have changed, I mostly hear Google being called backwards now for its view that customers are just beta testers you dispose of when your latest moonshot project doesn’t hit orbit.
Microsoft's support for multiple accounts is atrocious. I can easily have 5+ Google accounts that I switch between, moving between MS accounts is awful. Additionally MS's free consumer offerings are not competitive with Gmail/Drive IMO.
I'm not a fan of Google's solution either. With a device with multiple G accounts it’s always a guessing game when opening up a google doc which account it’ll choose.
> It's even worse if you have personal and business accounts tied to the same email address - you never know which one you're using, or which you need
I have a friend who managed to do get into this mess, and he's still not sure how he did it.
firstname.lastname@companybizname.TLD is apparently linked to two separate identities at Microsoft, one is a business account, one is a "personal" account.
Every time he experiences any kind of login issue, this bites him :/
This is a legacy setup that can no longer be created. Microsoft removed the option to use a custom domain for Microsoft accounts many years ago, but hasn't forced people to change.
However, your friend can get out of this scenario by following the instructions on this site:
They'll end up with <whatever_they_can_find>@outlook.com for their Microsoft account. When using Org services via a browser, you'll automatically use your Org account. When using consumer services, you'll automatically use your Microsoft account (assuming you've selected stay sign-in for both).
> This is a legacy setup that can no longer be created
Thank goodness for that!
> However, your friend can get out of this scenario by following the instructions on this site
Thanks for the tip, will try and walk him through this next time I'm with him.
> hey'll end up with <whatever_they_can_find>@outlook.com for their Microsoft account
I doubt they actually need/want access to the Microsoft account. They don't use this work email address for any consumer services, as far as I'm aware -although how could one tell what services it could be associated with?
I read an explanation from some Microsoft page or rep. that it had to do with making personal purchases in the Windows Store when you're signed in using your business account. IIRC the rationale was that the personal account could persist beyond your employment, so you wouldn't lose any purchases if you switched jobs.
If I indeed recall correctly, then that doesn't really make sense. Just force people to make a different, actual personal account, and have them use that.
> IIRC the rationale was that the personal account could persist beyond your employment, so you wouldn't lose any purchases if you switched jobs
Except if you lose access to the work email address by switching jobs, surely you're one forgotten password away from permantently losing access to the personal account too? It's linked to your _work_ email (only)...
Indeed. I've never understood this distinction. Either it's a business account, or it's a personal account. It's bad enough that people use their business mail to sign up for personal stuff, we don't need Microsoft to make it even worse.
Facebook and Google provide "Sign-in with Facebook/Google account" not because they do it out of goodwill, to only make it "easier" or "smoother" to login -- it obviously cost resources on their end to enable such features -- it helps them better identify users and then serve ads. And Google can be really aggressive -- try reddit or Quora.
Apple, on the other hand, tries to sell "login with Apple account" with a different approach: they advertise the "privacy" part of it and how you can hide your email address by using it's sign-in service. And they have a term where login with Apple must be enabled on an app and website if a company has an app on the app store and it supports any other third-party login. In other words, if Reddit supports login with Google on iPhone, it must also support login with Apple ID. This helped the adoption a lot.
For Microsoft, they are relatively late and small in the ad business (for now) so I guess they don't really care about getting more of your information via sign-in services. And they are not on this privacy bandwagon as Apple does. So they really have no incentive for this.
Nearly 100% have on-prem AD (full name: "Active Directory: Domain Services"). Azure AD is a separate identity provider -- to a first approximation it's HTTPS and cookies, not Kerberos, LDAP, and Ticket-Granting Tickets that we see on-prem.
NetIQ eDirectory tends to be the other big one. Although I am seeing a rise in companies not having an SSO solution recently at all. In fact some of the SMEs I've seen recently are running most of their stuff entirely via basic Microsoft O365 accounts or iCloud.
A lot of startups or smaller companies I've worked with are entirely on the Google stack (gmail, google drive). I imagine there's a scale when that option breaks, but I think it'd be fine until 50-100 employees.
One thing to note about these results is that when we get a result that says the company has a tenant, we are nearly 100% correct in that fact. However, if we say that a company does not have a tenant, we are not necessarily correct. It is possible that the google result did not point to their actual domain name, or they are using a different domain name for their AAD Tenant.
If you wanted to do this really robustly, you would probably want to get a better source for your domain names than automated google search results. You might want to also look at other combinations like “companyname.onmicrosoft.com”, however we are doing just rough estimates here.
The script also seems to assume that the company's domain name is of the form (foo.bar), which may be a reasonable assumption for the US-based Fortune 500, but won't work so well if trying to replicate this with international companies (which often have domain names like example.co.uk or example.co.jp).
In contrast, the vast majority of companies with Azure AD also have on-prem AD (full name: "Active Directory: Domain Services") with some type of synchronization between them. Usually this amounts to having an on-prem service that shleps password hashes (technically salted, stretched hashed versions of the on-prem hashes) to Azure.
Exactly. I know one myself, one of the biggest companies in the world, who's tenant name has no resemblance to their company name. Security by obscurity is not a security feature but it is a barrier...
I initially had the same thought as the parent. From the perspective of so many companies relying on the security of one authentication provider (rather than any one company using AD for all their authentication needs).
So if AD were to be compromised, that would be significant impact.
There are of course advantages to such a "single point of failure" such as concerted effort in one place. But one way to mitigate the spof is transparency, and I'm reminded of LastPass versus Bitwarden.
I know next to nothing about AD, but my company appears to match against this merely because we have an Office 365 account (from which we do nothing except download Word and Excel every now and then) so it doesn't necessarily mean you're using whatever it is much.
If you have Office 365 you have AAD. If you use pretty much any cloud hosted Microsoft business services, (E# licenses) you are using AAD. If you are using Azure, you are using AAD.
So, I don't see anyone pointing it out here: This doesn't mean they use Azure AD! If you use any Microsoft cloud services at all, you get a "shadow tenant". One employee signs into Teams for a meeting once and there you have Azure AD.
There's actually a number of products under the Azure AD name, including:
* Azure AD, their employee/workforce solution. It's a directory, authentication and authorization system. Think Okta or AWS SSO. I imagine this is mostly what the survey was tracking.
* Azure AD B2C, their CIAM solution. Think Auth0, Cognito or FusionAuth (disclosure, I'm a FusionAuth employee).
* Azure AD EI, external identity management (users outside your org).
* Azure AD DS, domain services (older Windows focused services). This subsumes a lot of what Active Directory provided.
honestly though, Azure's naming strategies do exactly what they say. AWS uses names that are adjacent or completely random (fargate?). i don't even think cognito is a word in english language[0]
Authorization and authentication. Like it or not Microsoft Active Ditectory or Azure AD (basically the cloud version) works with everything and it’s kinda the only single-signon/shared login solution for enterprises. You can build something yourself with LDAP, Kerberos and maybe Keycloak, but why bother when you more or less need AD for Windows and Exchange anyway.
For juniors: Enterprises and even small startups need to comply with their industry’s security certification (PCI, ISO, whatever) which requires traceability of logins (and central revocation when employees quit and provably complex passwords and inability to retry 100 times, etc.)
We use Okta, currently with on-prem AD, but are whittling away at the use cases for the latter and hope to be AD-free once we solve for RADIUS (suggestions welcome :)
Well if you're familiar with Google Workspace.. you know once you've got email accounts in there then there's a whole lot of user admin you can do?
Azure AD is just Microsoft's version of that directory. The thing is if you use for example Exchange Online, or even just like Microsoft Office licensing, you've now got Azure AD where the users have accounts. Then I see businesses spend a fortune to integrate Okta or similar products that don't actually add anything given how feature full Azure AD is at this point.
It does a lot of things, but broadly the thing people know it most for is handling roles, permissions and groups for your organization. It’s often the source of truth for things like access and provisioning. Pretty core part of the organization.
Active Directory is Microsoft's LDAP[1] server offering. Eventually it got more features and is used by firms to enforce company wide (or group wide) rules like "Every computer must lock after 5min of inactivity" or "Adobe Acrobat must be installed in all computers".
Azure Active Directory is the cloud version of Active Diretory. It has some extra features compared to on prem AD (MFA, SSO with 3rd paty apps...) but the whole endpoint management part was moved to another product (Microsoft Endpoint Manager).
The reason so many companies have an AAD tenant is it is set up automatically when you configure Microsoft 365.
on-prem AD has SSO, it's called Active Directory Federation Services. Compared to Azure AD, the on-prem Federation Services has more features. To give one example, Azure AD does SAML, but it's not full compliant. We ran into an issue with at my last employer when a partner moved from AD-FS to Azure Active directory and broke the SAML integration. It required us to go back and re-do the federation model from scratch.
Presumably this is the same thing whatismytenantid.com does under the hood.
Interesting (to me) is that the OpenID configuration endpoint provides the tenant ID for not only Commercial tenants but US Government (GCC & GCC-High) as well because the Azure AD portal has relatively new functionality to configure cross-tenant access settings by tenant ID or domain name but Gov tenants require you to obtain the tenant ID from the organization which is either security through obscurity or due to use of some Commercial-only Graph API call.
I never thought about how the "I'm Feeling Lucky" button on Google can double as an API to return the URL of the first search result before. That's pretty neat.
Indeed legacy, but you know how Fortune 500 companies are about new technology not directly relevant to their line of business.
Also, SAML as a spec is really complex precisely because it was created to satisfy a broad range of Enterprise-y requirements. I don't know if OpenID Connect is there yet. It certainly could be, the underlying spec (oauth2) could support a lot of variant complexity, and OIDC supports mobile and there are lot of extensions available or in progress. https://openid.net/developers/specs/
Honestly, I think the regulators should look at basically all of those things. Here in Europe scrutiny is building and a lot of those organisations do party hard and play loose with the rules. Microsoft is famously anticompetitive, but Adobe, Google and Apple can't be far behind in their respective areas.
Really? So you really think companies shouldn’t be able to sell software that works together bundled together? Why stop there? Phones and computers shouldn’t be “bundled” with operating systems? Computers shouldn’t be “bundled” with sound hardware? Where does it stop?
Bundling is fine. Bundling by a company that is a monopoly in the space is (or rather, used to be) a violation of antitrust law. But see Amazon’s Antitrust Paradox, especially sections IIA and IIIB: https://www.yalelawjournal.org/note/amazons-antitrust-parado...
So in that case, every cable company is a local monopoly and shouldn’t be allowed to bundle channels. Doesn’t anyone see how silly this sounds in 2022?
Disney is by far the largest entertainment conglomerate. Should they not be allowed to bundle Hulu, Disney and ESPN?
Intel has over 80% of the PC market, how much hardware should they be able to bundle on their motherboard?
And HN has a habit of calling any big company a “monopoly”. Amazon only has 56% share of e-commerce and a tiny share of all commerce in the US
But getting back to MS Office, I have three “office suites” right now on my phone - all three made by companies worth 1 trillion dollars - Google, Microsoft, and Apple.
A regulated monopoly. Key difference. Although of course today "regulated" is largely a legal fiction. Nevertheless, it's not so simple as pointing out who has the most market share. It's a pretty messy area of the law, and the field is heavily tilted by money, even more so than most areas of the law.
It’s not a “messy” area at all. It’s just a misunderstanding of the law. If what you’re saying is truly “illegal”, no court of law has found it so since Office was introduced over 30 years ago.
What’s more likely, that “bundling” as you define it is illegal and has never been prosecuted in over 3 decades or that you don’t understand the law?
It's far more likely I don't understand the law, but the discussion had turned from bundling to monopoly and antitrust questions, and I stand by my statements, as confirmed in the source I linked.
Nah. Azure AD is one of the few IdPs that already supports FIDO2 Discoverable Credentials. You can use Passkeys with it today. You can go passwordless with it today.
Unfortunately, unless this changed too recently for me to know about it, that feature is default off and labelled "Experimental" or something.
So it's difficult (ask me how I know) for someone who knows way too much about this stuff and has implemented it themselves, to explain to "leadership" why they should change that default.
I don't know the details except that we've been using it since early this year. The docs don't make it seem like there's anything particularly complicated with enabling it[0][1].
I'm not sure I really follow. In an enterprise setting, giving people the option to opt into fido fine and good, but it isn't going to meaningfully help lower the risk of phishing for the organization as a whole. To address phishing, organizations need to mandate fido and disable all the weaker forms of authn. That means you're still going to have to convince your leadership to buy into the change anyway. You'll also need a decent sized communication and training campaign to move everyone over to the fido auth flow.
The technology is the easy part for rolling out fido in the enterprise. The hard part is all the people stuff. (Although this too is getting easier, since a lot of orgs can now roll out fido with existing hardware via platform authenticators.)
Unless your company is in a high-risk security-sensitive business, they shouldn't. Most companies can accept the low risk of only requiring a second factor sometimes. Usually time-based, but also looking at location and device fingerprint. For example, if you normally log in from your laptop at work in one state and then it sees you trying to log in from a computer in another state (maybe you're visiting family?) it should definitely challenge you.
For instance, we are a B2B software vendor in the banking space, and we have to survive all kinds of audits regarding the nature of our code & vendors. By keeping nearly all of our 3rd party items under the Microsoft umbrella, we can automagically skip over vast chunks of our due diligence process (according to the mutual trust equation).
None of our customers is F500 (so far), but we have yet to encounter one who didn't already have AAD, or a willingness to set this up. From a product development perspective, we really prefer having a few known-good ways to do things. Authentication & authorization is one area that I strongly dislike having a large variety of flavors on. Especially considering the nature of our business and ever-increasing demands for complex MFA flows (e.g. SAML). There's been so many fly-by-night operations in this space, and our customers do not have patience for trying new things.