Hey all!

After a ‘short’ break I think it’s time to get back into some blogging action. Still wondering what’s wrong with some people in this world, but I’ll leave further politics out of this blog. Way above my cognitive capacity to understand, so let’s try Intune related matter instead.

For this post I’d like to discuss a topic I still see popping up quite often, being: ‘we are seeing -repetitive- jamfAAD prompts on our Intune registered Macs’.

The reason I want to discuss this is because, although there may be an issue on those ‘affected’ devices, there are a few scenarios or factors which may make those prompts 100% expected behaviour. And because I see a lot of people who have some misunderstanding on how the Intune registration for macOS via JPRO works, I think/hope this post may clarify a few things.

First of all, let me drop the relevant articles on how to configure the Intune integration in JPRO here:

Now, there seems to be some mismatch in view of the documentation regarding the required permission changes. The following document states the required changes which has to be made following some enhancements done by Microsoft:

However, looking at the 2 articles above, there is some mismatch in view of the MS article stating “After the app is registered successfully, the API permissions should only contain one permission called update_device_attributes“. This while the same document actually states to add permissions for Intune, MS Graph and Azure AD…

I’m currently working on getting those articles adjusted where needed, and have my permissions set as follows (for the manual configuration), as per the steps mentioned in https://docs.microsoft.com/en-us/mem/intune/protect/conditional-access-integrate-jamf#create-an-application-in-azure-active-directory, which works fine but in view of the recent/upcoming changes regarding Graph and Azure AD API, I think the articles may need some update (at the time of writing this post).

Apart from the discussion on the required permissions here above, I’ll leave the configuration out of today’s post as I want to focus on the real matter I want to discuss, being the ‘jamfAAD prompts’.

However, there is one additional reminder I do want to drop here:

You can only add 1 on-prem JPRO server to an Intune tenant for this integration. This because for on-prem JPRO servers you need to use the manual configuration. For JamfCloud instances you can use the Cloud Connector which does allow multiple JamfCloud instances to be integrated with the SAME Intune tenant. The Cloud Connector is not available for on-prem JPRO servers.

Now, let’s focus on the ‘jamfAAD prompts’. To do so, let’s discuss the process which happens when a device is being registered to Intune via JPRO first.

As we know we need:

Best Practice: For Execution Frequency, Jamf recommends that you select Once per computer. This prevents the policy from running multiple times on the same computer which can cause duplicate Azure AD records

Best Practice: Do Not Enable Conditional Access

Best practice workflows cover common scenarios; however, the following recommendations may not apply in your environment.

Jamf recommends that you do not enable Conditional Access for computers with multiple user accounts. Microsoft Endpoint Manager assigns one User Principal Name (UPN) to a device record. As a result, Jamf Pro will only send active data for one AAD ID per device at a time.

