I've got a Mac OS X 10.6 Snow Leopard Server Open Directory Master with a user who's getting Mobility & Application managed preferences from a group (the only group they're a member of). The workstation is also running Mac OS X 10.6 Snow Leopard, when the user logs in and tries to run our primary application which they're explicitly allowed to run (via the group's preferences), it says "You don't have permission to use the application 'Blah'".
Now, the application is added to the group's list of always allowed applications, unsigned (so a minor difference in application version or file contents shouldn't disallow it). It even lives in a subdirectory of /Applications which is in the list of folders to allow applications.
I've run into this when logging this user into new workstations and the following usually works:
Log them out
Remove the following files from their mobile home folder on the workstation: /Library/Managed\ Preferences/, ~/.FileSync, ~/Library/Preferences/com.apple.finder.plist, and ~/Library/Preferences/com.apple.MCX.plist.
Remove the following files from their network home folder on the server: ~/.FileSync, ~/Library/Preferences/com.apple.finder.plist, and ~/Library/Preferences/com.apple.MCX.plist.
Log them back in on the workstation.
However, this no longer resolves the issue.
Their Home Sync preferences are set (on the group) to sync ~, but not the following files (manually, at login, and at logout... no background sync here):
~/.SymAVQSFile
~/NAVMac800QSFile
~/Library
~/.FileSync
~/.account
Their Preferences Sync preferences are set (also on the group) to sync ~/Library & ~/Documents/Microsoft User Data, but not the following files (also manually, at login, and at logout... no background sync):
~/.SymAVQSFile
~/.Trash
~/.Trashes
~/Documents/Microsoft User Data/Entourage Temp
~/Library/Application Support/SyncServices
~/Library/Application Support/MobileSync
~/Library/Caches
~/Library/Calendars/Calendar Cache
~/Library/Logs
~/Library/Mail/AvailableFeeds
~/Library/Mail/Envelope Index
~/Library/Preferences/Macromedia/
~/Library/Printers
~/Library/PubSub/Database
~/Library/PubSub/Downloads
~/Library/PubSub/Feeds
~/Library/Safari/Icons.db
~/Library/Safari/HistoryIndex.sk
~/Library/iTunes/iPhone Software Updates
IMAP-*
Exchange-*
EWS-*
Mac-*
~/Library/Preferences/ByHost
~/Library/Preferences/com.apple.dock.plist
~/Library/Preferences/com.apple.sitebarlists.plist
~/Library/Application Support/4D
~/Library/Preferences/com.apple.MCX.plist
~/.FileSync
~/.account
Even with ~/Library/Preferences/com.apple.MCX.plist prevented from syncing during a Preferences Sync, it still seems to show up in the network home on the server frequently.
Are there any other files other than ~/Library/Preferences/com.apple.MCX.plist that contain application Managed Preferences that might be causing this one app to be showing up as not allowed? Any ideas on how ~/Library/Preferences/com.apple.MCX.plist keeps getting sync'd back up the network home folder on the server?
Update: I thought I had found a workaround this morning, but it also seemed to be extremely temporary. Basically, loking at /Library/Managed\ Preferences/[shortname]/com.apple.applicationaccess.new.plist I discovered that it didn't have an entry for the application in question, but /Library/Managed\ Preferences/[shortname]/complete.plist did. Naturally, I deleted com.apple.applicationaccess.new.plist, logged in again, and it worked... on one workstation. It failed on others, and after logging out & back in a couple more times it started failing on all of them again, even after further deletions of com.apple.applicationaccess.new.plist. Oddly, com.apple.applicationaccess.new.plist & complete.plist do both contain an entry for the application in question now, but it still says it's not allowed.
Further Update: Okay, so I now have a reproducible workaround which seems to be required after every reboot of the workstation:
Log in as the user (you'll discover you cannot launch the application in question).
Fast User Switch to the local admin account on the workstation (we always have one on every machine).
From that local admin account, run sudo mcxrefresh -n 'shortname' (logging out and back in as the user in question will not work).
Fast User Switch back to the user (you'll still not be allowed to run the application).
Log the user out and back in (you'll now be able to run the application in question.)
Fast User Switch back to the local admin account, log it out, and log back in as the user in question.
If you do all that exactly as described it'll keep working through log out & log back in, but NOT through a reboot. If, after a reboot, you try something like logging in as the local admin account, running sudo mcxrefresh -n 'shortname', logging out, then logging in as the user in question, it will NOT work.
Yet Another Update We don't have any computer groups in our Open Directory, so it shouldn't be getting any conflicting settings from there. I ran sudo mcxquery -format xml -user shortname -group groupname before & after performing the aforementioned process to allow the application in question to be run and the results were identical (saved the result to files & diff'd... I'm not just guessing here).
One Step Forward, Half a Step Back: When the Mac OS X 10.6.5 Server update was released, we upgraded our Open Directory Master to it as the changes included the following managed preferences fixes which I hoped might address this issue:
Addresses an issue that could prevent managed preferences from being applied when a user logs in on a workstation that has been idle.
Fixes an issue that could prevent administrators from bypassing client management settings on a workstation.
This seemed to improve the situation slightly. The application in question now usually launches without error. If, and when it does launch with the "You don't have permission to use the application" error, logging the user out and back in seems to correct it.
That said, we've since had to add a couple of applications to the user's ~/Applications/ directory and those are still prevented from launching. The workstations are running Mac OS X 10.6.4, the OD Master (which the workstations are bound to) is running Mac OS 10.6.5 Server (although there are two OD Replicas still running 10.6.4 Server), and we're using Workgroup Manager 10.6.3 (which is included with the Server Admin Tools 10.6.5 upgrade) to add the applications (unsigned, as always). This time, I've caught the following in /var/log/system.log when attempting to launch one of the allowed applications from ~/Applications:
Dec 22 17:36:24 hostname parentalcontrolsd[43221]: -[ActivityTracker checkApp:csFlags:] [954:username] -- *** Incoming app appears to be masquerading as white listed app and failed signature validation: /Users/username/Applications/FileMaker Pro 5.5/FileMaker Pro.app/Contents/MacOS/FileMaker Pro. Note: This may be a valid app of a different version than what was whitelisted (on a different volume?)
Dec 22 17:36:24 hostname [0x0-0xa42a42].com.filemaker.filemakerpro[43304]: launch of /Users/username/Applications/FileMaker Pro 5.5/FileMaker Pro.app/Contents/MacOS/FileMaker Pro was blocked
Dec 22 17:36:24 hostname com.apple.launchd.peruser.1340[6375] ([0x0-0xa42a42].com.filemaker.filemakerpro[43304]): Exited with exit code: 255
Dec 22 17:36:24 hostname parentalcontrolsd[43221]: -[ActivityTracker(Private) _removeAppFromWhiteList:] [1362:username] -- *** Couldn't find local user record
Running sudo mcxquery -format xml -user username -group groupname includes the following entry for FileMaker Pro 5.5 (and appears to include a full integration of the user's application whitelist & group's application whitelist):
<dict>
<key>bundleID</key>
<string>com.filemaker.filemakerpro</string>
<key>displayName</key>
<string>FileMaker Pro</string>
</dict>
Note the lack of <key>appID</key><data> ... </data> which seems to specify a signed application. While whitelisted directories also appear to be correctly listed in the results, they too do not actually allow the applications to be run either.
What is going on here?! Where else should I be looking?
