Allow “Sign in with Microsoft” to work with business accounts

Agree!

We are in the same position and I had no idea that this did not work for business accounts.  Thanks for raising it. 

Hey folks, you're right that Microsoft as an SSO option for end users is currently limited to Microsoft as a “social sign-in” (meaning you can use or Xbox or Outlook details for example). This is highlighted in our Enabling social and business SSO article. 

I agree with you that there's situations where end users are actually operating in a professional capacity, and should be allowed to use their Microsoft business details through the native Microsoft SSO method, the current workaround is setting it up via SAML instead. 

We've no current plans to address this but I'll log this internally so that I can track it. Many thanks for raising it. 

@caroline13 I know this is not the support channel but how does using the SAML setup help here? If we setup the SAML, that would only work for just one MS business domain/instance or would that allow any MS O365 business user to login via  MS Business SSO?

Microsoft has their own documentation for how to set it up using SAML. 

What we have found is that the SAML function is for one MS account… what we are wanting is for any user with a MS business account to be able to sign in to our ZD account using an SSO button. 

Caroline, this approach does not work as it requires users to be assigned to groups within your own AD.  You can't do that ahead of time without knowing who of your cusomters use Microsoft and then partnering with them as trusted orgs to share AD data.  Companies just don;t do this, especially companies that are primarily B2B with thousands of organisations they deal with, it's just not feasable.  

Also, Zendesk doesn't support JIT so there is no workaround for the above requirements. 


It would be great if we could get fully researched and comprehensive answers from the PM team instead of being dismissed so quickly.

We would really appreciate a solution to this issue as well. All of our customers use work or school accounts with Microsoft or Google.

Being able to present them with a sign in with Google button but not a sign in with Microsoft button is far from ideal.

Zendesk - you are missing the boat here and going to lose compliance customers. There is no way to require MFA for end users and now you take the enterprise app functionality away from M365. SSO is not practical with hundreds of business customers. If this or required MFA for end users is not addressed, we'll be forced to move everything to Jira or service now as we need positive confirmation that end user is who they say they are for security reasons. Please reconsider building an enterprise app for M365 Commercial AND GCC-High. This is very common amongst vendors and Microsoft has a large market share so I don't see why this wouldn't be high in your road map. Cyber compliance isn't going anywhere, this problem will only get worse. Thanks for the consideration.

I asked Zendesk support about this and he mention that “Around the end of 2023 there was a vulnerability identified related to Azure IDP (now is called Entra) and potential concerns with forging an agent login. Due to this vulnerability, it was decided to not allow the business accounts for end users to have more control over the tenants.”

If the problem is regarding agent login, it should be blocked for agent logins, not end users, but agent logins works as Social Login and end users doesn't, so the supposed “vulnerability” is still open.

Also note that the Google SSO button works with Personal AND Business (Google Workspace) accounts, it makes our jobs even more challenging to explain for our multisolution clients that they can use their Google Workspace accounts, but they cannot use they Microsoft account using exactly same domain. 

I will represent against Zendesk by our legal system in Brazil to act over this issue if not solved until March 31, 2025 because of our impact for over a year.

Hello everyone, Caroline from the Zendesk Product Team👋 The security of your Zendesk account and personal information is of the utmost importance to us here. Thank you for sharing your concerns. We wanted to take a moment to share more details about our decision and update you on our plans. 

In May 2023 a security vulnerability was addressed which could have potentially allowed an attacker to sign in as a Zendesk agent. There was no evidence that this vulnerability was exploited. The fix required linking Microsoft Entra ID tenants to the Microsoft sign-in settings for team members or enabling SAML-based SSO with the Entra ID tenant. That’s the behavior you see today in Admin Center under Account > Security > Team member authentication > External authentication. 

The fix additionally prevents end users from signing in using Microsoft authentication with Entra ID, resulting in them only being able to sign in with their personal Microsoft accounts. 

The vulnerability was a result of Microsoft allowing Microsoft account owners and administrators to set emails to an arbitrary value without any uniqueness, validation or verification. In contrast, Zendesk requires unique emails as identifiers for users and expects the Identity Provider (the Entra ID tenant in this case) to verify users' emails. Accounts have to be linked to a specific Entra ID tenant to ensure you are only working with trusted partners or your own directories.

There’s a possible path forward that we are exploring that would allow Zendesk admins to link Microsoft Entra ID to the Microsoft sign-in settings for end users (same as it works for team members today), but that’s not currently on our 2025 roadmap. Still, this potential future path wouldn’t allow for end users to sign in with any Microsoft business account because of the contradictions above on email uniqueness and verification. 

Thank you again for raising your concerns. We have documented this feedback for us to use in the future however at this time there are no plans to change this course of action, and we are continuously dedicated to providing customers like you the highest level of protection. Thank you for sharing your concern and for continuing to be a valuable Zendesk customer. 

Caroline, this mitigation workaround to avoid this vulnerability does not make any sense, if an attacker could impersonate credentials, the Microsoft Account login should be blocked for agents, not end users. There is the dumbest risk mitigation I ever heard.

Again, please revert end user login using Microsoft Accounts on /common endpoint, it's impacting us, Zendesk clients. If you are interested in looking further at this vulnerability, the risk mitigation for this “vuln” needs to be implemented for agents, not end users.

@caroline13 

Why couldn't you simply set it up so that if when they use entra to sign on if their tenant ID does not perfectly match what is loaded in Zendesk already, that they are limited to end-user role? I may be missing something here but it seems like a fairly simple fix. 

Unfortunately, this would not resolve the issue. 

There are two scenarios here:

• First, let's say name@domain.com is an agent in your system. If someone using their own Entra instance were to create a record with that email address and try to log in, we couldn't limit the person logging in to just end user permissions. It would mean either downgrading the agent record to an end user (which would undoubtedly be disruptive) or creating a new record, and we only allow one user with each email address to exist within an account.
• Second, even if the existing user is already an end user, we can't allow a takeover situation like this to occur — just because the user isn't an agent doesn't mean the data they have access to isn't private. In some cases they could have a long history of tickets, attachments, or custom objects, which the attacker could now access. The attacker could also use their authenticated status to submit tickets, spoofing the identity of your customer in a very believable way.

We are not set up today to combine our identity model with Microsoft's in this way. There is work we need to do before we can treat the true identifier of an Entra user — their Entra-specific ID — as their identity rather than their email.

Thank you again for your engagement and questions. As more folks may see this thread we do want to remind everyone that if you have any questions about configuring your account or using our features to keep your account secure, you can always reach out to our customer support team or your account team for help. We sincerely appreciate your continued feedback and insights for how we can improve our product offerings.

@caroline13  Excellent explanation, thank you!

Looks like Zoho Desk have same features than Zendesk and allow everyone to login using Microsoft credentials without restrictions. 

I solved it by running a self-hosted KeyCloak and added Microsoft + Google Social Login on it, a viable workaround for Microsoft Social Login limitation imposed by Zendesk.

@ivan14 wondering if you'd be open to sharing how you worked around this? We're running into this as well and are trying to find a solution for our customers to use the “Sign in with Microsoft” SSO button.

@caroline13 what's the latest with this? I understand the security risk, but I have to say, I agree with most of the comments here and I'm curious what's planned to help mitigate this. 

There's nothing more annoying than having to create new login credentials for every platform you're using, and it doesn't make sense for end users to have to do that when they have Microsoft credentials. It causes friction at login, lower engagement, and password fatigue. They should be able to sign in with Microsoft SSO to optimize their experience.