When an end user runs the registration policy in Self Service, the following happens (as per: https://docs.jamf.com/technical-papers/jamf-pro/microsoft-intune/10.36.0/Computer_Regisration_for_End_Users.html)

  1. Company Portal opens and prompts the user to authenticate to MS Azure
  2. If all goes well, the Azure registration happens and the user is presented with a message ‘You’re all set’
  3. After clicking ‘done’ in the Company Portal, it closes, and the jamfAAD prompt appears

At this point a record in Azure AD should have been created already:

Important to highlight here is that this is in AZURE AD and not in Intune/MEM (yet). The device will also report as Compliant – N/A at this stage.

Furthermore, a keychain entry is added containing the “Microsoft Workplace Join Key”. More about this below.

The next step is the jamfAAD prompt, and it’s important to understand what this jamfAAD actually does. To keep it short, the ONLY thing it does is authenticate to Azure AD in order to fetch the Azure Device ID of the registered Mac. Nothing more!

jamfAAD does NOT submit any information to Azure or MEM !

When clicking ‘Continue’ the end user will be prompted again to authenticate to Azure and will be asked to grant access to the macOS Keychain. Important here – as stated in the instructions window – is to click on ALWAYS ALLOW. This because jamfAAD will need access to the keychain items for ongoing checks happening in the background as from now. Both the WPJ key (see above) as the cached credentials for the authentication to Azure:

Once the end user completed this jamfAAD prompt, the registration to Intune is complete. At this point we should have:

  • Azure AD record (still reporting as Compliant – N/A)
  • WPJ key in the macOS keychain
  • Cached credentials for Azure authentication in macOS keychain
  • Still no device record in Intune/MEM
  • Some additional keychain items related to Company Portal and some macOS preference files which are not really relevant for this post

Now, the fact that we don’t have an entry in MEM yet, is totally normal. Even more, it can take time for this to process and for the entry to be created. Why? Well, this is because it’s NOT the device or jamfAAD which is submitting data to Intune/MEM but JPRO (on-prem) or the Cloud Connector (Jamf Cloud). Let’s have a look at this.

Shamelessly stealing a diagram made by a colleague (all credits to Kyle):

Whether it is JPRO directly or via the Cloud Connector is in se irrelevant. The important part here is that jamfAAD is only fetching the Azure Device ID, and submitting that ID to JPRO. What happens next is JPRO (directly or via the Cloud Connector) is then receiving the Azure ID and submitting the inventory data for this device to Intune. The data which is actually send can be found here: https://docs.jamf.com/technical-papers/jamf-pro/microsoft-intune/10.36.0/Appendix_Inventory_Information_Shared_with_Microsoft_Intune.html

In JPRO we can check this data submission in the inventory of the device => History => “macOS Intune Integration Logs” :

Once this data has been sent, JPRO’s job is done, the device should appear in Intune/MEM and -subject to the compliance policies in MEM – be reported as Compliant or Non-Compliant.

That said, it can take quite some time for Intune to process the data submitted by JPRO. This can take up to an hour or even more. Subject to how busy your Azure tenant is, how many Compliance Policies you have, etc…

Once the data from JPRO has been processed by Intune, the device shows up in MEM:

Now, that brings us to the main goal of this post, the jamfAAD prompts. Once we have our device in Azure and MEM, we’re good right? The end user should not get any jamfAAD prompts anymore?

Well, NO ! Even if there is nothing ‘wrong’ with the device or it’s Intune registration, it is entire normal – after some period and/or even repetitively – that jamfAAD will prompt the end user again like this:

The reason for this is per design and actually how jamfAAD works!

Once the initial registration is completed jamfAAD continues to run in the background and has to authenticate every 24 hours to Azure to confirm the Azure AD record is still intact and confirm the AAD Device ID. Why? Well, because it has to report it to JPRO as proof of the integrity of the registration, and the activity of the device.

This is why we have the WPJ key and cached credentials. jamfAAD actually authenticates silently to Azure and uses the items in the keychain to do so. As long as the WPJ key is ok, the Azure AD record is intact, the device is online (to contact Azure), the cached password is valid…. all is well. jamfAAD silently authenticates, gets the Device ID, reports it to JPRO, JPRO sends inventory data to Intune… everyone happy. (Quick note: JPRO only sends an inventory update to MEM when something changed..)

However, whenever this silent authentications fails, for whatever reason, jamfAAD will go into interactive mode and prompt the end user to authenticate again! This is 100% normal and expected behaviour. Furthermore, there are other situations where Azure may even instruct jamfAAD to go in interactive mode, such as an expired MFA lifetime.

In any case, when troubleshooting such scenario, the jamfAAD logs will provide more information:

log show --predicate 'subsystem CONTAINS "jamfAAD"'

I’m not gonna go too much in detail here but in any case where the silent flow fails, you’ll see entries like below and jamfAAD going into interactive mode:

Refresh token wasn't found, user interaction is required.

Creating Error with description: User interaction is required

The token cannot be obtained in a silent mode; the non-silent methods need to be called instead
...

Jamf Support is the place to go in case you need further assistance with identifying why this is happening, but a quick summary of potential reasons are:

  • Device offline for more than 24h
  • Azure AD password changed (hence cached credential invalid)
  • End user created multiple Azure AD records by registering the device multiple times
  • MFA is being triggered because of the MFA token lifetime which expired
  • Keychain issue (corrupted or user did not select always allow when registering…)
  • …

Or any issue with the Mac not being able to contact JPRO and/or Azure… but in a lot of cases the jamfAAD prompts / pop-ups are totally expected!

That said it is mandatory that the end-user does react to the prompt and authenticates to Azure when asked to do so! Failing to do so will result in repetitive prompts (every 2 hours), the device going into unresponsive state and being marked as non-compliant after a certain amount of time (days). More about this below.

I also want to highlight the importance of educating the end-user not to blindly attempt to register their device again to Intune. (see best practice mentioned above, set the registration policy to once per computer). This can result into duplicate Azure AD/MEM device records and break the registration. Unless the device has been moved to State 1 – desactivated as per the JPRO Conditional Access settings.

For all Intune registered devices there are 3 different states a device can be in:

  • State 0 – calculated
  • State 1 – desactivated
  • State 2 – unresponsive

State 0 is the state all devices should normally be in. This means that the device is checking into JPRO every 24h and jamfAAD submitting the Device ID.

State 2 is when a device has not checked in during the last 24 hours and/or JPRO did not get the Device ID. To fix this, the only thing the end user has to do is act on the jamfAAD popup and authenticate while the device is online.

State 1 is either because the device was removed from JPRO (inventory record deleted), or the device stayed in state 2 – unreponsive for more than x days.

And this brings us to the final thing I want to discuss, being ‘the amount of days of inactivity to flag a device as non-compliant’.

In Intune/MEM we have a setting referring to this concept:

However, this setting does not apply to device registered via ‘Partner Device Management’, like our integration with JPRO !

Instead, JPRO has it’s own setting to manage this:

Here in my test setup I’ve set it to 3 days, which means that whenever a devices fails to check in with JPRO for more than 3 days, so 3 days in state 2, JPRO will send and inventory update message to Intune/MEM with STATE 1. Typically around midnight the next day. This however will not just flag the device as ‘non-compliant’, it will remove the device record in Intune/MEM. Hence the device will need to be registered again via Self Service.

Very last thing I really want to highlight is the fact that, whenever you need some clean up of device records in either Intune or Azure AD (for instance when duplicate entries are causing trouble), there are a few things to keep in mind:

Hope this clarifies a few of the things I see some people struggling with. Let me know if I missed anything or if there are any inaccuracies you’d like to see corrected.

That’s it! As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!

Brgds,
TTG