Skip to content

Jamf Conditional Access Prompts and Troubleshooting Deactivation

Jump to bottom
benwhitis edited this page Jun 5, 2024 · 5 revisions

Background

NOTE: The recurring gatherAADInfo was removed in Jamf Pro 11.5. Much of this document does not apply to 11.5 and higher.

When computers are registered using the Jamf Pro Intune integrations (Conditional Access or Device Compliance), a client-side agent called "Jamf Conditional Access" (formerly JamfAAD) is configured to run a recurring silent authentication against Entra ID every 2 hours. If the silent authentication fails, it will fall back to an interactive authentication. If the interactive authentication also fails, the device will be marked non-compliant and will become deactivated.

This guide will cover broad troubleshooting patterns and the most common scenarios that result in either frequent prompts, or deactivated computers.

Breakdown of relevant components

Before diving in, here's a definition of some of the components involved in the recurring authentication process:

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

This LaunchAgent is created when the computer is initially registered. It is configured to run every 15 minutes. When it runs, it checks to see if a successful authentication has run within the last 2 hours, and if not, it will call Jamf Conditional Access.app with the gatherAADInfo verb.

/Users/$USER/Library/Preferences/com.jamf.management.jamfAAD.plist

This user-level preference file is created when the computer is registered. There are two key-value pairs that are relevant to this guide:

  • last_aad_token_timestamp: This is the epoch of the last time a successful authentication was completed by Jamf Conditional Access.
  • have_an_Azure_id: This indicates whether the last gatherAADInfo run resulted in a successful authentication. If the value is false (0), then the LaunchAgent will not call the recurring authentication every 2 hours. The computer is in a deactivated state, and a manual gatherAADInfo must be called to re-activate it.

/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/Jamf Conditional Access.app/Contents/MacOS/Jamf Conditional Access

This is the executable called by the LaunchAgent. This executable is also called by the registration policy.

There are two commonly used verbs:

  • registerWithIntune: This launches Company Portal in registration mode, and then performs a gatherAADInfo after Company Portal closes
  • gatherAADInfo: This calls the silent authentication against Entra ID. If the silent authentication fails, it will fall back to an interactive authentication. Important note: When the LaunchAgent runs, it also includes the optional -recurring flag when calling gatherAADInfo. This does two things:
  1. If have_an_Azure_id is false, no authentication will occur
  2. If it has been less than 2 hours (last_aad_token_timestamp), no authentication will occur.

/Library/Preferences/com.jamfsoftware.jamf.plist

This PLIST contains, among other things, the Entra ID tenant ID, and the client ID of the application that Jamf Conditional Access will authenticate against.

The App ID will always be one of these 3 app ID's, depending on the integration and connection type:

55d611b0-7d33-4d38-8df3-6041868930d7 - macOS Native Connector - Conditional Access manual connection

dd4f1d11-1200-4a1c-bccf-cb13e27467e6 - Cloud connector user registration app - Conditional access cloud connector

b03c10a8-71c7-45f9-b44a-3335ab76e970 - User registration app for Device Compliance

Machines going deactivated

There are two parts of every deactivation:

  1. Something causes the silent authentication to fail
  2. Something causes the interactive authentication to fail. When this happens, the com.jamf.management.jamfAAD.plist value have_an_Azure_id will flip from true to false, leaving the computer in a deactivated state. A blank AAD token will also be sent to Jamf Pro, which will result in the computer becoming non-compliant in Entra ID.

There are a lot of things that can cause this, and identifying the cause is crucial to preventing it from happening again. Jamf Conditional Access writes logs to the macOS unified logging system. Jamf Conditional Access + SSO extension logging can be retrieved using this command: log show --predicate 'subsystem CONTAINS "jamfAAD" OR subsystem BEGINSWITH "com.apple.AppSSO"' > ~/Desktop/JamfConditionalAccess.log

A few search terms to start with:

  • AAD ID: This filter in Console.app should return a list of every time a recurring authentication was successful, and when it failed. The successful authentications will look like this:

Jamf Conditional Access: [com.jamf.management.jamfAAD:workflow] AAD ID acquired for macOS user account test.user

A failed authentication/deactivation event will look like this:

Jamf Conditional Access: [com.jamf.management.jamfAAD:workflow] No AAD ID found for macOS user account test.user

