Let’s Get Conditional - Unconditional Love

This is the seventh of a multi-part series about the macOS Intune and Azure AD integration for inventory data and Conditional Access with Jamf Pro.

The topic of this post is explaining the macOS device de-registration process, or in another sense making them unconditional. The process of removing the relevant bits local on macOS devices as well as server side.

TL;DR: The macOS device needs to run a jamfAAD clean command to stop the check-in. More data exists in the login.keychain, but the clean command will stop any end user prompts. As for UPN scope and server side that can be done in the Partner Device Management blade and in Jamf Pro’s settings, but that is too long for an already too long TL;DR.

"The MacAdmin Gave, and the MacAdmin Hath Taken Away" (Jobs 19:84)

Looking back to the registration process on the macOS client we know that during the process several items, and one of particular importance is placed on the device in the registered end user’s login.keychain. The most important being the WPJ key that is used by jamfAAD and Microsoft applications (Office, OneDrive, Teams, etc.) as part of the authentication process to check conditional approval against. However; other items are created by the Azure AD logins that are completed.

login.keychain contents after registration on fresh macOS device with all of the registration related items selected.

In a removal of the registration we would need to remove these items from the end user’s login.keychain client side. This can be done via Keychain Access it can also be done via terminal using the security binary like Kyle E does with his script here. However; removing that does not clean the Azure side records. Server side actions need to take place for a full clean slate.

To break this down here is what the workflow would roughly look like for a removal and re-registration:

1. Run jamfAAD clean command to stop the check-in of the agent. (Note: This command would need to be run as the end user. jamfAAD must always be run as the end user not as root or elevated as sudo as that would point to roots processes and login.keychain.

2. Clear out the end user’s login.keychain client side (as seen in screenshot above).

   1. Items to be removed:
      MS-ORGANIZATION-ACCESS certificate
      com.microsoft.CompanyPortal.HockeySDK
      com.jamf.management.jamfAAD
      com.microsoft.CompanyPortal
      enterpriseregistration.windows.net
      https://device.login.microsoftonline.com
      https://enterpriseregistration.windows.net
      com.microsoft.workplacejoin.thumbprint
      com.microsoft.workplacejoin.registeredUserPrincipalName

3. Remove the Azure AD record of the given device. A invalidation of the WPJ in the end user’s login.keychain and run of jamfAAD clean command will change the device state (more on device state here) to 1. This will cause a removal of the Intune/MEM device record as the compliance engine sees a state of 1 knowing that it does not need to calculate compliance. The AAD record is created by Company Portal.app, and jamfAAD does not have rights to remove that nor does the Jamf Pro enterprise sync app.

4. Verify no duplicate records exist in Azure AD or Intune/MEM from previous registrations that were not cleaned 100%, and if they do also remove those. (Note: Each time a WPJ registration is called Company Portal.app may create a new AAD record. In CP.app v2.6 and higher changes were made to try and mitigate duplication if a registration is run over the top of an existing record. This was an improvement but not a catch all.)

5. Wait 5 to 10 min. for the deletions to full propagate Azure side.

6. After this clean up is done you can re-register the device then. No Jamf Pro side clean up is needed as the device will send the new AAD ID for the given user record and Jamf Pro will use that latest ID to post to Azure as the active ID.

What about having a user NOT routed to the Jamf integration registration?

Let’s say you have end users that you want to not get be able to register using the Jamf policy and Company Portal.app. That is possible via the Partner Device Management blade in Microsoft Endpoint Manager.

The PDM blade with the connection settings area.

In the Connection Settings area under the PDM App ID field you will find groups to include and exclude. If you exclude a group any UPNs in that group will NOT be able to register with the Jamf policy. However; they will be able to use Company Portal.app to enroll into Intune/MEM as an MDM then. Keep in mind this goes for any device that that UPN is used with. Since the first info Company Portal.app gets at launch is the UPN. Not the device. So you can not be granular with say Device A is in Jamf and registered but Device B is a direct MDM enrollment.