10.9 Managed Preferences Workaround

I've a little write up on what's happening with a "work around" for MCX too.

http://macmule.com/2014/02/07/mavericks-preference-caching/

I've found throwing out the managed preference folder, then open terminal and run a killall cfprefsd works

@bentoms This command seems to work with the system preferences but not the application preferences. Thanks!

Quit the app, & then make changes & then kill CFPrefsd

I am, I delete the preferences, kill CFPrefsd with terminal, try to open terminal again and it pops up with the application access issue.

I've noticed that if a user goes to System Preferences >> View >> Customize >> hides a pref pane by unchecking it >> Quits System Preferences >> Relaunches System Preferences >> then goes to View again they have access to that Pref Pane. Is there anyway to block this?

@jimlee][/url - this is a known bug actually, at least to anyone that thinks normally. Apple on the other hand doesn't see this as a problem apparently. Yeah.
Its been around for several OS versions now so not even something new.

The only effective way I know right now to manage this, outside of doing something clunky like modifying permissions on the blocked Pref Panes to be only run by root (I don't recommend this) is to set up another Profile or MCX setting that always sets the HiddenPreferencePanes key in the com.apple.systempreferences.plist to an empty array and User Level Enforced. This prevents the end user from enabling any of the Pref Panes as 'hidden', System Preferences will still allow them to check any of the Pref Panes, but once they quit and relaunch System Preferences it will be back to unchecked and therefore won't show up in the menu.

Is it possible to set up the empty array using the JSS web interface? I cannot find an array option when creating a manual preference.

@nigelg - Using version 9.x of the JSS? If so I do think that capability was removed, which is a problem if you ask me. There's a feature request already out there to being that back here:
https://jamfnation.jamfsoftware.com/featureRequest.html?id=1642
Being able to create custom array based MCX settings was gold in previous versions of Casper. Not having that ability limits it too much in my opinion. And I've never heard a good explanation as to why it wasn't included in version 9 either, so I'm not even sure why it was removed.

The more up votes it gets, the happier we get!

I just voted for it. Can't believe its gone, trying to work out how to get round it but its a pain I didn't need. Already busy enough and now I have to work out how to re-engineer this - can I use a login script to use the defaults command to write the empty array into the mcx file then kill the cfprefsd process again.. what a headache..

i can log in as a user, pick up the managed preference which denies access to the system preferences then ssh as admin and run "defaults write /Library/Managed Preferences/<username>/com.apple.systempreferences.plist HiddenPreferencePanes -array" then "killall cfprefsd"

When I reload the system preferences, nothing is hidden anymore.

I'm not sure if that method will stick in the long run though. Once the JAMF binary does its requisite framework update it may remove that specific setting from the plist. since i believe it redownloads the settings from the server and reapplies the whole thing, meaning, I don't think it just applies changes. I think it overwrites the whole plist file with the settings it knows about. I say this because I have in the past used PlistBuddy to temporarily unlock a blocked System Preference Pane for myself, but usually later in the day its grayed out again when the framework is reapplied.

But let us know how if it continues to stay in place over time. Would be an interesting workaround if so.

Yeah its not working. When I say "nothing is hidden anymore" i mean that every system preference pane is available for use, rather than panes being disabled/greyed out. So once the MCX has been applied, I update it using defaults directly then restart cfprefsd and every pane is available after restarting system preferences.

Though it was painful, we are glad we moved over to profiles from MCX when moving to Casper 9 and 10.9 this summer. It required a lot of testing in test environment and working with jamf developers b/c we had strange bugs with profiles being pushed down properly.

One of the nicest parts with profiles vs managed preferences is admins are prompted to disable management at login. In our environment, we are very limited in who is an admin on the computer, so works out great for us.

No more running specials scripts trying to wipe MCX settings.

I found a fix today by Samuel Keeley on AFP548 for the previously mentioned problem where you can hide a pane from the system preferences window and it will be available in the menu. He created a configuration profile using mcxToProfile (going to have to look into that myself) that does the same as the empty array that we couldn't create using the MCX interface in Casper 9.

http://www.afp548.com/2013/12/16/system-preferences-profiles-in-mavericks-plus-a-security-hole/

The link to the mobile config to download is here:- https://gist.github.com/keeleysam/c3a313db9b26bf414635#file-com-afp548-preferences-mobileconfig-plist

I have downloaded the "gist", removed plist from the filename and tested it. Works a treat.

@CasperSally
Can you please let us know what changes you've made to get a reliable configuration profiles setup (e.g from JAMF developers)?

@Kumarasinghe - The fixes put in for me are part of the 9.4 release regarding profiles coming down.

I was also having problems with reimaged computers with autorun data not getting config profiles, that problem was fixed by running a quickadd at reboot post image. It did present other issues (random machines not on wifi and other post image script tasks for whatever reason being skipped). I've asked JAMF for a solution on reimage where I can wipe policy history, without losing VNC logs & have config profiles reapplied. Like how 8.x worked with MCX and flush policy history flag. I've always had issues running packages at reboot on reimage.