Skip to main content

I've been trying to wrap my brain around the User Approved MDM Profile thing. Why would we allow users to NOT approve our company's MDM? Doesn't that give them a way to avoid being managed? We need our MDM to be 100% approved at all times with no way for the user to have a say one way or the other - HIPAA requirements and such. And It has to be approved every time Tomcat on the server is restarted? I'm trying to understand how this is possibly a good thing.

As far as I'm aware it doesn't stop the MDM being applied, it just stops certain features from working such as kext files.


That would cause a catastrophic problem with McAfee.


Yep, it stops a whole load of things from working!


As of right now User Approved MDM is required (meaning, the profile needs to be installed by supported methods OR the user needs to approve the MDM profile by clicking the "Approve" button) for two things:
- Secure Kernel Extension Whitelisting via configuration profile
- "Autonomous Single App Mode" (which is not manageable in Jamf yet)



So basically if you want to be able to whitelist secure kernel extensions you need the MDM profile approved. If it's not approved the profile will not apply to the computer and you'll see a failed management command for it on the computer record in Jamf. The user will have to manually approve any prompts from apps that use secure kernel extension (yep, McAfee is a big one, so is Cisco for AnyConnect and other VPN clients as well).



I don't think there is anything that would dictate to not approve the MDM. It's really a matter of how the profile is applied. The new enrollment method of 10.3 for 10.13.x devices takes care of it. As does DEP provisioning.


@emily "The new enrollment method of 10.3 for 10.13.x devices takes care of it."



Could you elaborate on that please? I'm currently testing Jamf 10.3 with 10.13.4 and I always have to manually approval it (I'm using Jamf Imaging and bringing down an image created with AutoDMG.


@allanp81



