"Disallow Camera Devices: True"?

Anyone know if there is there a PI for this? Hoping it's fixed in 10.4

Got the same issue. Can't create a new config profile with a security & security config without the camera being disabled.
I tried to add another config to specifically allow camera (Restrictions: allow camera) but still not working.
Got a support call open for it so we'll see.

@CasperSally Join the beta for 10.4. I made a discussion for it.

It’s PI-004822 btw.

We got bit by this today too - made a small cosmetic change yesterday to our security profile, only to find that we have shut off cameras on thousands of machines. Not good at all...

We were apparently able to fix this by configuring a Restrictions payload, per jamf support. Up to now, however, we had not deployed this payload to most of our machines - so why in h311 this would get written into the normal security settings profile is the big question (aside from how soon is this going to be fixed)??

@chris.kemp Major issue for us too. Do you know how you fixed it with a restriction profile? I created one which has camera allowed in it but the camera still doesn't work.

Seems to got it working by creating a "Restriction" and then select the "Restrict items in System Prefs" and "Disable selected items" (without selecting anything) and then "Allow use of camera" in "Functionality".

(and it stopped working again as soon as I made a change to the Security policy).

Thanks, I've put in a support case regarding this issue. Glad (well not glad, but you know what I mean) that I'm not the only one seeing this issue.

I can confirm the issue, we are seeing it as well.
I have downloaded the profile with the key redirection, stripped the signing and sure there is a restrictions payload that contains:

... <key>allowCamera</key> <false/>
...

Opened a support case to get the count and pressure up.

BTW, it disables content caching as well.

I just ran into this issue too and it took a lot of time troubleshooting to realize that this was being caused by one of our Configuration Profiles.

The best way I found to fix this is to include a copy of com.apple.applicationaccess.plist as a Custom Setting with the SAME profile.

From past experiences (ie: Security & Privacy Configuration Profile bug in Casper 9.82) I have realized that the best way to counter Jamf including payloads/preferences that you do not want configured, or are being configured incorrectly, is to include a Custom Settings payload with the affected profile that explicitly defines the settings you want. This method seems to avoid running into issues with payloads being Undefined (since they conflict), although I am not sure why so PLEASE TEST FIRST!

Also, make note that as of Jamf Pro 10.3.1, the Security & Privacy payload is also including the following keys in the profile that are only supposed to be configured by using the Restrictions payload (where most of the com.apple.applicationaccess keys are supposed to be configured) in a profile:

<key>allowAirPrint</key>
<false/>
<key>allowAutoUnlock</key>
<true/>
<key>allowCamera</key>
<false/>
<key>allowContentCaching</key>
<false/>
<key>forceDelayedSoftwareUpdates</key>
<false/>

Please note: The allowAutoUnlock and forceDelayedSoftwareUpdates are not really doing anything, since they are not applying a restrictive setting, so you don't need to include them in your Custom Settings plist. That being said, they still aren't supposed to be included with the Security & Privacy tab.)

Also of note, it seems this has been fixed in, at least, Jamf Pro 10.3.1, but in earlier versions of Jamf Pro 10 the Security & Privacy tab was also including the following key:

<key>allowAirPrintiBeaconDiscovery</key>
<false/>

I have included a copy of the com.apple.applicationaccess.plist file to upload with your Security & Privacy profile that should fix this issue as well as counter the other included keys that we are not trying to configure:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>allowAirPrint</key>
    <true/>
    <key>allowAirPrintiBeaconDiscovery</key>
    <true/>
    <key>allowCamera</key>
    <true/>
    <key>allowContentCaching</key>
    <true/>
</dict>
</plist>

You can also download the plist file here: https://www.dropbox.com/s/qgipritkydepz0w/com.apple.applicationaccess.plist?dl=0

In addition, if you are ever curious about whether your preferences are being applied properly then you should run the following Python script (courtesy of dataJar from the notes of their 2016 JNUC presentation), which will tell you the value of the preference key you specify, as well as whether the preference key is being forced or not:

#!/usr/bin/python

# Copyright 2016 dataJAR Ltd.
# 
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
# 
#     http://www.apache.org/licenses/LICENSE-2.0
# 
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

import CoreFoundation

domain = 'com.apple.applicationaccess'
key = 'allowCamera'

key_value = CoreFoundation.CFPreferencesCopyAppValue(key, domain)
print 'Key Value = ', key_value

key_forced = CoreFoundation.CFPreferencesAppValueIsForced(key, domain) 
print 'Key Forced = ', key_forced

The other notes (and this script) are available on their GitHub page here: https://github.com/dataJAR/jnuc2016

You can also use the System Information app on macOS (Go to "About this Mac" and then click "System Report") and look under 'Software' -> 'Managed Client' to see the preferences from a profile's payload and how they are resolving on the machine.

