Our solution has been to identify the critical/core apps that all of our users use on a daily or regular basis, and create a unique config profile for each of those applications/scenarios. You do have the option of having one large PPPC config profile, but currently there's no way to edit the config profile in jamf on the server side, and I wouldn't rely on their PPPC utility to go back and edit existing profiles. With that in mind, having individual profiles for each application makes it so that you can easily change something inside the profile without needing to rewrite the whole thing from scratch. Again though, I wouldn't do it for every application. Allow users to make the choice on non-critical apps, and provide an option in self service to reset their permissions if they accidentally choose the wrong option.

Having test users that can take screenshots of the PPPC prompts was very helpful at my org. At first I made a giant profile with everything, but over time as I've made adjustments or additions I've slowly split each app off into its own profile.

I agree with @float0n that you can't reasonably whitelist everything, so I focused on the core apps that we provision. Anything else is educating users as to what to expect. I also followed this suggestion of creating a self-service item to reset the TCC database if a user unintentionally clicks deny when they should have allowed something.

Thanks
@float0n and @sshort - You've answered my question, its not a bug, its a feature!

Thanks for the help!

I am also coming to the conclusion that every single app that has ever seen the light of day here will need a PPPC config created for it. This is not at all feasible. I don't know that I could ever do this because we do a lot of java development and our devs do things in bash, sh, zsh, and a few other shells. In my limited testing, I've seen prompts to allow the various shells to have access to various things. I hate to see what i'm going to have to do with homebrew!!! Today I had to figure out how to create a freaking PPPC profile for the Zoom Outlook Plugin. This will be a full time job just creating PPPC and approved kext profiles. It's all the background, support processes/apps, and plugins that will get you because you, as the admin, may never in a million years try each and every possible option within an app to discover the ones that trigger PPPC prompts, but the users might.

If a user gets prompted for something I have not seen yet and they click on Do Not Allow when they should have clicked Allow, will a PPPC profile installed afterward override that denial of access?

@AVmcclint In my testing anything that a user approves (or denies) can be overwritten by a PPPC profile. Camera and mic access are somewhat of an exception in that an MDM can't approve those for the user. So if they click Don't Allow (or even just ignore the pop up until it times out) you'll need to put something in self-service so the user can resolve the issue.

tccutil reset Camera
tccutil reset Microphone

Has anyone installed profiles that don't work as configured? We have set one up with an Apple Event to allow access to MS Outlook, yet the user still gets the Allow/Don't Allow prompt .

@macmanmk

I had this problem with setting PPPC on BitDefender for full disk access. The solution was to provide the full path to the binary in the Indentifier instead of just the binary name, so we have 2 entries.
You also have to provide the PPPC profile with ALL the binaries that the app will be communicating with, refer to

Jamf Events Profile
Jamf PPPC Compendium

I'm just barely getting started with Mojave and it is already getting out of hand. I just upgraded a eager user's Mac to Mojave yesterday and within 15 minutes he was prompted for 5 different PPPC related actions! Including one to allow the Logitech driver to allow him to use the scroll wheel on his mouse! Then he sent me this screenshot:

Now we have to allow apps to access other apps? Has Apple given any official guidance on how to manage a Mac that runs more than Pages and Keynote? I don't have the time and resources to create PPPC profiles for each and every application and process and shell command that my users use on any given day. However if this is the only way to make sure the programs run the way they are intended, I can't afford not to create profiles either. What happened to the days when our Macs "just worked"?

This constant prompting reminds me of Windows Vista. Remember how well that was received?

@AVmcclint I'm with you on that one....I have one or two that live on 10.14 and usually it's something like this at least once or twice a week. On top of that, we use over 110 unique software titles in the district, if not more. I wish there was something like a plist manifest that showed all the possible requests that a given software title could ask for built in the app and then I could whitelist the whole thing, removing ONLY specific ones that we specifically do not want to allow usage to. Something like this would remind me of "Manifest Destiny"...having a nice listing somewhere of what titles are requesting, instead of relying on emails from end users or searching forum threads for "PPPC and <fill in software title here>" or "TCC and <fill in software title here>"

@AVmcclint

Out of curiousity, do you know which version of Outlook that is appearing on? I have not seen that one myself yet, but majority of my users are still on High Sierra. I've had to make profiles for several security related apps already (primarily Cisco related), but I have yet to see something like that. And I am fearing the day I do (although Skype will be gone soon)

My user got the message using Outlook 16.16.5. Later I tried it on 16.23 on another Mac after I built the PPPC profile then I got the same error in reverse for Skype needing to control Outlook. I recreated the PPPC profile so it allows Outlook to control Skype AND so Skype can control Outlook - all in the same profile.

Another thing about this that is highly annoying is that it is very difficult to replicate the alerts. Yesterday I had to build a profile to allow iTerm to access the drive. I tested the profile successfully, then when I quit iTerm it gave me a message that iTerm needed access to something, but I was in a hurry and didn't get a chance to take a screenshot or document exactly what it needed. I shut the mac off and figured I'd replicate the message this morning. I can't get the alert to come back up now and my user never saw that particular alert at all.

