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.
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.
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.
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.
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.
Anyone really good at making AppleScript click buttons?
@ericbenfer no UI scripting for that button.
I wonder why this wasn't brought up at WWDC last year?
C
Hopefully a solution will pop up for that.
BR
Daniel
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...
@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…
@emily Hmmm... not getting that result... am I Holding It Wrong
?
@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...)
@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.
@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.
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.
@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?
@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.
@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.
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.
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!
@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.
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.
@Chuey You mention you have a way of approving automatically, can you elaborate?
@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
