Posted on 04-12-2018 12:44 AM
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!
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 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.
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 04-12-2018 04:06 AM
Anyone know if there is there a PI for this? Hoping it's fixed in 10.4
Posted on 04-12-2018 05:34 AM
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.
Posted on 04-12-2018 05:36 AM
@CasperSally Join the beta for 10.4. I made a discussion for it.
It’s PI-004822 btw.
Posted on 04-12-2018 07:34 AM
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)??
Posted on 04-12-2018 08:06 AM
@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.
Posted on 04-12-2018 08:14 AM
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).
Posted on 04-13-2018 07:45 AM
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.
Posted on 04-25-2018 06:57 AM
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.
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 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.
Posted on 05-15-2018 04:14 PM
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
Posted on 05-16-2018 02:45 AM
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.
Posted on 05-17-2018 11:10 AM
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" )
Posted on 05-17-2018 03:02 PM
Posted on 05-18-2018 04:17 AM
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,
Posted on 05-30-2018 02:49 AM
After enabling encryption, our users started facing issue with facetime camera. Stopped working
Posted on 05-30-2018 03:54 AM
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.
Posted on 05-31-2018 03:28 AM
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.
Posted on 06-01-2018 08:20 AM
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.
Posted on 06-02-2018 06:04 AM
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
Posted on 06-04-2018 09:47 AM
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...
Posted on 06-07-2018 01:27 PM
@mlavine , Thanks for the help. Your solution and .plist as a custom payload worked perfectly.
Posted on 06-07-2018 02:56 PM
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?
Posted on 06-08-2018 11:43 AM
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....
Posted on 06-08-2018 12:43 PM
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.
Posted on 06-08-2018 12:43 PM
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...
Posted on 06-08-2018 12:44 PM
sorry for the double post, cant delete for some reason
Posted on 06-12-2018 11:37 AM
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.
Posted on 06-12-2018 11:52 AM
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?
Posted on 06-13-2018 06:06 AM
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 on 06-22-2018 05:35 AM
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!
Posted on 07-10-2018 11:47 AM
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....
Posted on 07-10-2018 11:53 AM
Removed post. Pending update.
Posted on 07-11-2018 08:34 AM
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.
Posted on 07-17-2018 10:34 AM
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
Posted on 07-23-2018 05:40 PM
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/>
Posted on 07-24-2018 12:23 PM
Looks like 10.6 just dropped. Will update soon and see.
Posted on 07-24-2018 01:01 PM
Didn't see anything in the patch notes for 10.6 that says this is resolved. How unfortunate...
Posted on 07-24-2018 01:06 PM
@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.