Microsoft Enterprise SSO and Tiered Azure Accounts

[McAwesome]

I've started playing around with the Microsoft Enterprise SSO plugin to compliment Jamf Connect.  For end users, this seems like an easy no brainer setup.  The problem comes with our IT tiered accounts setup.  In our environment, standard users have a mundane account while IT tends to have a Tier 2 account, server admins have a Tier 1, etc.  This was done for various security reasons, and generally works well for us.

This setup does not play nicely with the Microsoft Enterprise SSO though.  For example, in my testing I effectively get locked out of Jamf because the Microsoft SSO auto applies the mundane account and Jamf doesn't have a built in account switcher I could use to swap to the appropriate tiered account.

Does anyone have any recommendations on how to handle this edge case?  The vast majority of our users won't have these tiered accounts, but those that do will be pretty vocal about things not working.  I don't see a way to exclude specific sites from the Microsoft SSO configuration without excluding full browsers or applications.

[AJPinto]

I suggest reaching out to Microsoft on this, its their product and they should have the best advice.

What are you looking for with an account switcher? SSO can be disabled in self-service (or use CLI to run policies with terminal), and there is a SSO bypass URL for JAMF. Assuming I am tracking on that question correctly.

[McAwesome]

I was referring to the Jamf web view, not the Self Service client.  That's where the Account Switcher functionality would need to be built, and since that is a Jamf Product it seemed prudent to ask here how others are handling that interaction.

[AJPinto]

You pointed out yourself that "the Microsoft SSO auto applies the mundane account" which implies you traced this behavior down to the Comp Portals SSO extension, which is not a JAMF Product. When you enable SSO, JAMF passes all authentication off to the IDP.

Playing in beta is well and good, but these are the kinds of feature parity issues are things I would expect to see when testing beta products. You could submit a feature request to JAMF to separate SSO for the JAMF Console and SSO for SelfService. Considering you are testing a beta product I would not expect much from JAMF on this, and I suggest reaching out to Microsoft for best practices.

[McAwesome]

The "Preview" label is misleading and has more to do with Microsoft's labeling than anything.  The Azure team explicitly says it's Production, not Beta.  They've gone so far as to give a JNUC presentation about that just last year.  So this is not "playing in Beta" or "testing a beta product".

What I've tracked it down to is the Jamf website, not the Company Portal application.  Which is why I asked other Jamf admins how they were handling that with their own deployments of this product that Jamf has promoted as part of a Best Practice deployment.

[AJPinto]

I have learned to not trust JAMF integrations. JAMF talks a big game about 0day support, but even for Apple functions it takes JAMF 3-6 months to add support. Something 3rd party like Microsoft may take years for JAMF to add functions for new features beyond the basic frame work.

Jamf Nation Feature Requests

We use SSO with Okta as its less convoluted, on both sides. 

[piotrr]

Cool that you're playing around with the SSOe preview, but that's what it is - a preview. 

Looking forward to see it live though. 

[McAwesome]

Keep in mind that the Azure team uses "Preview" in a different way than you are.  It is live now with support from Microsoft.  It's "Preview" in that it may have bigger changes than other Azure products.  They actually did a JNUC talk last year encouraging people to use it in Production.

[piotrr]

I went to verify what you're saying, and lo and behold, the preview tags have been removed from the SSOe Entra page and the document is in active update. 

Microsoft Enterprise SSO plug-in for Apple devices - Microsoft Entra | Microsoft Learn