One thing which has been around for quite some time now, and stayed way to long on my blog-to-do list is: Integrate Microsoft Azure Intune in Jamf Pro. So, time to get that done!

Goal of this blog is to go through Microsoft’s tech article which you can find here and achieve macOS compliance goals as discussed here.

Let’s go and see if we can identify any roadblocks or gotcha’s while doing so.

First things first, the pre-reqs:

– Microsoft Azure
– Jamf Pro 10.1.0 or later
Company Portal app for macOS
– macOS devices with OS X 10.11 Yosemite or later
Microsoft Intune licenses

If needed, get an Enterprise Mobility + Security E5 trial here.

The company portal is quite straight forward. Just download the pkg from the link in the pre-reqs, upload it to your Distribution Point, and create a policy to deploy and install it to your devices.

But, important to know is that, in order to register the devices correctly in Intune, the Company Portal should NOT be executed manually. Instead we need to create a SELF SERVICE policy which triggers the Company Portal to run, followed by some additional configs. We’ll come to that below.

Let’s start on the Azure side of things. Here we’ll need to create an app, which Jamf Pro will connect to, and grant Jamf Pro access to provide inventory information about the devices.

To create the app, go to: Azure > App Registrations and click ‘New Registration’.

Give the app a name, select “Accounts in this Organizational Directory only” as supported account types, and add your Jamf Pro URL as a ‘Web’ URI (Full URL in the format of https://FQDN).

Click Register, and you’ll be brought to the overview page of your new app. Here you can already copy the ‘Application Client ID’, which we’ll need to add in a couple of other places later. Copy it to temporary note somewhere for easy access.

Next, we’ll go to ‘Certificates and Secrets’, where we need to create a new Client secret. This will be used by Jamf Pro to connect to the app when uploading inventory information for the registered devices.

Note:
We don't need to assign any users to this app. Opposite to other Azure integrations, like Jamf Connect, it's Jamf Pro connecting to the Azure app via this secret, not the users using theMac.

Click on ‘New client secret’, give the secret a name and an expiry period, and click add.

Note:

If the client secret expires, you must create a new client secret in Azure and then update the Conditional Access data in Jamf Pro. Azure allows you to have both the old secret and new key active to prevent service disruptions.
IMPORTANT NOTE:
Immediately copy the displayed secret to your temporary notes before leaving this page. As you can see below, you can't retrieve the secret later. If you forgot to write it down somewhere, you will need to create a new one. Not a big deal, but just so you know.

Next we need to fix some permissions. Go to API Permissions, and first REMOVE all API permissions which are present by default. You really can only have one permission active for this Intune integration to work.

Once you removed all permissions, click on ‘Add permission’ and select Intune:

Select ‘Application permissions’:

And ONLY select ‘update_device_attributes’:

Once you added the permission, don’t forget to click on ‘Grant admin consent for …’ to avoid end users being presented by any such prompt later.

That’s it for the app registration and settings.

Next, we said we don’t need to assign any user to this Jamf app, but we obviously do need to assign Intune licenses to our users of course. There is no such thing as a free lunch, and while a lot of Azure functionality is free, Intune is not.

I’m using my E5 trial for this blog, so let’s give one of my test accounts a license, and while I’m there, why not give it an O365 license as well for which I have another trial.

Note: If you are testing things out with new (test) accounts, like I am, you might get an error saying ‘License cannot be assigned to a user without a usage location specified’. To fix this, go to the user account, and give the user a location in it’s profile:

Now, to finish our setup in Azure, before we head over to the Jamf Pro settings, there is one more thing to do: enable the integration with Jamf Pro in Azure. We already have the app ready, now we have to tell Intune to actually integrate with Jamf Pro. For this we go to Microsoft Intune > Device Compliance > Partner device management. Because we already configured the API permission, the only thing left to do, is to copy paste our Jamf app client ID (which we copied to our temporary notes earlier) and hit save!

This is actually everything we had to do in Azure to make an integration with Jamf Pro possible!

So, off to Jamf Pro settings we go!

To finalise the integration config between Jamf Pro and Azure Intune, go to Jamf Pro Settings > Global Management > Conditional Access.

Here, we’ll need 3 things:
1) the domain name of our Azure Tenant (your actualy Domain name if you have a premium domain name configure in Azure, or something like mydomain.onmicrosoft.com if you don’t)
2) the application client ID of the app we created in Azure
3) our Azure app secret which of course we nicely wrote down as well :-), which in Jamf Pro is referred to as ‘application key’.

