Give your users a better sign-in experience with the macOS Microsoft Enterprise SSO plug-in

With the Intune release from October 2020, the macOS Microsoft Enterprise SSO plug-in became available (in preview). The plug-in is designed to provide a better sign-in experience by limiting the authentication prompts a user gets on his macOS device when accessing Azure AD connected applications.

The SSO plug-in allows any application to participate in single sign-on even if it was not developed using a Microsoft SDK like the Microsoft Authentication Library (MSAL).

In this post, I show the settings I used for testing, which provides an SSO experience for the Safari browser and the Pulse Secure VPN client (which also uses AAD authentication).

The minimum supported macOS version on which the extension supports is 10.15.

Create an Device features Profile

As written in the documentation we should use the sso app extension type Azure AD.
To configure the Microsoft Enterprise SSO plug-in for apps that don’t use MSAL we can provide the App bundle ID in the profile. In the documentation also two additional settings are found to further reduce the number of authentication prompt.

The settings to configure the plug-in are found in the Device features profile.

• Sign-in to the Endpoint Manager admin center
• Browse to Devices – macOS
• On the Configuration Profiles tab click +Create profile

• Choose Device features as Profile type
• Click Create

• Give the configuration profile a Name
• Enter a Description (optional)
• Click Next

• Scroll down and open Single sign-on app extension
• Select Microsoft Azure AD as sso app extension type

Provide the App bundle IDs of the apps that don`t support MSAL

You can look up the bundle IDs by running this in Terminal:

osascript -e 'id of app "Name of App"'

For example

osascript -e 'id of app "Microsoft Outlook"'

Enter these two keys, for both choose Integer as Type and enter value 1:
browser_sso_interaction_enabled
disable_explicit_app_prompt

Finish the setup wizard by assigning the profile to a security group of choice.

End-user experience

Time to have a look at the end-user experience.

I tested several Office 365 apps with and without the profile applied, and with and without the app IDs added to the profile. For the first Office app you need to sign-in with full credentials. As soon as you`re signed in to the first app of the Office suite, you don`t need to provide any credentials or only the username in the other apps. The policy seems to not change anything in that behavior. I expected to auto sign-in to the very first app and so on.

For the Pulse VPN client which I used for testing as a third-party app, there is a big difference in the sign-in experience. Without the policy applied, the username and password need to be applied for authentication. With the policy applied, I get a real SSO experience.

Also for Safari, I see a real SSO experience when the policy is applied, which we don`t see without the policy.
The SSO experience with the Safari browser is shown below. I signed out from Office 365, choose to forget the account and closed Safari. After starting Safari, I still get an SSO experience.

I also tested the new Microsoft Edge browser (version 87), with different settings without much luck to get an SSO experience. Until I installed and used the Beta (v88) and Dev (v89) versions of the browser. When signed in to the browser, you finally get an SSO experience when visiting Office 365. But still, I needed to sign-in to the browser itself.

The feature is still in preview and as more apps might support MSAL in the future, user experience might get better for more and more apps.

For now, happy testing and let me know your experience with the SSO extension.

Update January 2021:

At this moment only the Company Portal and Microsoft Teams app support MSAL. The other apps from the Office suite should get MSAL support later in 2021.