When writing one of these manually, where does one get the "code requirement"? I'm trying to write an allow for the NWEA secure testing browser.

Found this chat that is 100% relevant to my current blocker.
More and more apps within our macOS Mojave 10.14.x are requiring this PPPC permissions just to install and run simple applications.

Should we (as a community) come up with a list and PPPC settings required?
Sorry, I can't contribute much to this list, as I don't know any PPPC settings required.

So far I am seeing the "allow" pop-up when installing:
Symantec DLP
McAfee ENS 10.6.1
DisplayLink v5.1
Parallels Desktop
Junos Pulse Secure
FireEye

@Bernard.Huang What pop-ups are you seeing for Symantec DLP? Our org uses that service, and we've never encountered a PPPC permission warning, so curious as to what you saw. My org made Mojave available in self-service about a month after release with a set of PPPC profiles that whitelisted our core apps. We've never included DLP b/c we never got a warning.

We're definitely seeing Symantec DLP PPPC pop-ups.
We are installing Symantec DLP v15.0 onto Mojave 10.14.2 and beyond.

I also notice for McAfee ENS, when we install 10.2.3, there is PPPC.
When upgrading from 10.2.3 to 10.5.9, there was no PPPC question. I suspect it is because it is already allowed.
When upgrading from 10.5.9 to 10.6.1, there was the PPPC question again.

For ALL these applications, I would love to know what app name it is kicking off, that is triggering this PPPC.
Then I can get on with creating the .mobileconfig file to cater for them.

Hi @mlizbeth

I'm reading your screenshot.

Could you share how you got the Code Requirement information = identifier "com.bitdefender.EndpointSecurityForMac" and anchor..... ?

And what is this Code Requirement field used for?

Update

I got it. Some more research show if I put in codesign -dr - /path/to/app , then the Code required will show.

Example:

codesign -dr - /Library/PrivilegedHelperTools/DisplayLink/DisplayLinkUserAgent.app

Executable=/Library/PrivilegedHelperTools/DisplayLink/DisplayLinkUserAgent.app/Contents/MacOS/DisplayLinkUserAgent
designated => identifier "DisplayLink.DisplayLinkUserAgent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] / exists / and certificate leaf[field.1.2.840.113635.100.6.1.13] / exists / and certificate leaf[subject.OU] = "73YQY62QM3"

@AVmcclint - I'm with you on this PPPC bs.

I have a further question. If a user does dismiss the question and not allow the application to run properly, is there a way to get this question back?

I have a few users already stumbled when macOS Mojave ask for permission.

Since they don't have admin rights, I have to push out admin rights, then manually uninstall the application. Then reinstall the application via Self Service again, then the PPPC pop-up will happen again, now we can select Allow.

I have found that if an app requests access to the camera or microphone and the user disallows it, they can go into System Prefs > Security > privacy and change the settlings for Camera and Microphone even if they aren't admins. That's all I've been able to confirm though.

@Bernard.Huang Ah ok, yes that's a screenshot to approve the DLP kernel extension. And we definitely have a kernel extension whitelist profile for that, but that specific warning is not PPPC.

@sshort

Thanks for clarifying.

Sounding like an amateur now.... What's the difference between Kernel extension and PPPC?

I'm asking from the perspective of how to automatically allow it. For Kernel extension or PPPC, don't I need to set up the Privacy Preference Policy Control just the same?

@Bernard.Huang User Approved Kernel Extensions arrived with High Sierra 10.13.4, Privacy Preferences Policy Control arrived with Mojave 10.14. They're different things despite both being things a user has to visit the Security & Privacy panel in System Preferences to approve if you don't get your configuration profiles right.

@Bernard.Huang This is a good post on kernel extension whitelisting

They're similar in that users have to explicitly approve access to enable them (or an admin with an MDM can whitelist), but they have separate profile payloads. Kernel extension approval is for a (hopefully) rare type of app that requires some process to work at the kernel level of the OS, so things like antivirus, virtualization, or other security apps. PPPC is going to be more common in that any app that wants to access data from another app, or user data like photos will get a permission prompt.

Wow, my mind is blown! Thanks @sdagley & @sshort You guys make me look like a complete amateur. And in a good way, I am learning a lot.

I shall get this whitelisting started.

This is a good post on kernel extension whitelisting really is a great article.

Wish me luck in getting all the kernel extensions.

Hi all,

Just find out how to find out all Kernel Extensions and their team Identifiers.

This is from page
https://technology.siprep.org/getting-the-team-id-of-kernel-extensions-in-macos-10-13-and-higher/

So the line is

sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy

SELECT * FROM kext_policy;

Here's an example of the output I got

Sorry to have taken the focus away from PPPC.

Hey,

Just wondering whether anyone has had success with Adobe After Effects? I'm trying to pre-approve its access to control Finder but it's not working. I noticed that when I run codesign on the After Effects app, the output from the 'designated =>' field has no bundleID in it. All the other pre-approvals in my config profile have a bundleID listed in the code requirement field and they work perfectly. Am I missing something?