Let’s Get Conditional - jamfAAD Binary and Device State

This is the fifth 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 jamfAAD binary on macOS devices.

TL;DR: Devices that are using the Jamf Pro and Microsoft integration have the jamfAAD binary that gathers the AAD ID from the Workplace Join at Registration and then checks that data daily.

The jamfAAD binary is located inside of the Jamf.app:

/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfAAD.app/Contents/MacOS/JamfAAD

A symbolic link also exists for ease of use at:

/usr/local/jamf/bin/jamfAAD

The jamfAAD binary is called at registration. In a previous post I covered the registration process client side the use of jamfAAD in the process is to launch Company Portal.app as the end user in registration mode, and to then listen for the Company Portal.app exit code. After that jamfAAD will run a gatherAADInfo command to procure the AAD ID from the registration as well as verify the WPJ key created in the process (that will be used for later Conditional Access authentication).

More on the commands found in the binary as of v10.21.0:

JamfAAD collects device and user Azure Active Directory ID values and reports them to the Jamf Pro server.

Usage:

JamfAAD [-verbose] <command>

Available Commands:

clean - Removes the Azure AD token from the user's keychain and the user's preferences from the preferences directory

gatherAADInfo - Collect AAD information and send it to Jamf Pro server; use -disable-cache-read to always connect to Azure

help - Print this help message

registerWithIntune - Launches Microsoft Company Portal. If user successfully registers with Intune, gatherAADInfo runs.

version - Print the version of JamfAAD

Global Flags:

-verbose - Shows extra information

However; jamfAAD’s story is not done there. Each day (24 hour period) a subsequent run of the gatherAADInfo command needs to take place to verify that the WPJ key is still intact, and the device is healthy and the user is active. That is done by a LaunchAgent that runs at user login and reoccurring after that first tigger when the user session is active (to learn more about LaunchAgents go here for a great write up).

The LaunchAgent is located at:

/Library/LaunchAgents/com.jamf.management.jamfAAD.agent.plist

What that daily check does is allow for the device to know what state the WPJ key is in. That information is then sent to Jamf Pro to calculate the state of the device. The state is an attribute used in internal calculation and sent to Azure. Azure then uses those values to either calculate compliance or not.

The state values:

0 == Active/Calculated

A 0 would be a newly registered device, a device that has been running a gatherAADInfo daily, or a device coming back from Unresponsive (2) after a gatherAADInfo command run (and Jamf policy check-in (but often if a device is online that will happen at the same time if not before the jamfAAD run))

1 == Deactivated

A 1 would be a device deleted or retired from Jamf Pro. This is sent to Azure so that the compliance is no longer calculated. So the record in Intune would not be present, but the Azure AD record would remain as the the Jamf integration does not remove that record created by Company Portal.app.

2 == Unresponsive

A 2 would mean that the time of last recurring check-in is more than 24 hours ago. The device would still be sent for calculation but after many days (greater than 30) of being in an Unresponsive (2) state the device would be marked as Deactivated (1).