Note: If there is no line like this in the log, AND the /Users/$USER/Library/Preferences/com.jamf.management.jamfAAD.plist shows have_an_Azure_id is false, the logs likely have rolled over before they were collected.

  • acquireTokenSilent: If the silent authentication fails, it prints a line like this: acquireTokenSilent returning with error:

  • acquireTokenInteractive: If the interactive authentication failed, it prints a line like this: Did not get a token from acquireTokenInteractive, sending an empty token.

Common scenarios

There are three common scenarios that lead to deactivation.

SSO Extension Issues

In Jamf Pro 10.50 and higher, Jamf Conditional Access relies on the SSO extension for silent and interactive authentications. In certain network environments, the SSO extension may return an error code that causes Jamf Conditional Access to fall back to interactive prompts very frequently.

If the user fails to complete the interactive prompt, the machine will become deactivated. Due to the high frequency of the prompts, it is very likely that users in this scenario will eventually become deactivated due to either prompt fatigue, or simply missing it when it appears.

In the logging command above, messages like this will be very frequent:

error = Error Domain=com.apple.AppSSO.AuthorizationError Code=-9 "not AppSSO URL" UserInfo={NSLocalizedDescription=not AppSSO URL}, requestParametersCore = {

This will likely be appearing for more than just Jamf Conditional Access. If it's impacting Jamf Conditional Access, it's most likely also impacting Teams, Edge, Safari, Outlook, OneDrive, etc.

To resolve this issue, ensure your network meets the requirements detailed in this Microsoft document: Microsoft Enterprise SSO Plugin For Apple Devices - Network Requirements

Be aware, there is a known issue with macOS that makes it more sensitive to proxying on domains that should not matter. This is fixed on macOS 14.3, where only these two domains need to be excluded from proxying/inspection:

  • app-site-association.cdn-apple.com
  • app-site-association.networking.apple

Invalid grant

It's also common for the silent authentication to fail with some response from Entra ID with the invalid_grant message. This indicates that there is some requirement applied to the user/app that could not be met by the silent authentication.

Jamf Conditional Access: [com.jamf.management.jamfAAD:msal] TID=12345 MSAL 1.2.14 Mac 14.3.0 [2024-01-01 00:00:00 - 7F6779F2-640C-4FB2-9462-B16C102CF61C] Processing an AAD error with error code -51412, error invalid_grant

To find out more about this response, we'll need to look at the Entra ID sign in logs. Go to Entra ID -> Users -> Pull up the user in question -> Sign-in logs. Filter by the app name (all the possible app names are defined toward the beginning of this doc), and look for authentications that match the timestamp of the client-side log. If you find the failed or interrupted sign-in, it should contain more information about why the silent auth failed.

Reducing the failure rate of the silent authentication will reduce the rate of interactive prompts. Because the user only has to fail the interactive auth a single time to become deactivated, cutting down on silent failures is crucial.

Multiple MSAL accounts (Fixed in Jamf Pro 11.3)

If you're seeing this specific behavior, Jamf Pro 11.3 has enhancements that enable Jamf Conditional Access to pick the correct account every time. Please upgrade to 11.3 or higher!

This one is most likely to occur in environments where users may use multiple Entra ID accounts throughout the day, or environments where users were recently migrated from one Entra ID tenant to a different one.

When Jamf Conditional Access performs the recurring silent authentication, it first must retrieve the correct account from the MSAL cache. However, if multiple accounts are returned, it's possible for Jamf Conditional Access to pick the wrong one.

The logs may contain this message (note this is a debug only message, so it won't show up unless --debug is included in the log show command): Jamf Conditional Access[7756:20d5a] [com.jamf.management.jamfAAD:azure] More than 1 account, will try to find a matching account.

There is some element of chance to this behavior, so it's possible that Jamf Conditional Access will pick the correct account, and nothing will happen. Other times, it may consistently pick the wrong account, resulting in frequent interactive prompts.

This one can be identified by an extension attribute like this: DuplicateMSALAccountEA

Unfortunately, the only way I've found to clear out the multiple MSAL accounts is to delete the Local Items keychain and reboot the machine. This has some drawbacks, as the Local Items keychain is used to store things like ssh keys that the user may not have backed up. While it's not as disruptive as wiping the Login Keychain, I'd recommend erring on the side of caution, only deploy this script to computers where users have complained about the prompts and understand what is going to happen.

The user will receive one last prompt to sign in to Jamf Conditional Access. Because the Extension Attribute is looking at a log show over the last 5 days, it's possible machines will remain in Multiple accounts found status for up to 5 days after running the clean-up.

Clone this wiki locally