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
- Azure AD Admin rights for integration connection via admin consent experience login
- 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.
-
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.