This is an issue we ran in to when deploying the macOS 10.14 Mojave upgrade to a group of pilot computers. In our lab tests everything worked fine, but I'll explain why the issue cropped up and the required solution here in case anyone else finds it helpful.
SETUP
- Computers have a LaunchAgent that triggers a shell script that sets the user environment (dock, wallpaper, desktop icons) depending on what user is logged in.
- The script itself is properly signed.
- We have a configuration profile giving the signed script access to Finder/PostEvent.
In our testing, this setup resulted in the script launching properly and it set the environment as expected without requesting approval by the end user. However, when deploying this to our group of pilot machines, half of the machines had the script reverting to asking for end user for approval even though the script was signed and the correct configuration profile was installed.
THE WHY
End-user approvals and configuration profile approvals are stored in /Library/Application Support/com.Apple.TCC. Inside of that folder is a database (tcc.db) that records end user approvals as well as an MDMOverrides.plist that contains approvals pushed from JAMF. (I believe this plist only shows in Mojave).
The reason that we were seeing this prompt, even though everything was in place to ensure it worked properly, is that the machine isn't able to read that MDMOverrides.plist file.
In macOS 11 El Cap, the permissions on this folder are drwx------@ 4 root : admin. The CORRECT permissions that appear in later versions of the OS is drwxr-xr-x@ root : wheel. Unfortunately, these folder permissions are never changed during macOS upgrades from 10.11 to newer operating systems and at some point (10.13?) the folder became SIP protected, making it nearly impossible to change the permissions on the folder manually without jumping through a lot of hoops. Without the ability for a machine to read the .plist in that com.Apple.TCC folder, it's not able to authenticate that the script is whitelisted by the configuration profile and fails over to prompting the end user to manually approve.
THE SOLUTION
Due to the fact that this folder is SIP-protected, the only reliable solution is to wipe the computer and re-install a newer operating system from scratch to ensure that the proper permissions for com.Apple.TCC are laid down.
Yes, you CAN disable SIP, change the permissions, then re-enable SIP, but this isn't a scalable or scriptable solution.
We're in the process of automating the process of clean install macOS on our machines, but it will likely require pre-staging the macOS installer and QuickAdd package and making sure the machine is enrolled in DEP so that the MDM profile can be approved without end user input.
I hope anyone else running into this issue finds this post helpful. If you have machines that were deployed with macOS 10.11 that have been upgraded over time and you're wondering why your configuration profile whitelists aren't working, this is likely the culprit. We've opened up a bug ticket with Apple so hopefully they can resolve it in future releases.
