Had this happen this morning in our environment, and used the functionality restriction profile to enable the camera... but then all iCloud services AND Touch ID got disabled. Now users have to reregister their fingerprints again... pain in the butt if you ask me...wish there was better communication on JAMFs part to notify us of this before our end users had too...
sorry for the double post, cant delete for some reason
I deployed the 'custom setting' and it appears as though it's getting overwritten by the root level managed preferences. I eventually had to deploy a restrictions/functionality payload alongside my FileVault2 security & privacy payload. It'll be nice once this is fixed and Jamf isn't randomly inserting restrictions into configuration profiles. I have to keep testing to see the effect of the restrictions as far as TouchID goes. So far, my own machine hasn't informed me to set up my fingerprints again.
I've been tracking bug number PI-004822 for this and it's still listed as a known issue in the 10.5 release: http://docs.jamf.com/10.5.0/jamf-pro/release-notes/Known_Issues.html
I'm amazed it's still not fixed yet. What is taking so long? How does Jamf not consider this a major issue?
I too was surprised that it was not addressed. I've been told from the ticket that I opened is that the issue is marked resolved for version 10.6. I asked when 10.6 would be released, and the person I spoke with did not have that information.
The custom setting worked until the user rebooted their machine. I too had to add the restrictions payload and then allow camera settings. Side effect of that was that anyone who had fingerprints setup on newer MacBook Pros lost all their fingerprint settings - even though I had allowed them in the payload.
Because FileVault2 is usually a policy standard for most institutions, just about everyone is using a configuration profile to escrow the keys. The fact that I had to add "restrictions" to "allow" functionality combined with the fact that I had to piggyback it off the same configuration profile that is deployed to EVERY 10.13.x machine is quite frankly a crap workaround.
Posted: 5/16/18 at 5:45 AM by tjhall
Best working workaround for now is to add "Restrictions/Functionality/Camera allowed" to any "Security and Privacy" payload.
I've tested this and it works.
I sent a 2015 MacBook Pro to Apple thinking there was no way it could be JAMF. I clearly have Allow Camera checked off in my restriction profile. They replaced the logic board and display assembly.
The real fix was to add "Restrictions/Functionality/Camera allowed" to any "Security and Privacy" payload.
I should have done more research :)
YIKES!
This is absurd. Dear JAMF, what the heck are you thinking??? Real simple, do NOT do anything to change OS defaults unless we put a policy/profile in place to change it!! The fact that I have to discover a problem by user report, do research, find this thread, add a payload to our baseline policy to re-enable all the things you're turning off by default for no reason with no notice, is just unacceptable. This is NOT how this software should work, and it's making life more difficult instead of easier....
Removed post. Pending update.
For whats its worth I have seen this on two 10.13.5/6 Macs out of ~6000 10.13 Macs to which this profile is deployed. Our Restrictions configuration profile does not restrict the camera, and the only way I can replicate this is to explicitly restrict the camera. Our Jamf is 10.5.
Hi there,
We managed to just uncover this issue (we're on 10.4.1). For people that have added a Restrictions payload to any "Security and Privacy" payload, when you click save, do you do a "Distribute to All" or "Distribute to Newly Assigned Devices only"?
I figure I need to distribute to all to make sure everyone's camera is working, but I'm very wary of doing a distribute to all that might torpedo other things.
Thanks,
Jason
Hey Everyone,
I just spoke with JAMF Support. The appearance of the new restrictions below were enforced due to an update on their XML code. Their representative told us 10.6 will be released sometime this week to fix this issue. The workaround that solved our issue was our JAMF representative providing us the configuration profile in XML format and we removed the new restrictions from the code and uploaded/deployed the new configuration profile.
<key>allowAirPrint</key>
<false/>
<key>allowAutoUnlock</key>
<true/>
<key>allowCamera</key>
<false/>
<key>allowContentCaching</key>
<false/>
<key>forceDelayedSoftwareUpdates</key>
<false/>
Looks like 10.6 just dropped. Will update soon and see.
Didn't see anything in the patch notes for 10.6 that says this is resolved. How unfortunate...
@afarnsworth It's marked as being fixed as part of the 10.6 release notes (http://docs.jamf.com/10.6.0/jamf-pro/release-notes/Bug_Fixes_and_Enhancements.html)
[PI-004822] Jamf Pro no longer includes the Content Caching setting from the Restrictions payload when a computer configuration profile was configured with the Security & Privacy payload.
I haven't gotten a chance to upgrade and test it myself yet.
Ha, we just pushed out the temp fix this morning and then a few hours later the 10.6 upgrade lands. Oh well, I'll wait and see and then schedule the upgrade eventually.
All of this hassle is why I have reasoned to use custom profiles where I control the domain and the keys that get applied. As long as JAMF doesn’t start applying other domains when I deploy a custom profile payload, I’ll be good. It’s not pleasant to not be able to use the GUI options.
I created the following FR to have an advanced tab where you can manipulate the domains, keys and values that get applied directly (at least that is the spirit of it)
https://www.jamf.com/jamf-nation/feature-requests/7688/in-configuration-profiles-have-advanced-tab-with-all-the-domain-and-key-options
Fixed in 10.6
[PI-005793] Fixed an issue that could cause a computer's camera to become disabled when the Security & Privacy payload of a computer configuration profile was configured.
For PI-005793, does anything else need to be done after the 10.6 upgrade? Like: Re-push the existing Security profile? Re-create and push a new Security profile? Or does the offending camera restriction get removed after a client checks-in, post upgrade?
@analog_kid Based on my chats with Jamf support, I think you would have to re-push all affected Configuration Profiles to apply the fix. So you wouldn't have to re-create it, you would just have to re-apply it. It would not get automatically fixed on check-in.
@jkuo
I suspected this was the case but wish they explicitly stated the resolution in the release notes.
Thanks again!
Thanks for all your posts guys
We are running Jamf Pro 10.4.1
This problem has surfaced a couple of days ago
We used to have the Restriction (tick Allow Camera) and Firewall Configuration Profiles separately
Solution:
Now made the Restriction (tick Allow Camera) and Firewall Configuration Profiles into one and has solved our issue
@ jamfnc
Your solution worked perfect for our environment (JAMF 10.4.1 and macOS 10.13.6). We were having issues with Staff not being able to connect to their Document Cameras... by combining the Security and Privacy configuration Profile and the Restrictions Configuration Profile into one Configuration Profile instead of two separate ones it correctly picks up the proper allow / deny settings from the Restrictions... this incidentally also resolved an issue we were seeing with AirDrop not working on some of our pre 2017 MacBookPros.
Thanks