Once all the info is there, hit save. Next, and this is an important step which is not well documented in the Microsoft guide, you must click on ‘Open administrator consent URL’ to finalise the setup! This will bring up an Azure login prompt on which you need to authenticate with your Azure admin account, and grant the required permission for the Jamf Native macOS Connector (part of Jamf Pro authenticating to Azure).

Once this is done, you can test the communication between Jamf Pro and Intune by hitting the ‘Run test’ button.

Note: I forgot the 'Admin consent URL' step here and was able to run the test without any errors. However, later on, when devices where not showing up correctly in Intune... I realised I forgot something. More about that below.

Now, that’s all for the config of the integration in both Azure and Jamf Pro, so what’s left? Well, we already discussed the policy to deploy the ‘Company Portal’, so the only things we still need are: a Self Service policy to register our device in Intune, and some compliance policies in Intune. Let’s make a quick compliance policy in Azure first!

For this, we go to Microsoft Intune > Device compliance > Policies and ‘create policy’. I just selected a few basic things to have something to test with and hit save. A full discussion of compliance policies is a bit outside the scope of my post here, and something I’ll leave to the Azure admins amongst us for now.

Now we are really done in Azure and the final things we need is our Jamf Pro Self Service policy which our end user will have to use to register their devices. Compared to everything else, this is just the easiest thing to do. Just create a new policy, do NOT set any trigger, set the frequency to ‘ongoing’ and add the ‘macOS Intune Integration’ payload. This payload is just a matter of enabling a tick box, adding it to Self Service and scoping our policy to the required devices. Done!

Don’t forget to configure the Self Service tab to your liking. If you want you can even select the ‘Include the policy in the Device Compliance category’ which is automatically created for you since you integrated Jamf Pro with Intune:

ALL SET NOW! Let’s try it out!

Presuming our device already executed the policy to install the ‘Company Portal’, the end user now needs to run Self Service and execute our Intune policy to register the device:

The first thing that will happen is, the ‘Company Portal’ launching (hence the need of deploying that first ๐Ÿ™‚ ). Note however that this has to be trigger by Self Service! Just running this app will not register it correctly into Intune.

After clicking ‘Sign In’, the user will be presented by the standard Microsoft login screen, asking to put his/her Azure account…

Because my test Azure instance is federated to ADFS, I’m then redirected to my ADFS webapp to authenticate. In a pure Azure environment, you would just be presented with a normal Azure authentication screen. But in case you were wondering, all works fine with ADFS ๐Ÿ™‚

The ‘Company Portal’ will then call some resources and register the device into Azure!

All set??? Well, not really! Far from that actually, because at this point the devices might indeed have been added to Azure AD, but the link to the inventory record in Jamf Pro has not been established yet. For that, a little bit of extra magic is needed. After clicking ‘done’ at the ‘All set’ screen, the Self Service policy will then throw another Microsoft prompt and ask the end user to authenticate again! Yes, a bit annoying from an end user experience, but that’s how it is.

The reason for this is that the jamfAAD agent will grab the AAD Device ID from Azure, and add that to the Jamf Pro inventory. Remember, it is Jamf Pro sending inventory information to Intune, not the device itself. To do that Jamf Pro needs the AAD ID of the device.

What follows is another authentication run against Azure (and ADFS in my scenario)…

But also a prompt asking for access to a Microsoft key stored in the ‘login keychain’. Yes, a 3rd authentication needed (this time the local account password). This is expected and necessary.

Once this is done, the device will show up, both in Azure AD Devices, as in ‘All devices’ in Intune, ready to be assessed as compliant or not:

Now, in one of my first test runs while writing this post, my device only showed up under ‘Azure AD devices’. Nothing under ‘All devices”… ? So I went back to my Jamf Pro settings, checked all settings, went back to Azure to check everything there again, ran a test in the Jamf Pro settings, ran some recons to update the Jamf Pro inventory, manually sent inventory information to Intune from within the Jamf Pro settings… nada … no joy, the device never showed up under ‘All devices’.

Under ‘Azure AD devices’ it even showed up with ‘MDM – none’:

Yes, I already mentioned it above, after a while I realised I forgot to click on the ‘Open Admin consent URL’ link to give the Native Jamf macOS Connector the right permissions!

After doing so, running the Self Service policy again, or the following command in Terminal nicely triggered the inventory info to be send to Intune to make the device show up correctly!

 /usr/local/jamf/bin/jamfAAD gatherAADInfo -verbose

And this brings me to the end of this quick overview on how to integrate Intune with Jamf Pro!

As always, let me know if I missed something. Don’t hesitate to give any comments, remarks or shoot some questions. However, in case you need some solid troubleshooting I would advise to contact Jamf Support (or Microsoft, depending the situation) ๐Ÿ™‚

Brgds,
TTG

Print Friendly, PDF & Email