Posted on 04-12-2018 12:44 AM
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?
Solved! Go to Solution.
Posted on 04-12-2018 04:01 AM
This is due to a bug. Contact JAMF support.
I would also encourage you to vote for these two feature requests:
Posted on 05-02-2018 04:10 PM
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
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:
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.
Posted on 07-24-2018 01:08 PM
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.
Posted on 07-26-2018 03:59 AM
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)
Posted on 07-26-2018 05:04 AM
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.
Posted on 08-16-2018 09:26 AM
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?
Posted on 08-16-2018 09:32 AM
@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.
Posted on 08-16-2018 09:35 AM
I suspected this was the case but wish they explicitly stated the resolution in the release notes.
Posted on 09-05-2018 04:23 PM
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
Posted on 09-17-2018 12:04 PM
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.