What is the best way to apply Office 355 login to MacBook on Jamf?

[ManagerofVibes]

Hello Jamf friends!

I am new to the IT world, any assistance would be greatly appreciated. 

We have new Macbooks that we would like for users to sign in by using their Office 365 work domain credentials. We have Jamf Pro. What is the best way to do so in Jamf Pro? Any articles or videos would be great. 

Thank you, 

[ManagerofVibes]

*Office 365

[AJPinto]

This is not as simple of an ask as you are probably hoping. MacOS and Windows are fundamentally different, and the manufactures have two vastly different end goals with their products. This process makes about as much sense as logging in to Windows with your iCloud credentials. However, here we go :).

MacOS can be joined to a domain, but don't do it. Apple stopped developing macOS with domain binding in mind over a decade ago, and it is full of problems. The correct way to go is Platform SSO.

Platform SSO has a LONG way to go, but it is macOS's solution for OS authentication with IDP credentials. PSSO is currently only supported by Entra (using the Comp Portal SSO extension which I think is still in preview or was just released), and Okta (using their Okta Verify app which is still in preview). No other IDPs have signed on to use PSSO yet that I am aware of. Configurating PSSO on the Jamf side is simple enough, and I put Microsoft's documentation below. 

Platform Single Sign-on for macOS - Apple Support

Microsoft Enterprise SSO plug-in for Apple devices - Microsoft identity platform | Microsoft Learn

One everything is setup and working, the user can log in to macOS with their Entra credentials. Which should be the same credentials as O356 which meets your goals. I suggest doing some HEAVY research on PSSO before trying to deploy it.

[wakco]

---

@AJPinto wrote:

Platform SSO has a LONG way to go, but it is macOS's solution for OS authentication with IDP credentials. PSSO is currently only supported by Entra (using the Comp Portal SSO extension which I think is still in preview or was just released), and Okta (using their Okta Verify app which is still in preview). No other IDPs have signed on to use PSSO yet that I am aware of. Configurating PSSO on the Jamf side is simple enough, and I put Microsoft's documentation below. 

---

Yes, Microsoft's version was only made Public Preview this month (May 2024), and therefore not considered ready for production. Microsoft currently have this slated for official release in January 2025. See the Microsoft 365 Roadmap for their current plan.

I almost forgot to add, Microsofts documentation is aimed at Intune, not other MDM's. That said I have got it working in Jamf Pro.

[ManagerofVibes]

Thank you for this!! Definitely going to do some more research. 

[ManagerofVibes]

Hi AJPinto, 

I am still figuring this all out. Can I pick your brain on this? 

Jamf Connect seems a bit too complicated for us. We are looking at Intune to apply SSO. I'm confused as to why both Jamf Connect and Intune both require the users to make a local account. Is a local account always required, if so why? I assumed as long as our Admin local account is on a work laptop, the user does not need to create their own local account. 

Kind Regards,

[wakco]

Technically all accounts are local, it's really about defining the authentication authority, and for a laptop with the old AD binding that was why we needed "Mobile" accounts, because they were automatically created local accounts allowing the user to login when the authentication authority is not available. Even with Jamf Connect or PSSO/SSOe (once officially available), they still create a local account, the difference being that when these services are available a person that has never logged into the laptop can login and the services create an additional local account, and when the services are not available, only those people that have logged in previously to the laptop can login, just like the old AD "Mobile" accounts.

[AJPinto]

macOS's SSO extensions are largely disabled when you use a mobile account as apple does not want you domain binding. Yes, I am oversimplifying the disabled comment, but I am trying to be simple. If you want a long explanation I tried to cover it below.

The first thing to understand is macOS is not Windows, don't assume any ideas or fundamentals for Windows apply to macOS in any way shape or form.

On macOS there are generally two account types. You have a Local Account, which is what 99.9% of your accounts will be. Then for domain bound macs you have a Mobile Account or domain account. Generally speaking, under no circumstances should you ever domain join a Mac, so that leaves you with using Local Accounts.

The main difference between local and mobile accounts is how macOS handles authentication and password rotation and what functions of macOS are disabled or enabled.

