Microsoft Conditional Access via Partner compliance management – Addigy

Overview

Ensuring that end users are accessing organization data on a trusted organization device is a key component to many best practice device security practices. Combining Microsoft Conditional Access to validate the user, in conjunction with Addigy to secure the device, allows Apple admins to make sure corporate assets are being accessed in a secure manner.

After this article please check out the Addigy Compliance Engine as it is a key part of the Conditional Access solution, and how the macOS devices are calculated as compliant or not.

Also, see Microsoft Conditional Access using Certificates for a workflow for Conditional Access that does not require Microsoft Enterprise Mobility + Security (E3 or E5).

High Level Technical Overview

Using Addigy’s Compliance Benchmarks and Azure Conditional Access, only devices registered to users and marked as compliant will be able to access data and apps that are behind a configured Conditional Access policy. When the Corporate Conditional Access controlled resources are attempted to be accessed, Azure Conditional Access will check the Azure Device ID of the device making the request (provided in the access request via the WPJ (Workplace Join) certificate) and its Compliance State as sent over to Azure from Addigy as part of the Partner compliance management integration.

Note: Currently, Addigy supports one Azure Tenant ID per Addigy account. Multi-tenant support is in development.

Requirements

Azure AD (P1 or P2) subscription plan with Conditional Access (More information)
- Azure AD Admin rights for integration connection via admin consent experience login
  - Domain or Global Admin
Microsoft Enterprise Mobility + Security (E3 or E5) for users to preform the WPJ device registration (Find more info here)
Azure AD User Group for desired Device Compliance registration users
Addigy Account using Addigy MDM
macOS devices on macOS v11.0 and up
Addigy Compliance Engine is setup and enabled with at least 1 benchmark and 1 rule in said benchmark
- (The act of having this calculation done against the device record is what send the device record data to Microsoft Azure once the device is registered)
Conditional Access Policy is NOT set to All Cloud Apps
- (This will block the User.Read used by Microsoft Partner Compliance API to verify the user at the time of registration)
Deploy Azure AD Single Sign-on Profile to macOS Device

Technical Workflow

Below we discuss the technical workflow connecting Addigy and Azure as part of the Microsoft’s partner compliance management integration, setting up the user one time Conditional Access registration (WPJ (Workplace Join)) workflow in Self Service, and setting up Conditional Access Policies that grant or deny access based on the device state sent over as part of the registration.

Enabling Partner compliance management for Addigy

The first step needed to allow for the integration connection between Addigy and Azure is to add Addigy as a partner

Navigate to endpoint.microsoft.com
Open the Tenant Administration blade (what is a blade?)
Open the Connectors and tokens blade
Open the Cross platform > Partner compliance management blade
Chose Add compliance partner to start the partner wizard
Select Addigy from the Compliance partner dropdown in the wizard
Select the macOS platform from the Platform dropdown
Click Next to advance
Select the desired user group that will have Workplace Join and Registration ability. If desired this can be a group you define (ex: An organization Department that dynamically updates in Azure AD, a static group of testers you manually add to a user group, or a specific user). This can also be assigned to All Users so that any member of this Azure AD tenant could preform the registration and have their device become compliant. However; please contact support to obtain the ID of this object for step # of the Connecting Addigy to Azure/Intune Partner compliance management section.
Note: Please take note of the group selected. You will need the Object ID of that group next.
Click Next to advance
Review your configuration and confirm and save the configuration via the Create button
The endpoint.microsoft.com session can now be closed as the Addigy partner connection is enabled and waiting for the Addigy side activation and first service heartbeat.

Connecting Addigy to Azure/Intune Partner compliance management

With Intune listening for service partner activation, let’s start the Addigy to Azure connection

Navigate to Account > Integrations > Third Party Add-Ons > Microsoft Intune
Input your Azure AD Tenant ID in to the Tenant ID box. Then input the the Group Object ID of the group you selected in step #9 of the prior section.
Note: Clicking Find in Azure will take you to the respective landing pages for the tenant info that holds the Tenant ID and the Groups blade so you can search. Then copy and paste the Group ID.
Optional: If you want to present users an internal KB if they are not enrolled in Addigy and attempt to access Microsoft Conditional Access content you can set that URL here.

Note: The Tenant ID can be found on the Azure AD portal home screen:
With your Azure AD Tenant ID entered, click the Connect button.
In the window that opens for the Azure AD Admin Consent Experience Sign-In, perform an Azure AD sign in with an account with proper admin rights to grant domain or global consent to the partner app. After you are signed in click the Accept button to allow the integration.
The integration will now process and connect the needed services. Once that process is complete the UI will show the following green signifiers that the integration connection was successful. Additionally; endpoint.microsoft.com > Tenant Administration > Connectors and tokens > Cross platform > Partner compliance management will show the Addigy partner listed and with a successful heartbeat as shown in the following example.

Configuring Self Service for End User Registration and Microsoft SSOe

The last configuration step needed is to enable end users to preform the registration on device so that they can get their device AAD ID and login.keychain AAD certificate to use for browser and app sign in at Conditional Access posture and prompt.

Navigate to your Policies
Select the desired policy
Click on the Self Service Tab
Click on the desired Self Service configuration
Edit the Self Service configuration via the Edit Configuration button
Under the Integrations section check the box to enable the Intune integrations inside of Self Service (lower left corner of Self Service app)
Click Save and Review then confirm that change for deployment
Device will now see the registration workflow option in Self Service after policy deployment

Extensible SSO

To reduce the number of sign-ins and support the security changes in place after May 2023, please configure the SSOe profile for Microsoft apps and browser sessions. Use the Microsoft prescribed values in the Extensible SSO profile payload found in Addigy. Read more

Troubleshooting

Devices that have been registered do not show in Intune
- This is expected. The PCM API integration does take place in Intune, but the device records are Azure/Entra REGISTERED only. They are not Intune ENROLLED. Thus the records only show in Azure/Entra.
After inputting your Azure Tenant ID and attempting to connect you get an error on the redirect and admin consent sign-in on Azure:
- Cause: The first section of this setup workflow was not completed properly when enabling Partner compliance management for Addigy as a compliance partner. If that is not added the API will not have rights to call out for setup. Additionally; it it was just added recently (as it would be for this process) you might need to re-run the connection again as there can be a slight delay in the accepted registration of the connection.
Device/User can not register because the device is stated to not be compliant, but you are attempting to register the device to make it compliant (chicken and egg problem).
- Cause: This is expected if All Cloud Apps is configured for the Conditional Access policy since any User.Read to Azure AD is going to invoke the core frameworks that encompasses All Cloud Apps. Here is the Microsoft KB that calls out the inability to use User.Read apps when App Apps is blocked.
  
  The best practice is to not use All Cloud Apps but add any enterprise apps that users have rights to.