I would highly encourage anyone who reads this to vote for the following Feature Requests so Jamf will rework how they deal with Configuration Profiles so we can, hopefully, avoid these kinds of issues in the future:

Please re-work how configuration profile payloads are managed
Break Up Multi-MDM-Payload GUI Payloads
Select which keys to enable and include in a configuration profile

Also, last thing, make sure to Contact Jamf as well for any other help. As noted in the first response to this thread, this is a known bug.

Mlavine,

I just tested your solution with JAMF version 4.1 and it did not work for me? Have other folks been successful using this fix?

Thanks, ~B

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.

Hi tjhall

I have noticed that if I follow your recommendation I get the following behaviour on computers still on 10.12.6

If I add "Restrictions/Functionality/Camera allowed" ( and a few others as we allow for TouchID) users will get their TouchID reset forcing them to set it up again ( And a flood of tickets " I lost my 3 FPs on my Mac" )

I am also see this result for 10.12 user and 10.13 after enabling restrictions with the security and privacy payload as suggested by @tjhall . Any suggestions on getting TouchID to work? Configuration profile states that its allowed but cannot get TouchID to work with it as stated by @frankp .

Unfortunately I've not come across the Touch ID issue (we don't have any Mac's with touch) but had similar issue with users saying they had to set up iCloud again.

Bit of rock and a hard place. We use web meetings constantly and all the camera's were disabled throughout the company so the workaround was a necessity.

Does it prevent users from using Touch ID or is the issue they have to set it up again? I suppose it could be scoped to exempt the Touch ID ones but that possibly leaves them with te camera disabled. Only other option is to wait for a Jamf update or push out separate script file,

After enabling encryption, our users started facing issue with facetime camera. Stopped working

If you are using a config profile to allow the camera, you will have to add that payload to every new config profile until JAMF resolves the issue. I would have your account added to the PI in hopes that they resolve quicker.

yes, I tried adding the payload under the Filevault configuration profile to replace the com.apple.applicationaccess.plist to allow camera set true. Also that is only payload we have under configuration profile.
It is getting applied for first time, there from second reboot.. the setting is not getting applied to other mobile user profile, it works only for local users in that macbook.
hmm, JAMF need to take quick fix, as came a showstopper for handing filevault from security perspective.

We experienced the camera-disabling bug, and created a Restrictions profile to re-enable it. That fixed the camera issue, but has also seemed to introduce another issue of applying app restrictions even when that is not enabled in the Profiles config UI.

I have seen the same (jamf 10.4.1). My security profile (only FileVault settings managed) has not changed last few months. Two Macbooks updated to 10.13.5 now have 'camera disabled' .
Is this coincidence? or does 10.13.5 interpret the same profile differently?

Workaround: add restrictions payloads, with all things allowed. see also FR 7269

This popped up in our environment last week, out of nowhere....
And when i looked at our Config Profile that featured we found that JAMF had injected that garbage into the profile that we didn't configure...
They really need to do the implement the feature requests that are mentioned above, i had to the custom settings above to fix the issue--
The custom settings fixed the issue, even thought that profile still shows a 'Restrictions -> disabled allow camera devices = true' in the GUI...

We had to work through a different profile issue we had, and when we sent a copy of profile (from the jss), Apple Support commented that it was filled with extra junk for some reason, so it's clear that this is a real need to re-do the MDM profile creation on the JSS...

Up Vote these now! this is ridiculous---
https://www.jamf.com/jamf-nation/feature-requests/7269/please-re-work-how-configuration-profile-payloads-are-managed

https://www.jamf.com/jamf-nation/feature-requests/1699/implement-a-bug-reporting-and-tracking-system-on-jamf-nation

@mlavine , Thanks for the help. Your solution and .plist as a custom payload worked perfectly.

I'm running into the same problem as @msg4karth where the workaround stops functioning after a reboot. Any ideas on how to make this more sticky?

Yes - my thrill was short lived when the end user reported after rebooting the behavior is back.....

Aside from applying and additional restrictions payload, are there any other options....

I'm testing out a profile using 'custom setting' profile using plist/mcx format instead of the Security & Privacy settings, and so far it seems to be working in my tests...
It seems to be doing the things i want without the Restrictions garbage getting add to the profile...

JAMF said that version 10.6 should address this, although i don't know if this is another 'bandaid' fix...
(i highly support eh feature requests above, the config profile section of the JSS could be done better)

It's very frustrating to have the JSS inject garbage into your profiles.

Also, i found with version 9 of the JSS, it seemed that you could upload 'signed' profiles and it would distribute them 'unaltered' unless you unlocked/de-signed them... I don't seem to be able to do that with 10, i think it's only taking 'plain text' versions of profiles.