Configuring Microsoft Enterprise SSO plugin on iOS devices using settings catalog in Intune

-
 

Microsoft Enterprise SSO plug-in for Apple devices is a great way to have device-wide single sign-on (SSO) for all apps and websites in a consistent, secure, and seamless way. As part of Apple's Authentication Services framework, SSO plug-in reduces the number of authentication prompts users get when using devices managed by Intune and providing single sign-on (SSO) to apps and websites that use Microsoft Entra ID for authentication, including Microsoft 365. Apple's enterprise SSO framework ensures that only an approved SSO plug-in works for each identity provider by utilizing a technology called associated domains. To verify the identity of the SSO plug-in, each Apple device sends a network request to an endpoint owned by the identity provider and read information about approved SSO plug-ins. Once set up, apps that support the Microsoft Authentication Library (MSAL) automatically take advantage of the Microsoft Enterprise SSO plug-in.

The Enterprise SSO plug-in is currently a built-in feature of the following apps:

- Microsoft Authenticator: iOS, iPadOS
- Microsoft Intune Company Portal: macOS

The Microsoft Enterprise SSO plug-in for Apple devices offers the following benefits:

- It provides SSO for Microsoft Entra accounts across all applications that support the Apple Enterprise SSO feature.
- It can be enabled by any mobile device management (MDM) solution and is supported in both device and user enrollment.
- It extends SSO to applications that don't yet use the Microsoft Authentication Library (MSAL).
- It extends SSO to applications that use OAuth 2, OpenID Connect, and SAML.
- It is natively integrated with the MSAL, which provides a smooth native experience to the end user when the Microsoft Enterprise SSO plug-in is enabled.

In this blog post, I will be covering the configuration required for setting up SSO for iOS devices. 

Pre-requisites

- The device must support and have an installed app that has the Microsoft Enterprise SSO plug-in for Apple devices.
- iOS 13.0 and later requires Microsoft Authenticator app to be installed.
- The device must be enrolled in MDM, for example, through Microsoft Intune.
- Configuration must be pushed to the device to enable the Enterprise SSO plug-in. Apple requires this security constraint.
- Apple devices must be allowed to reach to both identity provider URLs and its own URLs without additional interception. This means that those URLs need to be excluded from network proxies, interception and other enterprise systems.

Intune Configuration

Using settings catalog, organizations can take advantage of the shopping cart experience and choose the settings they want. There are some settings which I recommend configuring at a minimum. Process is as follows -

2. Browse to Devices –> Configuration
3. Click Create -> New Policy
4. Select Platform as iOS\iPadOS
5. Select Profile type as Settings catalog
6. Provide a Name and hit next.
7. Click on Add settings.
8. Configure the following -




9. Assign to a device group and\or use filters for assignment.

End user experience

Microsoft Authenticator app must be installed on the end user's device even if they are not using it.

After users sign in successfully, the extension is automatically used with the help of a bootstrap to sign in to any other supported app or website.

The pushed configuration can be accessed under MDM management profile.


For a managed application like Edge, when the end user tries to access portal.office.com, then the user automatically signs in using SSO configuration. I am using InPrivate session to ensure the credentials are not already cached in the browser.


For a non-managed application like Safari, when the end user tries to access portal.office.com, then the user is automatically signed in. I am using the private browser session in Safari as well.


Lastly, you can do a compliance check of the policy in Intune.


Final thoughts..

As part of the Apple's Enterprise SSO, Microsoft Enterprise SSO plug-in is both seamless and secure. It can be enabled for both managed or specific apps with variety of configuration. It also supports conditional access policies. I am intrigued by its various applications and shall be exploring relevant use cases where SSO can play pivotal role in enterprise device management.

References:

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){              ...
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from st...
Read more

Intune: Configure Printers for Non-Administrative Users

-
Image
Configuring printers for end users or giving them the ability to do it themselves is a normal requirement for organizations. Now if your users are Administrators, then the configuration can be straight forward, but in case of Non-Administrators there are additional steps required as Non-Administrators will not be able to add a driver in the driver store despite being able to install a printer. In this blog, I will cover the steps that I took to address this requirement using Intune. The setup involves 2 steps -  1. Setup registries. 2. Install the driver and configure the printer Setting up registries – The registries that need to be configured are actually part of a GPO setting – Allow non-administrators to install drivers for these device setup classes It can be found under: Computer Configuration -> Policies -> Administrative Templates -> System -> Driver Installation I used a Powershell script to set the values and wrapped it in a Win32 application. $P...
Read more