We’ve pushed out some config profiles that contain 4 pre–approved 3rd party kernel extensions.
Once received by the clients their facetime cameras would no longer work. When removing they payload from the config profile, camera access was restored.
Anyone else seeing this?
There is currently an issue in Jamf where it will inadvertently add extra config profile payloads for restrictions to unrelated config profiles. The only way I’ve seen to work around this is to manually edit config profiles, sign them so the JSS won’t mess with them, and then teupload them and tell the JSS to leave it read only and not strip the signing.
Contact support and tell them the issue so they can add you to the product issue number so they will make fixing this a higher priority.
This is not the first time this has happened. You guys might be interested in this Feature Request:
I'd encourage you to vote it up. The issue you are running into is used as an example in the FR as to the problems with Jamf Pro's management of Configuration Profiles.
We are starting to have this issue as well. Turns out the issue is related to a configuration profile that enables the firewall on any Mac that has it disabled. Any Mac that has 10.13.3+ that had a disabled firewall and was receiving this profile was getting the fated black screen in any web conferencing app. Was getting an error in the logs of the profile on the same machines after updating the config profile on redeployment, but removing them from scope on the config profile, removing the Jamf framework (sudo jamf -removeFramework) and re-enrolling into Jamf resolved it. Seems like a bug, or Kext issue that isn't easily resolved in High Sierra. Almost seems like Jamf should take the "security and privacy" option out if it's going to break things in High Sierra..
Can anyone that's seeing this problem verify the unexpected restrictions are actually listed in the Profile Settings for the errant Profile in System Preferences? I'm curious if the restriction is being applied without being visible as I'm experiencing a problem with a password policy being applied on our Macs and I haven't found where it's coming from yet.
I have had this issue with a Login Window payload in a configuration profile. Simple fix is to add a Restrictions payload to the Login Window payload, and set the Restrictions to allow the use of the camera.
Yes, if you look at the profile on the Mac it states that the particular profile restricts the use of the camera. It clearly stated that there were restrictions, even though at that time there were none applied to the policy.
This has been fixed in JSS 10.6.
Problem is that it suddenly manifests itself once a change is done to any existing config profiles and casues a lot of confusion.
Best working workaround (apart from upgrading to JSS 10.6) is to add "Restrictions/Functionality/Camera allowed" to any "Security and Privacy" config payload.