"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

bpavlov
Honored Contributor

CasperSally
Valued Contributor II

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

tjhall
Contributor III

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.

bpavlov
Honored Contributor

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

It’s PI-004822 btw.

chris_kemp
Contributor III

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)??

tjhall
Contributor III

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

tjhall
Contributor III

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

jonlju
Contributor

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.

Andreas_Schenk
Contributor
Contributor

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.

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.

bcrockett
Contributor III

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

tjhall
Contributor III

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.

frankp
New Contributor

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" )

matin
New Contributor III

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 .

tjhall
Contributor III

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,

msg4karth
New Contributor III

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

jconte
Contributor II

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.

msg4karth
New Contributor III

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.

blinvisible
Contributor

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.

maurits
Contributor

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

kstrick
Contributor III

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

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

acaveny
New Contributor III

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

eosrebel
New Contributor III

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?

acaveny
New Contributor III

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

kstrick
Contributor III

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.

gregreznik
New Contributor III

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

gregreznik
New Contributor III

sorry for the double post, cant delete for some reason

dwilks_
New Contributor

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.

andrewh
New Contributor II

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?

acaveny
New Contributor III

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.

doylema
New Contributor III
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!

yadin
Contributor

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

jbutler47
Contributor II

Removed post. Pending update.

dgreening
Valued Contributor II

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.

jkuo
Contributor

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

jay2dajay
New Contributor

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/>

sgorney
New Contributor III

Looks like 10.6 just dropped. Will update soon and see.

afarnsworth
Contributor

Didn't see anything in the patch notes for 10.6 that says this is resolved. How unfortunate...

andrewh
New Contributor II

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