• Local Accounts will lean on macOS to handle everything and use various SSOe's to handle password rotation and synchronization which Apple is actively supporting and developing for. 
  • MacOS built in extension to allow for password management by AD.
  • MacOS has built in extensions (PSSO) for password management by IDP.
  • MacOS has built in extensions for tools like Jamf Connect to hook in to in order to control password rotation.
    • Though many of these tools are clunky due to needing to unlock the macOS keychain separately from the IPD requiring two separate authentications at times.
• Mobile Accounts will attempt to sync their PW to AD when the user changes the PW locally, and it's a crap shoot if macOS will sync the PW if it is changed remotely.
  • MacOS views itself as the top IDP even of Active Directory, meaning Account changes from other devices or even in AD itself may not be accepted by the Mac.
    • In addition, remote password changes will not update the FileVault password.
  • Apple is no longer developing macOS with Mobile Accounts in mind.
    • If a user forgets their password, you are supposed to use recovery with the FV Recovery key to reset their password, which breaks a mobile account.
  • There are many other example of issues domain binding causes, but these are the most obvious.
  • Many features like macOS's built in password syncs between AD and FileVault are disabled with Mobile Accounts as well as some SSO extensions.

Jamf Connect specifically builds a local account. If you are domain bound, there is no point in Jamf Connect. With Jamf connect, assuming you have already logged in to macOS, the authentication box you see is to verify your credentials against your IDP to allow Jamf Connect to pull your PW change information and generate Kerberos tickets. Jamf Connect will also sync your password if the local and IDP password dont match, this requires you to enter your macOS keychain password to perform. If you are doing everything with Jamf Connect, you should only need to enter your password once.

Intune. I am assuming you are talking about Device Compliance or Conditional Access. The reason you log in to this is to perform Azure registration. Even on Windows, this is a manual process the user must perform and has nothing to do with macOS itself. It's not different then needing to login to a website. Could MS automate this? Sure, but they won't.

SSO on macOS is also performed very differently then SSO on Windows. You can have the Microsoft SSOe (extension) on macOS without registering with Intune. You just need to install the comp portal app, deploy the configuration profile setting up the SSOe and the user needs to log in to any Microsoft service (Office, OneDrive, Edge, whatever) to generate a ticket. Once the ticket is generated the comp portal will use it with anything configured to accept the ticket.

PSSO (Platform Single Sign-On) is the direction macOS is going, this also does not work with domain binding. It will be a couple of years before PSSO is really worth using, but it is the literal replacement for domain binding and has most all the benefits with none of the draw backs. You would need to install the Comp Portal, or any PSSO extension. Once configured with a Configuration Profile, the user simply logs in to macOS with their IDP credentials. It uses AAD groups for admin access, and can accept IDP password rotation (the old PW works still due to strange design desires which is a security concern). The login window for the first time in macOS's history creates tickets, and they can be used to log in to Office, websites or anything else configured to use the tickets. Like with the SSOe, the user never needs to actually log in to the comp portal for this to work. Unless you need to perform Azure Registration for Device compliance. 

TLDR: You should not be domain binding, and certainty SSO is not a reason to domain bind. You need to research how SSO functions on macOS. Install the necessary SSO extensions and configure them, which does not require domain binding. 

[talkingmoose]

It's an additional cost to Jamf Pro, but Jamf Connect was built to do just that. And you can manage it using Jamf Pro.

https://www.jamf.com/products/jamf-connect/

[m_mile24]

We currently have JamfConnect in our environment but ofcourse it lacks the true SSO and other features for PSSO has. Im assuming with PSSO, SSO extension will soon phase out no? 

[ManagerofVibes]

Hi, We have Jamf Connect too! And it does lack the true SSO. Right now, we are testing a Macbook and it currently shows 4 local accounts (one being an admin). It's confusing, I am not sure if I did something wrong. :(

[ManagerofVibes]

What are you experiencing @m_mile24?

[wakco]

No, PSSO is just the macOS side of the equation, something else is still required to make the connection to the authentication service being provided.