Profile Manager - Why create Enrollment Profiles?

Question

Level 1

7 points

Profile Manager - Why create Enrollment Profiles?

So a similar question was asked previously:

I've read through it and I don't think the answers provided tell the whole story, so I'd like to ask again adding some of my own thought and clarifications on the previous thread. This may be considered a "primer" by some - though I am certainly not the expert on Profile Manager. I'm laying it out there to explain my understanding and off of that, ask a question. If you are an expert, and understand how all this works, please just skip to my question below!

First, my experience and understanding. (I urge others to correct/clarify where they see fit):

The previous thread attempted to make a distinction between the 3 different types of profiles: Trust, Enrollment.and Remote Management Profiles.

I believe the proper 3 distinctions should be: Trust, Remote Management/Enrollment, and Configuration Profiles.

- The Trust Profile is basically a Profile (.mobileconfig file) that contains the Server Certificate that needs to be present to validate other signed Profiles. It's a fancy way of packaging up the Root certificates.

- The Remote Management/Enrollment Profile is a Profile (.mobileconfig file) that delivers the Remote Management "connection". It registers the device with the Profile Manager server and facilitates the ability to use PM/APNS to push various Configuration Profiles as well as commands (wipe/lock/etc). It is *only* called an Enrollment Profile when you explicitly create one (more on that below). Because an Enrollment Profile does not need to exist to enroll (or rather it will use the implicit "unseen" enrollment), this is the most confusing of the 3 Profile types. It is further confusing because the term "Profile" is used almost elusively on the device and not within Profile Manager. In fact the "Enrollment Profile" is the only one explicitly called a "Profile" within the management interface!

IOW: While it is not shown anywhere in Profile Manager, I believe that "Remote Management" (called a Profile on the device) is basically the *default* Enrollment Profile that is only inferred and seen when you use the Enroll function on MyDevices. This means you don't need to create any Enrollment Profile to enroll your devices interactively via the MyDevices page.

- The Configuration Profile is a Profile (.mobileconfig file) that delivers specific settings. These Profiles are applied to either Users, Groups, Devices, or Device Groups. They can be automatically pushed to an enrolled device, or they can be manually downloaded from the MyDevices page (seems to apply to User configuration only) for devices even if they are not enrolled (this would allow the end user the 'choice' to pull down settings).

Having outlined that, the simplest steps to enrollment...:

