"Disallow Camera Devices: True"?

jonlju
Contributor

Hi,

I'm wondering if anyone has run into the issue we've just started experiencing after upgrading JSS to 10.3.1. We have a configuration profile for handling screensavers and FileVault2 recovery keys. For some reason however this now also disabled camera devices.

I can see in the profile at a client that under "Restrictions" it says "Disallow Camera Devices: True". And I know it takes this from the Security & Privacy setting in the configuration profile because if I remove that part all together, the restriction is no longer there. However I can't for the life of me see any Restrictions-tab for this configuration profile in the JSS. Does anyone have any idea on how to solve this issue?

Thanks!432b48a2ebf84b02a5247d8b22ca6643

2 ACCEPTED SOLUTIONS

mlavine
Contributor

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

ad1117bd81d04bf0b00a12bda2b1265f

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.

View solution in original post

47 REPLIES 47

jkuo
Contributor

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.

cgolebio
New Contributor III

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

daz_wallace
Contributor III

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.

analog_kid
Contributor

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?

jkuo
Contributor

@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.

analog_kid
Contributor

@jkuo

I suspected this was the case but wish they explicitly stated the resolution in the release notes.

Thanks again!

jamfnc
New Contributor III

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

jimshreve
New Contributor

@ 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