macOS 10.13.2 and "User Approved MDM enrollment"

[Winterhalter]

Per the newly issued Apple Doc https://support.apple.com/en-us/HT208019 , any new enrolls I have for clients running macOS 10.13.2 need the MDM Profile to be "approved" by a user (any user!) in order to have full functionality.

Is this something that JAMF Pro will be able to work around? (I'm on 9.81 at the moment) Is the only real "solution" to this enrolling in DEP? (the distributed nature of our organization makes DEP annoying at best) This seems like a case of Apple creating a problem that DEP is the solution for.

The profile functionality being disabled is listed in the following screenshots.

[emily]

If Jamf changed their enrollment workflow to involve installing a profile, then leveraging installApplication to install the binary/agent stuff? Maybe. The issue is the MDM Profile being pulled down by the agent, rather than the profile being installed by the user. If the MDM Profile was installed manually by the user it would be considered User Approved because the user installed it themselves. At least that's based on what I have gathered around this behavior change.

I'm not sure how likely it is that Jamf will completely change their user-initiated enrollment workflow, so I'm guessing that getting DEP in place is the preferred option for this. I do know that the SecurityInfo management command includes the status of UAMDM in a device, stating if it's User Approved, if it's not, or if it's DEP-enrolled. That will at least help build some reporting around the "feature" so a user can be informed that they need to take action. I would recommend checking out this feature request around that.

[jzeles]

It is definitely a case of Apple creating a problem that DEP is the only real solution for. This was supposed to be fully implemented in 10.13.2, but they actually pulled out the DEP requirement for now (they say it will be added in the spring). For now, having any MDM will disable the forced approval. The screenshots you included look like the 10.13.2 beta which did force the user to approve even manually installed MDM profiles.

If this is going to impact your ability to Apple, please contact your reps. and make sure you convey why forcing users to use DEP isn't a great solution for all enterprises.

[Winterhalter]

Screenshots are from last week's update to 10.13.2.

I have definitely talked with my Apple rep about the reasons DEP doesn't work well for our organization. I guess I'm due to have another one.

[emily]

DEP being required for UAMDM is still a part of 10.13.2. I've given Apple an earful about this. If you do a user-initiated enrollment on a 10.13.2 Mac you'll see that button is still there. What they did is remove the requirement for user-approved kernel extension loading. So basically the only impact of UAMDM in 10.13.2 right now is confusion and heartache. It's like being trolled.

[dgreening]

DEP is NOT a one size fits all solution! Automated workflows which do not require DEP need to be maintained for those of us who cannot fully leverage DEP due to it not being supported in certain countries. It is very clear that Apple has not thought out these changes before implementing them.

[ericbenfer]

Anyone really good at making AppleScript click buttons?

[bentoms]

@ericbenfer no UI scripting for that button.

[gachowski]

I wonder why this wasn't brought up at WWDC last year?

C

[dpratl]

Hopefully a solution will pop up for that.

BR
Daniel

[brunerd]

Bumping this thread, just to say I have not been able to figure out how to detect whether or not a user has accepted, thus no EA yet... I guess that's why JAMF says the ability to report on this will be coming "in a future release"... wondering if anyone else has been able to divine the state of an MDM profile? I tried by looking at the output of "profiles -C -v" before and after accepting, no change, no dice...

[emily]

@brunerd profiles status -type enrollment

As of 10.13.3 anyway

I threw together an EA for it:
https://github.com/smashism/jamfpro-extension-attributes/blob/master/python/uamdm_status.py

But I'd recommend joining the Jamf Pro 10.3 beta if you're not in it already…

[brunerd]

@emily Hmmm... not getting that result... am I Holding It Wrong™ ?

[brunerd]

@emily Just to update this... the above was perhaps a 10.13.2 machine although I thought it was 10.13.3... anyway, on 10.13.4 it will output the DEP and MDM values... but... "MDM enrollment" still set to "Yes" even though it has not been accepted which is not very helpful of Apple... either there is another way to determine this or it's the ultimate middle finger from Apple to those not using DEP
(I didn't see anything jump out in the output of profiles -C -v either...)

[emily]

@brunerd are you running the 10.3 beta anywhere? Before you fall too far down any rabbit holes trying to get reporting around this you may find some of the changes in that upcoming version of Jamf Pro… illuminating.

[arivera]

@emily so this issue has been addressed on Jamf 10.3 Beta ? I am a bit behind on this and a bit confused, just noticed this issue not long ago and I see it seems to only happen on my High Sierra installs, these machines are running 10.13.3 . Any insight will be gladly appreciated.

[emily]

Now that 10.3 is out, yes, this is addressed. For 10.13.x+ Macs enrollment is done with the MDM profile first, like iOS. The jamf binary and other bits are installed using installApplication after the MDM profile is in place. Because the MDM profile is installed first and added by the user it is automatically installed as "user approved".

Macs on 10.12 and below will still using the QuickAdd method by default.

[Chuey]

@emily I've reviewed the release notes of 10.3 and if I'm understanding correctly it appears QuickAdd PKG is still not a supported method? With close to 8,000 machines ... in place upgrades are not an option for me and I'd have to tackle this in a work flow. Any advice on how to accomplish this if I'm understanding correctly?

[emily]

@Chuey quickadd is definitely still a supported method. Macs on OS versions below 10.13 will still use a QuickAdd. If you want to force a QuickAdd you can go to https://your.jss.url:8443/enroll/?type=QuickAdd regardless of detected OS version to install via QuickAdd.

What you lose by using a QuickAdd package on 10.13+ is the MDM profile will not be marked approved on installation. If a QuickAdd is used the MDM Profile must be manually approved by the user by clicking that Approve button in System Preferences > Profiles. If the MDM profile is not marked as approved the secure kernel extension whitelisting payloads will be rejected because an MDM profile must be approved before SKELs can be whitelisted via profile.

Hopefully that makes sense.

[Chuey]

@emily Yeah it makes sense -- I guess I was hoping I could use the QuickAdd and it have the approved MDM -- I have a lot of machines that we re-image and enroll in a work flow using QuickAdd -- I'm now stuck in a bind.

I cannot hand click approve on this many machines -- i mean i could but who wants to do that?

In place upgrades are not an option

The only thing left for me is to enable DEP for these devices, image them with 10.3.x like they are straight out of the box so they use DEP, and then leverage casper for all software.

[michael_devins]

While we don't normally make database knobs a "feature" in our release notes or docs, we added something that may be helpful or desirable for certain organizations. If there is enough interest in this functionality, we could consider exposing this as a setting within Jamf Pro itself.

There's a database knob for "com.jamfsoftware.jss.frontend.enrollment.mdmEnrollmentMacOSMinVersion" that defines the minimum macOS version that enrolls using the new MDM Enrollment Profile (based upon browser detection) for user-initiated enrollments. Default enrollment behavior is the new MDM Enrollment Profile on macOS 10.13.0 and later.

The value can be any valid macOS version going back to macOS 10.10.0. Undefined parts will be assumed as zero, e.g. "10.13" is equal to "10.13.0". "10.13.2" is the most precise and nothing will be assumed to be zero.

For example, setting this macOS version to "10.12.0" will ensure that Macs running Sierra will also enroll with an MDM Enrollment Profile instead of a quickadd.pkg. I would recommend testing with common browsers as some provide inconsistent macOS version reporting. Safari provides a reliable experience. When unknown, Jamf Pro will default to quickadd.pkg.

[Look]

Sigh just started playing with this on 10.13.4
I really don't want to go to DEP until Apple makes it a zero touch process, who really wants to have to step through the setup wizard on hundreds and hundreds of lab computers before they will download any additional software!

[Chuey]

@Look Tell me about it! Everyone keeps telling me DEP DEP DEP but I have 6K plus devices that were never setup with DEP -- now I get told to go DEP and really there is no other option for me?

I have a zero touch deployment right now -- boot to Deploystudio, name the computer, click play and walk away. Literally! I'm really having a hard time with DEP with such a large environment of existing devices. I like automation -- not wizards and mouse clicks.

I don't like how they throw around zero touch deployment with DEP -- it's not zero touch. Also when IBM threw around zero touch -- yeah -- zero touch for their IT because they just handed the clients their devices and THEY TOUCHED It -- so it was zero touch for them but it was not a true zero touch.

I like DEP for out of the box - brand new devices but not for existing deployments.

I'm really stuck in a hard place right now on what to do. I have a way to automate clicking the 'approve' button and it works -- only problem is I have to give the "terminal" app accessibility access under Security and Privacy. You use to be able to script that but now SIP killed that!! UGH!!

If you figure out something with it - post back and let me know - right now I'm not sure what I'm going to do and summer is quickly approaching.

[jtrant]

Watching this thread with anticipation, since I'm in a similar situation. Not every Mac can or will ever be DEP-enrolled in our environment, so we need a backup deployment workflow for High Sierra which is zero-touch.

[allanp81]

@Chuey You mention you have a way of approving automatically, can you elaborate?

[Chuey]

@allanp81 Yes, there is a way to script it -- BUT in order to run the automation script ... you have to give either Script Editor or Terminal access under "System Prefs > Security & Privacy > Accessibility" ... You cannot automate adding an app to that section unless SIP is disabled. So in my situation even tho this script works -- it takes me more mouse clicks and key strokes to add the app to that area than to just click approve. But here is the way I accomplished it if you're still interested:

Remotely Approving UAMDM

[allanp81]

@Chuey I think I ended up finding your blog yesterday anyway, it's very annoying that at present we as admins can't get round this.

[el2493]

@emily thanks for that information about 10.3 providing the MDM profile rather than the QuickAdd package for enrolling on High Sierra. Had a few techs reporting the "Approve" requirement (we're currently on 10.2.2 and not using DEP, so everything's still QuickAdd packages), am looking at upgrading to 10.3.1 as soon as possible.

[timlarsen]

Hey all, I am wondering if anyone else is seeing the issue (feature?) I am seeing in 10.13.3 and 10.13.4. I happen to have an all-DEP workflow at this point in time, but with a couple of different configuration workflows. One is fairly straightforward where the end user creates their own local user account as part of setup, and then that user does not have to approve the MDM profile. No problems here. The other is where no user (aside from a local management account) is created, and additional users are created via Self Service with some cocoa dialog scripting I've done. These additional users also don't seem to have to approve the MDM profile, EXCEPT when I install a user-based Wi-Fi/Active Directory certificate profile for them, and then all of a sudden the MDM profile becomes unapproved (even when I log back in as the local admin). At first I thought this was a bug only with 10.13.3 but then noticed it in 10.13.4 too (but it sounds like UAMDM has been a thing since 10.13.2 anyway). Any insight would be helpful as always, thanks!

[timlarsen]

You know what, duh... forgot all about this: https://www.jamf.com/jamf-nation/articles/372/enabling-mdm-for-local-user-accounts. This explains my problem I think.

[pueo]

Hello Everyone

Read all the posts and are having similar issues to most folks on this post. Thanks @timlarsen for the link. Explains my issue, but not sure of how my new workflow will be.
VPP was working great until Jamf 10 (i think) and Apple introducing UAMDM. Since then we can no longer push out VPP to lab machines unless logged in as a (MDM Capable account) AD account (Lab machines bound to AD at this stage). Super annoying and does not look good for Jamf. I read Profile Manager can install VPP apps no problems.

P.

[#32]

This is killing me.

[Chuey]

@bdtracey it's awful...

[Winterhalter]

At least as far as kernel extension use goes...

Per Faronics:

To disable User Approved Kernel Extension Loading, boot into macOS Recovery and use the 'spctl kext-consent disable' command to completely disable the feature

Per the related Apple doc:

If you're managing User Approved Kernel Extension Loading using the spctl command and you reset NVRAM, your Mac reverts to its default state with User Approved Kernel Extension Loading enabled. You can set a firmware password on your Mac to prevent unauthorized changes to NVRAM.

https://support.apple.com/en-ca/HT208019

If you check the man page for spctl it looks like it can have some interesting uses. It also looks like it's a bad idea to completely disable spctl itself, so be careful.

[ostrowsp]

Any one have any idea how long it takes for the Jamf binaries to come over once the CA and MDM profiles have been installed? It's be over an hour and nothings installed yet

[MBrownUoG]

Hey folks. Quick question regarding our experiences with this:

We're currently using DEP for all our new devices, and we're on Jamf Pro 10.2.2 at the moment. We're still needing to user-approve the MDM profile for every single device however... is this expected with the versions we're on? Would upgrading our Jamf installation remedy it?

[tnielsen]

So there is still no way to "auto approve" the MDM profile unless you use Device Enrollment method? Irritating..

[tnielsen]

Hey, so I found this guys site which has a great idea. It's not full automation of profiles but it DOES allow you to do this remotely!
https://jerbecause.wordpress.com/2018/02/18/remotely-approving-uamdm/

The idea is you can enable apple script editor to have control of the computer using (Manual step everytime) System Preferences -> Security & Privacy -> Accessibility -> + Script Editor. Once it has been given control, you can simply run the below applescript to approve the MDM Profile. Great job apple, you really secured those computers! /s

tell application "System Preferences" to activate

tell application "System Events"
    tell application process "System Preferences"
        set currentWindow to name of window 1
        click button "Profiles" of scroll area 1 of window "System Preferences"
        delay 2
        click button "Approve…" of scroll area 1 of window "Profiles"
        click button "Approve" of sheet 1 of window "Profiles"
    end tell
end tell

[AHolmdahl]

@tnielsen Im 99% sure that that won't work. The Accessibility settings are also protected.

[donmontalvo]

Apple plugged that hole once word got out.