Let’s Get Conditional - Unconditional Love - Part 2

This is the eighth 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. In this post we will also cover automation (to the best of our ability) of removal of items.

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.

Now with more automation!

Disclaimer: Run script at your own risk. Please test before deployment.

1. Run this script to clean up all of the local items on the macOS device pertaining to the WPJ and jamfAAD. Then have the end user logout and back in or reboot to reload the login.keychain.

2. Remove the Azure AD record of the given device.
   Note: An invalidation of the WPJ in the end user’s login.keychain or run of jamfAAD clean command can 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.

3. 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.

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

5. After this clean up is done you can re-register the device using this script to run jamfAAD with no cache and force a new ACL prompt for the login.keychain. 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.

Note:
For some background on the items being removed and recreated. If we look 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.

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