Microsoft Conditional Access via Partner compliance management

Overview

Ensuring end users access organizational data from a trusted device is crucial to many security best practices. Combining Microsoft Conditional Access to validate the user, in conjunction with Addigy to secure the device, allows Apple admins to verify corporate assets are accessed securely.

Please also check out Addigy Device Compliance, as it is a key part of the Conditional Access solution, and how Macs are calculated as compliant or not.

Also, see Microsoft Conditional Access using Certificates for a Conditional Access workflow 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, Microsoft Conditional Access will check the Entra Device ID of the device making the request (provided in the access request via the Workplace Join (WPJ) certificate) and its Compliance State as sent over to Entra from Addigy as part of the Partner compliance management integration.

Requirements

Entra ID (formerly Azure AD) (P1 or P2) subscription plan with Conditional Access (More information)
- Entra ID (formerly Azure AD) Admin rights for integration connection via admin consent experience login
  - Domain, Global, or Application Admin rights
Microsoft Enterprise Mobility + Security (E3 or E5) for users to preform the WPJ device registration (Find more info here)
Entra ID (formerly Azure AD) User Group for desired Device Compliance registration users
- Note: This group must contain all prospective macOS MSFT CA users and current users, users can not be removed post registration as this will cause API post failures on device info updates at check-in or state change
Addigy Account using Addigy MDM
macOS devices on macOS v11.0 and up
Addigy Compliance 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 - Single and Multi Tenant Steps

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 (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. If All Users is selected in the following section (Addigy integration connection steps) you will need to get the Object ID for All Users. This Object ID for the All Users group can be obtained by contacting Addigy support.
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 - Single Tenant (Addigy Organization Level)

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 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 and Group 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. After that has been accepted the Addigy Compliance enterprise application will be made in Azure. This App will have the Application ID of 6bbb2957-99e2-4457-9269-0da766ba04e9.
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.
The connection is now setup and devices will be able to register if they have the SSOe deployed and have Addigy Self Service deployed.

Connecting Addigy to Azure - Multi Tenant (Addigy Policy Level)

With Intune listening for service partner activation from the Microsoft API enabled with Addigy as a partner, let’s start the Addigy to Azure connection

Navigate to the desired policy for integration then Integration & Settings > Integrated System (tab) > Intune
Input your Azure AD Tenant ID in to the Tenant ID box. Then input 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.
With your Azure AD Tenant and Group 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 a green title bar signifying 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.
The connection is now setup and devices will be able to register if they have the SSOe deployed and have Addigy Self Service deployed.

Configuring Self Service for End User Registration - Organization & Policy Level

The last configuration step needed to enable end users is to perform the registration on device so that they can get their device Entra/AAD ID and login.keychain Entra/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 - Organization and Policy Level

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

The values to add are:

Extension ID: com.microsoft.CompanyPortalMac.ssoextension
Type: Redirect
Team ID: UBF8T346G9
URLs
- https://login.microsoftonline.com
- https://login.microsoft.com
- https://sts.windows.net
- https://login.partner.microsoftonline.cn
- https://login.chinacloudapi.cn
- https://login.microsoftonline.us
- https://login-us.microsoftonline.com
Extension Data: Microsoft
- App Allow List
  - com.apple.Safari
  - com.addigy.MacManage
  - com.microsoft.CompanyPortalMac
  - If Chrome is used
    - com.google.Chrome
- App Prefix Allow List
  - com.apple.
  - com.addigy.
  - com.microsoft.
  - If Chrome is used
    - com.google.

FAQ

How often is data sent to Microsoft from Addigy?
- Data is sent on an individual device basis. When a device audit completes (takes place every 5 minutes out of the box) and there is a change in any data (EX: passcode settings, FileVault 2 Status, etc.) that causes a calculation from the compliance engine either making the device compliant or not complaint that data is sent to Microsoft's Partner API to update the Entra device record. It can take 60-90 seconds on average for Entra to get that data and update the record.
- There is also a heartbeat that the partner service principal sends basically stating "hey, I am here if I had any data about any of the devices I would have sent them already assume that all these devices are in the state they are in now unless I say so". If that heartbeat for the API connection is ever lost after 30 days the device are assumed non compliant. This heartbeat is the date time that can be seen in endpoint.microsoft.com > Tenant Administration > Connectors and tokens > Cross platform > Partner compliance management.

Troubleshooting

Looking for more info about the Device Registration process? Use the macOS Unified System Logs output to see what is taking place for MacManage at registration:
- sudo log stream --level=debug --predicate 'subsystem contains "com.addigy"'
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.
Company Portal is getting re-installed and moved on the device
- Cause: The Conditional Access integration deploys its own version of Company Portal and moves any existing version into an Addigy directory as well as keeps it up to date. If you are also deploying Company Portal from your policy this may cause some issues with a loop. You do not need to deploy it as a standalone as the integration only uses Company Portal at the time of registration and then never again (unless re-registration takes place from a login.keychain reset or deletion where the device WPJ cert. is removed).
Microsoft Single Sign On Extension failing to preform the WPJ
- The SSO extension framework from Apple and the Microsoft Enterprise SSO Extension built on it require that certain domains are exempted from TLS interception/inspection (also known as break and inspect proxying).
  - Steps to resolve this in linked Microsoft KB