@emily is talking about the user initiated enrollment (https://yourjamfserver.company.com:8443/enroll) where the user is required to install 2 config profiles that automatically approve the MDM profile.



I have purposely not updated my base image past 10.13.1 so that while using jamf imaging as you are, the mdm profile will automatically be approved upon running OS updates since the manual approval took place on 10.13.2 and higher.


https://isimagingdead.com/


The more folks resist Apple's directions, the harder it is going to get for you to provision machines. Get on board with recovery / App installer based restore and thin provisioning. Is it ideal? No. Will you be in a world of hurt if you don't pivot? Yes. Just wait until the T2 chip is in all Macs. Legacy "imaging" type workflows are going to be DEAD.


The problem is that we physically CAN'T do Internet Recovery booting here and it is highly unlikely we'll be able to use DEP anytime soon. The current Jamf Imaging workflow is seamless and works. To change to manually wiping and installing the OS (security requirements dictate what we do if we can't throw down an image), then manually running a QuickAdd.pkg to enroll in JamfPro is more than an inconvenience.



Simply saying "imaging is dead... use DEP" is not helpful at all.


Are you sure it "works" if the MDM profile is coming in unapproved and the setup isn't following Apple's approved provisioning workflows? That doesn't sound like "works" to me. If you're not going to update your workflow you need to temper your expectations of what "works" and what doesn't.


@AVmcclint
just to expand on what @emily stated, not sure if you read this from Rich. Also it seems for the time being asr restores are still supported, so why not use all currently available methods at your disposal to get the job done.


I know that it is not helpful, but unfortunately this is the position that Apple has put us in. I have breathed bellyfulls of fire at Apple/Jamf, and just had to give up and have Field touch machines a few times when provisioning. I hope that those of you for whom this new workflow (user initiated or DEP) does not work (such as lab Macs) have initiated a dialog with your AppleCare reps, and are testing and submitting feedback on the betas... Apple seems to be keen to break things and see who screams the loudest before thinking about providing ways of re-automating workflows which are now horribly mangled. But, hey, you know, 10.12.6 is still a supported OS. :)



But once you are on 10.13.4...


(After taking some deep breaths and calming down) It is horrific that apple keeps breaking things the way they are without considering the impact on users and admins. I’m frustrated daily by my own infosec not wanting to open 17.x.x.x and Apple’s reluctance to help me convince them to. What I don’t understand about the new user approved MDM is that if an alien MDM profile somehow manages to land on a user’s Mac, they’ll be able to approve it??? How on earth is that in any way secure? The current method of installing the MDM at the time of imaging/enrollment is as secure as you can get, I would think. The user has no say in the matter - they are company computers used for company business... we don’t do BYOD. We don’t do user initiated enrollments specifically so we can control exactly what computers get in our network and access our data.


Well hey, at least JAMF 10.4.0 gives Notification Center reminders to Approve the profile.
It's something. But indeed, things are going to take a while to settle in getting back to simple device management.


I would like to add, while this is a headache and may cause some companies to drop Apple choice in their environment. At the end of this very poorly executed transition we will have a much more secure macOS. That is a win for everyone!!



C


@AVmcclint this helped explain 17. block to my infosec team: https://youtu.be/Z-Lg9uBbmfk


I sent that video to our InfoSec team as soon as it was available. I think one person watched a couple minutes of it. :-


Anyone else having issues with enrollment and config profiles not being applied with JSS 10.4.1 and 10.13.4? I usually use Casper imaging to setup and enroll new machines, but recently attempted to enroll a Macbook using the user initiated enrollment process. What I found is that I can get the CA and MDM profiles installed, but no other profiles seem to apply without leaving the machines sitting for hours. I also noticed that the "jamf" terminal command does not work unless I navigate to where the binary is installed and run it directly from there.


I may be wrong but I have seen few cases that MDM approval notification via Self Service is pushed out even if MDM profile is approved already?!
Then I noticed this:

User Approved MDM: Collected for macOS 10.13.2 or later



Does it mean, that people who are still using macOS 10.13.0 or 10.13.1 will be notified even when they have approved MDM profile?
Probably workaround is only to update OS because there is no scope option for this notification.


There's a big problem with user approved MDM. On five Macs, I have had issues with VPP assigned apps not installing via Self Service. The reason is because the MDM profile suddenly becomes unapproved while the app is installing. I watched this happen with Self Service open and the Profiles preference pane running side by side with Self Service. On my own MacBook Pro, the MDM profile suddenly became unapproved, and then it would not allow me to approve it. I got a message saying that the profile has to be approved manually using the computer's connected, mouse, keyboard, or trackpad, as if I was remote controlling my MacBook Pro. I wasn't. I was able to approve the profile using another admin account. But that leads me to my next issue... Only the user who approved the MDM profile can download VPP assigned apps using Self Service. If another user tries, the MDM profile will become unapproved again. I have an open ticket with Jamf for this, and from what I understand from my conversation with someone in support yesterday, this is known, and it has been going on for a while now. Right now, I have zero confidence in Jamf Pro. This must be fixed. No more updates of Jamf Pro should be released that do not have a fix for this issue. If this is an Apple issue, then Jamf needs to work with them to get this resolved. Having MDM is useless without the profile being approved.




@howie_isaacks That is what makes this whole thing scary. I think this falls squarely on Apple's shoulders, but Jamf has a huge responsibility to lean heavily on Apple to make it right. I think Jamf has enough pull to point out the danger in this new MDM model.


@AVmcclint This has bummed me out so much, I don't even want to attend JNUC this year. I will be going only to avoid wasting all the money that was spent to get me there this year. Everything depends on the MDM profile being approved and working properly, so this makes Jamf Pro very unreliable. I plan to nag Jamf daily until a solution is implemented. If I try to contact Apple about this, it would be a wasted effort. Jamf can and should pressure Apple to take action. Apple uses Jamf Pro too, so they must know that this is a problem.


@howie_isaacks You and I both know firsthand how futile it is for end users to get a point across to Apple. We are lucky that we do have Jamf's ear via JamfNation and Jamf has the ability to wake up the powers that be in Cupertino. The real question is WILL they?


@AVmcclint Jamf WILL do this. I won't allow them not to. Once I get stirred up about something, I don't let it go until I get satisfaction. This is huge. If this doesn't get others here stirred up, it should.


If your organization is in Appleseed you need to report the issue if you're not going to file a bug. If you're not in Appleseed for IT, reach out to your SE to get added. Or reach out to your SE to file an issue through them. It's an Apple issue, not a Jamf issue. I'm sure they already do work with Apple on these issues, but they are just one Apple customer. We are Apple customers too, and share the responsibility of reaching out to Apple to get things like this resolved.


Reply