Skip to main content

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.




Nice post, thanks for the breakdown and workaround. SIP can definitely cause some frustrations when the workaround isn't really scalable. This is not TCC-related, but my org also had a situation where it wasn't practical for users to jump from Yosemite or El Capitan to Mojave because of some quirks with Centrify. Our poor test user had their Mac wiped with a fresh install of Mojave, but for quite a few people we had to upgrade them to Sierra first (to receive a Centrify patch), then up to Mojave.

@bvanpeski thanks for the great write up. It looks like the permissions and ownership CAN be changed before upgrading. I'm just in the process of upgrading from an El Crapitan device to Mojave after altering the permissions and will see if the PPPC stuff then works ok.

@bvanpeski You are a genius! That sorted my issues out!

Workaround Update



For those curious about the engineering solution we've been working on, I'll update this post with notes/process.



Requirements
1. Pre-Stage macOS Mojave Installer and JAMF QuickAdd.pkg to the machine.
2. Ensure machine is connected via ethernet, since wireless profiles will be deleted upon erase & install and the machine won't be able to enroll without an internet connection.
3. Use the above as your scope (Has: Installer + QuickAdd pkg and is connected via ethernet)



Process
1. Use the eraseinstall command to kickoff the installer and enroll the machine when it's done.
NOTE: The drive needs to be APFS formatted for this to work. The command looks like this: 



"/Applications/Install macOS Mojave.app/Contents/Resources/startosinstall" --eraseinstall --agreetolicense --installpackage /Users/Shared/QuickAdd.pkg --nointeraction


Once the process is complete, you will have a brand new out-of-the-box macOS that is enrolled in JAMF.
2. Kick off the rest of your policies and you're good to go!



Note: Apple has a secureToken (read more) it assigns to the user created during the setup assistant or the first user to log in on a new machine. A secureToken is required for turning FileVault on for a user. However if you are creating the first user via command line, that user doesn't auto receive a secureToken. While it's not something we need in our environment, I just KNOW that at some point in the future Apple is going to require it for something and I want to make sure there is at least one account on the machine with such a token.



If you're creating a user via the command line, you can have a secureToken assigned to it by setting it to auto-login for the first time (use kcpassword if the account has a password assigned). You probably want to give this to an admin account. For security you can simply delete the kcpassword file and switch off auto login for for your admin user when creating subsequent user accounts to prevent that admin account from auto-logging in and from having the login credentials stored on the machine.

@bvanpeski , thanks so much for the great explanation. This is the exact same issue we were seeing on our machines that we were doing in place upgrades on. We have had a support case open with Jamf for the past two weeks and hadn't gotten anywhere.



Unfortunately we don't have the luxury of wiping every machine, so we'll be disabling/enabling SIP quite a bit for the permissions change prior to the Mojave upgrade. Fortunately, I think a large number of our Macs don't fall in this category.

@bvanpeski AWESOME find and thank you so much for posting! I was able to fix my Mac so I could properly create policies for the rest of the fleet! :)



[edit]



Interestingly, when in Recovery Mode SIP isn't enabled on Macintosh HD, so all I needed to do is the following command.



chmod 755 /Volumes/Macintosh HD/Library/Application Support/com.apple.TCC

Reply


Terms & ConditionsCookie settings