When you setup Profile Manager, you can go right to the MyDevices page on your device, login, and choose "Enroll." (sample device is let's say an iPad)

Doing so will prompt you to install the "Remote Management" profile.

Note that when enrolling in this way it does not appear necessary to install the "Trust Profile" for your server, even when using a Self-signed Cert. It would appear that this "Remote Management" profile contains not only the SCEP Enrollment Request and the Device Management payload, but also the Certificates that would be installed with the "Trust profile"

So we have seen here that one can enroll a device without explicitly creating any "Enrollment Profile."

So why use an Enrollment Profile?

Well according to https://help.apple.com/profilemanager/mac/3.1/#apd6DD5E89E-2466-4D3C-987E-A4FF05 676EB7, the answer is pretty straightforward:

"The user does not need to authenticate or log in to Profile Manager’s user portal"

This is a great feature. For one, you can create an Enrollment Profile and send it via e-mail and the user doesn't need to visit a web page and login to enroll a device. In fact, based on my experience Enrollment Profiles can't even be accessed via the MyDevices page unless you are a Server Admin.

However, when distributing an Enrollment Profile you seemingly *must* install the Trust Profile prior to this, or you will get an error about communicating with the server. Several docs/tutorials you can google explain how to set up your deployment systems (specifically OSX machines) to deploy systems with both the Trust and Enrollment profiles to facilitate automatic enrollment when a new system is deployed so it can instantly be managed.

However, since a device that is already deployed will/may not have the Trust Profile installed, one would have to visit the MyDevices page to install that prior to being able to import a delivered Enrollment Profile. Because of that it seems that from a distribution approach (as opposed to a deployment scenario) there is not much advantage of using an explicit Enrollment Profile anyway since we already need to visit the MyDevices page to get the Trust Profile, we might as well just use the standard MyDevices implicit Enrollment.

All devices that have enrolled themselves via a defined/explicit Enrollment Profile will be listed under that Profile in Profile Manager. Devices that have enrolled via MyDevices will not be listed under any Profile, but rather just under Devices (where *all* devices will be shown regardless of how they enrolled).

So, now the questions:

So, the idea of an Enrollment Profile makes perfect sense - it is basically the only way to create an exportable profile that can be distributed and configured to automatically enroll a device without interactive enrollment via the MyDevices page.

What I don't get is WHY is there the ability to create multiple Enrollment Profiles rather than simply providing a default exportable profile?

The reason it makes no sense to me is there is absolutely no correlation (that I can deduce) between an Enrollment Profile and the devices that used it to enroll. While I can see a (non-exportable) list of each device enrolled via each Enrollment Profile, it ends there. I can't, for instance, create Configuration Settings that I link to an Enrollment Profile. Or dynamically populate a Device Group with all devices enrolled from a specific Enrollment Profile. If I could do these things, it might make sense to me and I have spent much time looking at the interface and scouring documentation to see where the connection is. I have simply determined that there isn't one.

I can go ahead and create several Enrollment Profiles such as:

iPads

Lab Systems

Main Office Systems

High Security Systems

And I can deploy these Profiles (either via mail/file or via initial deployment) to the respective devices. I can then see under each Profile which devices enrolled. But, since I can't actually do anything to correlate those systems to a configuration, why would I want to do this segregation? Sure it gives me a listing of iPads apart from OSX machines, but I can't do anything with this listing!

Now, of course, I can still pre-stage devices and add them into particular device groups so that as soon as they are enrolled (via any Enrollment Profile) they will get the Configuration Profile(s) attached to them. This makes the inclusion of multiple Enrollment Profiles even more suspect.

Am I missing something? Can someone enlighten me as to what the purpose of creating more than one Enrollment Profile would be?

We can easily say "Well it's not hurting having them there" but, in terms of complexity and confusion I believe it is. Had they simply provided a single Enrollment Profile ("Remote Management") that was downloadable/exportable it would have been sufficient.

Thoughts?

Posted on Jul 9, 2014 5:31 PM

Reply

Answer 1

Best reply

mscott_mdm

Level 2

459 points

May 22, 2017 9:25 AM in response to BJH75

This is a pretty good write-up, but I'd like to clarify a few points.

The Trust Profile is basically a Profile (.mobileconfig file) that contains the Server Certificate that needs to be present to validate other signed Profiles.

While it does help to validate signed profiles, all current Apple devices will install any profile regardless of the validation status of the signing. The critical part the Trust Profile is for is to enable the device to trust the server when you're not using a trusted SSL certificate. If you setup your server to use a trusted SSL certificate, the Trust Profile is unnecessary.

It's a fancy way of packaging up the Root certificates.

Technically, the server's root Certificate Authority (CA) certificate, AKA, the certificate that issued the intermediate CA that in turn issued the default SSL certificate. 😉

The Remote Management/Enrollment Profile is a Profile (.mobileconfig file) that delivers the Remote Management "connection".

This profile is the Mobile Device Management (MDM) profile, which when obtained from Profile Manager includes at least two payloads, possibly three: 1) The MDM Enrollment payload, which is what causes the device to actually enroll with the MDM server (which doesn't have to be Profile Manager); 2) A device identity payload, which Profile Manager delivers in the form of a SCEP payload, although it is allowed (but not recommended) for an MDM server to simply provide a device identity directly; 3) If needed, the server's CA certificate(s), the same ones that are included in the Trust Profile.

In fact the "Enrollment Profile" is the only one explicitly called a "Profile" within the management interface!

Profile Manager uses the term "profile" only for the things you manually download (i.e., .mobileconfig files). If Profile Manager pushes them, it uses the term "settings." My theory is that when configuration settings are delivered directly to devices by Profile Manager, the actual mechanism is not necessarily always a profile, and the distinction isn't really relevant to the user. But when you download a file, that file is called a profile.

IOW: While it is not shown anywhere in Profile Manager, I believe that "Remote Management" (called a Profile on the device) is basically the *default* Enrollment Profile that is only inferred and seen when you use the Enroll function on MyDevices.

You are basically correct here, but it might be less confusing if you called "default Enrollment Profile" the "MDM profile".

This means you don't need to create any Enrollment Profile to enroll your devices interactively via the MyDevices page.

Absolutely!

However, when distributing an Enrollment Profile you seemingly *must* install the Trust Profile prior to this, or you will get an error about communicating with the server

.

Yes, this is correct. An Enrollment Profile (as PM uses the term) is really an OTA (Over The Air) enrollment profile that performs some complicated dance that ultimately delivers the MDM Profile the same as if you went to /mydevices. However, the OTA spec provides no mechanism to profile the certificates to trust during the OTA enrollment process, so you have to install the Trust Profile first.

However, since a device that is already deployed will/may not have the Trust Profile installed, one would have to visit the MyDevices page to install that prior to being able to import a delivered Enrollment Profile.

So this isn't true. You can also download the Trust Profile from the PM web admin (under the menu in the upper-right corner of the page). You would distribute both the Trust Profile and Enrollment Profile together.

So, the idea of an Enrollment Profile makes perfect sense - it is basically the only way to create an exportable profile that can be distributed and configured to automatically enroll a device without interactive enrollment via the MyDevices page.

It's also the only reusable profile. The MDM profile downloaded from /mydevices can only be used once, and expires if not used within 10-15 minutes. This means you pretty much have to use an Enrollment Profile to mass-enroll devices using Apple Configurator, for instance.

I can't, for instance, create Configuration Settings that I link to an Enrollment Profile. Or dynamically populate a Device Group with all devices enrolled from a specific Enrollment Profile.

You must be using an old version of PM. PM has supported for several major releases the ability to automatically add devices enrolled with an Enrollment Profile to a device group.

We can easily say "Well it's not hurting having them there" but, in terms of complexity and confusion I believe it is. Had they simply provided a single Enrollment Profile ("Remote Management") that was downloadable/exportable it would have been sufficient.

Well, there is also the matter of security. By being able to create multiple Enrollment Profiles, you can independently "revoke" the profiles you've sent out should one fall into the wrong hands. (You simply delete the Enrollment Profile from PM.) So being able to create more than one means that you don't cut off everyone's ability to use an Enrollment Profile if you ever have to do this. But before PM added the ability to automatically add devices to device groups, that was about the only benefit I could think of.

Nice write-up.

Reply

Answer 2

tknospdr

Level 1

18 points

May 19, 2017 5:03 AM in response to BJH75

Seems to me that it makes self enrollment of unknown devices possible.

Say I have a large company that has a BYOD policy. My payload profiles include a root profile that is standard across every device in our network be it a Mac, iPad, or iPhone. Then I've created individual profiles that pertain to each of those specifically. And then a third level of profiles that cover different user groups. Say sales, marketing, and executive.

I can create a deployment scenario where the Enrollment Profile for "Sales iPad" has my root, iPad, and Sales payloads in them. When we hire a new sales guy, he can get onto our wifi, and his landing page says:

Welcome to BnL Inc, (don't mind the trash, we're working on it)

If you're a new hire in our sales dept, click here.

You're now done from a device standpoint, and you didn't even know about his iPad until it showed up in your management console.

Reply

Answer 3

hemmes

Level 1

25 points

Jun 5, 2015 4:40 PM in response to BJH75

I feel your pain here, it does seem pretty lack luster. But here's what I've come to determine. An enrollment profile is, yes, another way to create a connection to the Profile Management server. One of the only settings you can give the Enrollment Profile is whether or not to restrict it to placeholder devices or not, which cold be further organized / controlled by utilizing Serial numbers, UDIDs, IMEIs, and MEIDs with added placeholder devices. What it does also seem to let you do is identify which devices have utilized that profile, located under the Usage tab for each respective profile. I suppose this allows you to identify which device has used a respective distribution methods, such as a specific web link, email blast, etc.

I happen to be having an annoying issue where I can create new enrollment profiles, but cannot delete them at all, receiving an error:

"A Server Error has Occurred

Please reload the webpage and try again.

If this error continues, please contact your administrator."

I'm using OS X Server 4.1

Reply