Hi, and welcome to "iOS Device compliance."
This is Jamf's forward-looking disclaimer.
Please take a minute to look this over.
All right, my name is Bryce Carlson.
I'm a product specialist at Jamf.
I specialize basically in anything having to do with Microsoft.
So the macOS integration,
SCCM, and now this iOS device compliance.
So what's new with iOS device compliance,
I guess, is where we're gonna start.
Then we're gonna look at, how is that different
from the existing macOS integration?
We'll also look at the best practices of how to use it and basic setup
to kind of give you a taste of what that feature is gonna look like.
We'll also give a demo of the end user process
so you can see from start to finish the admin side of things
where we have the actual integration setup
and then what the end user will see.
So, what's new?
Well, iOS platform support. That's new on all fronts.
It's not something we've had previously.
And we're doing that with a new API for Microsoft for device compliance.
There's a new blade in Microsoft Endpoint Manager,
formerly Intune– that was rebranded on August 1st–
that allows us to do that.
And we're also using a new feature of the authenticator app for iOS
to perform that user site registration to get the devices compliant.
We're also using a different form of compliance calculation
with that new API, and we'll kind of get in depth
as I show a quick summary of what the macOS
is set up like and how that is different from the new iOS integration.
So, first, we go and look at the...
macOS integration as it exists today,
we have the partner device management blade,
and what we have there is our enterprise application ID
tied to your Jamf Pro server that's allowing you to go through,
register the devices,
and then Jamf Pro goes and fills in the blanks about those devices
so that you can get a complete composite about that device.
So you have it in Jamf as an MDM,
and you have it in Azure as a registered device
with the different inventory attributes that Jamf knows about it.
What's new is the partner compliance management blade.
That's in preview now.
That'll probably change by the time JNUC rolls around.
At the time of this recording, it's just first getting into preview.
And that is very similar.
It allows, again, a device to be in Jamf as an MDM,
and then the registration takes place
and Azure can take action on if the device is compliant or not.
So how is that different from macOS integration as it exists now?
Well, right now the Workplace Join is used,
which is happening within Company Portal.
If you were just to go and take a device and enroll it into Intune, or MEM now,
as an MDM, you would use Company Portal.
And what's gonna happen is, you'll do a Workplace Join,
and then you'll get your Intune and/or MEM MDM profile.
So what we're doing with the current macOS integration
is we're opening Company Portal,
and we're putting it in registration-only mode
using a specific flag of minus R
that came about through this integration.
And what that's doing is, it's doing just the Workplace Join
and then stopping the process, because if we were to continue on,
it's going to fail because it's gonna try
and put that into an MDM profile,
and the device is already enrolled into Jamf as an MDM.
So after that registration-only takes place, Company Portal exits
and that UPN is validated, sent to Jamf Pro,
a composite JSON of that Azure AD ID information that we just got
is combined with the inventory data that Jamf already has.
It's built and sent, and then Azure and Microsoft Endpoint Manager
take that data and calculate compliance.
So what does that look like to the end user?
Well, they're gonna open self-service.
They'll see the registration object.
In this case, the policy that we have there.
That's going to get kicked off.
That will call Company Portal in registration-only mode.
That's what we're talking about.
You'll go ahead, you'll sign in with your UPN,
and once you've signed in, that Workplace Join will take place
and the organizational access cert is going to be put into
that user's login keychain
where it could then be used in the future for OneDrive,
PowerPoint, Excel– doesn't matter.
Safari–anything that's prompting for it could go and utilize that.
After that's done, you'll go ahead, close.
Company Portal will exit. It'll inform Jamf AAD that it's done.
You'll go and verify your user principal name,
and then it's gonna take that information that we just got
after we allow access with the "always allow" button.
We'll take that information, and it will send it off to Jamf Pro
and Jamf Pro will build that composite.
So Jamf Pro's side then: we see the data that was sent via the inventory,
all of the pieces of inventory information.
That's mapped out and sent.
And then Azure's side.
We see that device there, which is registered, compliant, and good
because of the data we sent
and because the data we sent is matching our compliance policy
that we have set within Microsoft Endpoint Manager.
So this is where the major difference between the existing
macOS integration and iOS comes in.
We had those pieces of information about the device that we're gathering,
and then we're taking and sending those to Azure.
And Azure is calculating the compliance based off of that.
So in the audit logs within Azure, you'll see, okay, I've received that.
You know, Bob's device has this passcode, has this encryption setting.
It has Gatekeeper.
Based off of that and based off what we know in our policy,
that is what's telling it if it's compliant or not.
The new integration is different.
It's actually much simpler than that.
We'll get into the setup in just a little bit.
But what's essentially happening with the new integration is,
we're sending a flag of "is compliant" or not.
We're making that call
for Microsoft Endpoint Manager and Azure to tell it
this device is compliant based off of smart group criteria
that we have Jamf Pro side.
Then we just combine that along with the AAD ID that we know
and post it using the new API.
So best practices and setups.
The new integration also uses two enterprise apps:
one for the server side, one for the client side.
The existing macOS integration
is using the enterprise app for the server side post.
That's how we're getting that data there with that API call.
And then we're also using a client side app
that's being used in this case via authenticator.
In the macOS case, that's what Jamf AAD is using to validate that data
after Company Portal exits.
You'll also want to have a user group of the users
to be targeted within Azure,
which I'll show in the setup here in just a second.
You also want smart groups for who is compliant.
So this device is compliant based off of these, you know,
sets of criteria within your smart group.
And then, you know, you'll also want a smart group of who can register–
basically, in a macOS policy sense, who can see that policy.
It's actually not a policy; it's an object
because there isn't policy on iOS.
And then just like with macOS and Company Portal,
that app is gonna be called.
And we, in the documentation for the macOS integration,
advise that you push out Company Portal first.
Otherwise it's not gonna call that bundle identifier
how it's doing it, similar with iOS.
Not exactly, but it's still best practice to deploy the authenticator app
because it gives a better user experience.
It allows the user to just quickly go from one step to the other,
as you'll see in the end user registration,
which makes that process much less painful for the end user.
And they're than familiar with that app, too,
if you're having them use that for MFA or any other prompts.
So we'll first do the server side setup here.
So I'll go into my server settings
and go into my device compliance for iOS.
I'll edit that.
I'm gonna pick the sovereign cloud that we're using.
At this point, the global cloud is the only one that we have.
We'll pick our group of who's going to be compliant,
and we'll talk about the criteria there,
and we'll pick our group of devices that we want to register.
So we'll say, you know, within this factory,
these devices can register just for this example here.
We'll go and hit the connect button then.
And that's going to redirect us to the Jamf Cloud connector,
which is where we're hosting that enterprise application
for this multitenant, safe-listed Microsoft app.
We'll go ahead, sign in with our Azure admin.
We'll accept the terms on the first app,
which will be the server side app.
It will redirect us back. [indistinct] in their ID.
Redirect us back, and we'll sign in again to make the native app,
which will be the user registration app.
The names are subject to change, yeah.
It'll then ask us to open Microsoft Endpoint Manager,
and it will load up the tokens and connectors area
of Microsoft Endpoint Manager where that new integration blade exists.
Within there, we'll go to "add a new partner,"
and we're going to add a new partner for the iOS platform
using the Jamf app.
Right now it's Jamf SH Test–
again, subject to change before general availability.
We'll go ahead. We'll hit next.
And then we're gonna pick our specific group of users
within Azure we want to register.
So, similar to, in Intune, how you would sign a license for E5.
We're saying the people that are in this staff test group
can go and register,
and it will allow that calculation and flag to be set.
So in other words, that all set.
We can go ahead back to Jamf. We can confirm that we've done that.
That way it can go and make that heartbeat connection.
This page will say it's establishing a connection.
It will auto-refresh when it's done.
Here we can see on our integration there,
it has a time of last connection from before
I deleted it and recreated it for this video.
But it'll get a new timestamp shortly.
It does take about 60 to 90 seconds, roughly, for this process to take place.
What's happening on the back end
is it's making that first call-out with your unique generated ID
and then sending that out to Microsoft for Microsoft to then respond back,
and then Jamf Pro will update that once it receives that signal.
It takes a little bit of time,
but the page auto-refreshes.
We go back to Azure.
We can go ahead and refresh there,
and we can see, yep, we have a new timestamp.
It's now communicating server side. We're all good to go there.
So those smart groups that we touched on...
The one for compliance,
the one that I have set here is just simply saying,
"Do we have Passcode enforced?"
and making sure that the device is auto-locking
and requiring a password.
As well as, does it have an 802.1X profile?
It really could be whatever you want,
just as long as your smart group logic plays out
and the devices stay in that group through any fluctuations you would have.
Unless, of course, the device is no longer
meeting your security requirements,
then you would want it to fall out of that group.
Now, that flag that we're sending Azure side–
we talked about the compliance policy for macOS.
There isn't anything like that for this integration
because we're sending that flag.
We're just saying "is compliant" or not.
So within our Azure compliance policy,
we're saying, require the device to be compliant.
And if it has that, go ahead and grant access.
And what that'll do then is for any of the native apps–
so Word, PowerPoint, Excel, Outlook, OneDrive, within iOS–
they'll be able to use that token from the Microsoft authenticator app
to go ahead, sign in and be compliant
because they're using that shared ID of, "This is the device."
I am compliant to go and do so.
So any of those native apps will function and honor this.
You could have different scoping
if you want to have different apps that are affected by it.
I'm just saying all cloud apps here with one exception,
which leads me to a best practice.
And this is something that comes up on macOS too:
you'll want to make sure that when you set up your compliance policy,
you have an exclusion for the iOS native app,
which will probably wind up being called the user registration app
once this goes to production.
Because if you don't allow the user registration app an exception to this,
what happens is when you're going to go through authenticator,
it's going to stop and say you can't use this sign-in
because you're not compliant for this enterprise app,
which is kind of a problem
because you need that app to become compliant.
So it's a "what came first, the chicken or the egg?" scenario.
If you don't have access to that enterprise app to sign in
to become compliant,
how are you ever gonna become compliant to sign in to use the app?
It's happened a couple of times with customers with macOS.
It's just one thing to keep in consideration.
That is in the documentation there.
It's easy to miss if, you know–
obviously not all Jamf admins are the Azure admins,
so you might not have full purview into that.
So it's just one thing to keep in mind.
Again, another best practice would be to go
and have that Microsoft authenticator app
on the devices at the time of user registration,
which I'll be showing in just a second here.
That way, it's a nice, fluid, quick process
that's very painless for the user.
Plus, you have authenticator deployed then
for future use with, you know, the iOS native apps.
If you have Outlook or One Drive
and you're acquiring MFA via authenticator,
it's already there.
That can be your first step in your workflow then.
So the new end user process–
it's similar to what we saw in macOS,
but with actually a few less steps.
So we're using the authenticator app
in this new function.
It's going to start with self-service.
The user will be directed
to authenticator app.
They'll go ahead and perform
their sign-in.
They'll get a token.
Once that user side action is done,
Jamf Pro will send the data.
So what does that look like?
On user side, we'll go and open the Self Service app,
and you'll see the registration object there.
We will be prompted to sign in.
I'll pick my account that I've used in the past
but I've signed out of for this video.
I'll go ahead and use my saved password for that, and it's gonna go ahead
and prompt us to register our device.
If we click on "more info,"
it'll just tell us it's using that native user app.
We'll go ahead, hit "register."
That's gonna go out to Azure AD,
create our device, and then give us our token
via MSAL in the authenticator app.
Authenticator will get that.
It'll bounce us back to Self Service and tell the user they're all done.
No other action is needed Jamf side
within Self Service.
Go ahead, close the app.
The only other action that might be needed
was the end user maybe signing into
Outlook or OneDrive, which will prompt them possibly to unlock authenticator
if you're using that for your authentication.
Server side, what does that look like?
So Azure side, all we're seeing is that device record,
and is it compliant or not?
It just simply submits that flag, yes or no.
You could set up an email notification if you want
for the smart group of "is compliant."
You can monitor that via Jamf
and also through reporting within Azure.
But it's really up to you.
There's not much else to the integration than that.
It's quite simple, really.
If you have any questions, we'll cover those in Q&A.
Thanks for listening.
And if you have any feedback, please use the survey in the widget below.
Thanks.