SBAC Secure Browser 7.0 and Disabling Spaces

[johnnasset]

There are a few threads on here regarding this (some started by me) but I'm having a heck of a time consistently disabling Spaces on client machines for Smarter Balanced testing in a few weeks. To disable manually, you go to System Preferences-Keyboard-Shortcuts and uncheck these boxes. This screenshot is from my machine running 10.10.2 but the same boxes exist in other OS versions.

Unchecking these boxes modifies the ~/Library/Preferences/com.apple.symbolichotkeys.plist.

Last year with version 6.3 of the browser I created a custom configuration profile with this plist as the payload set to the computer level. Worked great.

Now with version 7 of the browser, not so much. Even after deploying a config profile, checking that the boxes are unchecked, the SBAC browser still thinks Spaces is enabled. If I manually check and uncheck the boxes, the browser launches fine. So there is something that is finalizing the update to that plist that is only getting done by manually making the change. Next, I tried building the dmg in Composer and distributing with FUT/FEU enabled. Same as the profile, I could verify the boxes were unchecked but not until I manually touched them in System Preferences would the changes take effect. I also tried a login script I found here but got the same end result.

Working with JAMF Support, I found that if I used the dmg built from Composer, FEU/FUT via Casper Remote, with a user logged in to the machine and then did a shutdown (not reboot), the changes will take effect. Great, except that I've found that even with FEU/FUT, this has to be done with each user on the machine while logged in. Via policy in the JSS, it does not work via login/logout, only every15 or custom trigger while the user is logged in.

There is obviously some final commit for the plist that takes place via manually unchecking the boxes or with the shutdown but I can't figure out what that is. Some suggested workflows:

Use Self Service to install the dmg with FEU/FUT. Not crazy about this one as we would be relying on students to run the SS policy, ranging in ages from 8 to 18. I can't guarantee this would be done across the district and it needs to be for high stakes testing

Make sure machines are logged into a specific account designated and trigger policy via every15 or custom trigger and instruct buildings to only test with this account as I can't ensure the browser would work properly with the other accounts. This is what way I'm leaning. Our mobiles get shutdown daily and I can set an energy saver profile to handle the desktops. This is still not as automated/fool-proof as I'd like.

Other details:

JSS version 9.65
Account are AD accounts
OS versions primarily 10.7-10.9 (majority are 10.7 and 10.8)

I'm still working with JAMF Support on this but would love any feedback/ideas that anybody has which could make a nearly seamless workflow.

Thanks
John

[cbrewer]

Seeing more or less the same thing in my school district. I have a config profile that appears to disable all the keyboard shortcuts you mentioned. It seems to work as it should, except that the secure browser from AIR doesn't recognize the settings.

Like you, this same method worked for us last year using 10.7/10.8 and browser version 6.x.

I have a case open with AIR, but have heard very little back. The case number is 258681.

[johnnasset]

Whew, thought I was going crazy. I'm also attempting user level config profiles scoped to single LDAP users but not working consistently. I can confirm (usually after a shutdown or two) the boxes are unchecked by the config profile but the browser still won't launch.

BTW, our browser comes from Measured Progress but I'm guessing they share the bulk of the code with AIR.

[galionschools]

While I don't manage OSX devices with Casper I've found with AIR that even if Spaces was disabled it would still give me the dread Access Denied message. What worked for me was a launch agent that deleted com.apple.spaces.plist and com.apple.symbolichotkeys.plist from the users library. Not sure if both plists need to be trashed but it worked for me every single time either via a script or just by manually trashing them.

[jacob_salmela]

We had similar issues with the MN Secure Browser and had to disable both spaces as well as the dashboard (considered a space). Below are the values from the config profiles we made (I don't have the original .plists):

com.apple.symbolichotkeys

{AppleSymbolicHotKeys={118={enabled=false, value={parameters=[65535, 18, 262144], type=standard}}, 119={enabled=false, value={parameters=[65535, 19, 262144], type=standard}}}}

com.apple.dashboard

{mcx-disabled=true}

You could probably make a script to deploy the settings at login if the profiles don't work.

[johnnasset]

Interesting @galionschools . If you delete these plists from the user library on login, wouldn't the default revert back to spaces being enabled?

[galionschools]

I thought that as well, but it might be due to preference caching i.e. cfprefsd that the values don't revert back to defaults.

I did the same steps that Jacob outlined above and while the files and the gui reflected the changes the secure browser still insisted Spaces was enabled.

[cbrewer]

Thanks for the tip @galionschools

I've found that using my config profile for disabling the keyboard shortcuts along with using a launchagent to delete com.apple.symbolichotkeys.plist after login gets the job done.

Here's the script I'm using to create the launchagent if anyone is interested:

#!/bin/bash

#Check for existing launch agent and delete if found
if [ -f /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist ]; then
    echo "LaunchAgent to delete com.apple.symbolichotkeys.plist already exists. Removing..."
    rm /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist
fi

#Write out a LaunchAgent to delete com.apple.symbolichotkeys.plist on login
defaults write /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist Label AIR.DeleteSymbolichotkeys
defaults write /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist ProgramArguments -array
defaults write /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist RunAtLoad -bool YES
/usr/libexec/PlistBuddy -c "Add ProgramArguments: string rm" /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist
/usr/libexec/PlistBuddy -c "Add ProgramArguments: string /Users/$3/Library/Preferences/com.apple.symbolichotkeys.plist" /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist
chown -R $3 /Users/$3/Library/LaunchAgents
chmod 644 /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist
echo "Created LaunchAgent to delete com.apple.symbolichotkeys.plist on login"

[johnnasset]

@cbrewer

Wow, works great!! I set the config profile to user level and the script to run once per user at login. This was on a 10.9 machine. Off the top of your head do you see this working any differently for 10.7 and 10.8 machines? I'm sure the launchagent is fine but I seem to think that the com.apple.symbolichotkeys.plist is different for 10.9 vs 10.7 and 10.8.

Really appreciate yours and everybody's help on this. I'll buy you a beer or three if we ever cross paths.

[cbrewer]

I've only tested on 10.9/10.10 so far. The only problem I've found is that sometimes the launchagent runs before com.apple.symbolichotkeys.plist exists. I'm working on a new version that writes a script to the tmp folder and then calls the script from the launchagent. The script includes a sleep command so that it'll wait 5 seconds before running.

[cbrewer · Accepted solution]

Here's my updated version. As I said, this one writes a script. The script also deletes both the launchagent and the script itself. This way there's nothing left behind after com.apple.symbolichotkeys.plist is deleted.

#!/bin/bash

#Check for del_symbolichotkeys.sh and delete if found
if [ -f /private/var/tmp/del_symbolichotkeys.sh ]; then
    echo "/private/var/tmp/del_symbolichotkeys.sh already exists. Removing..."
    rm /private/var/tmp/del_symbolichotkeys.sh
fi

#Check for existing launch agent and delete if found
if [ -f /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist ]; then
    echo "LaunchAgent to delete com.apple.symbolichotkeys.plist already exists. Removing..."
    rm /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist
fi

#Write /private/var/tmp/del_symbolichotkeys.sh
echo '#!/bin/bash' >> /private/var/tmp/del_symbolichotkeys.sh
echo "" >> /private/var/tmp/del_symbolichotkeys.sh
echo "sleep 5" >> /private/var/tmp/del_symbolichotkeys.sh
echo "rm /Users/$3/Library/Preferences/com.apple.symbolichotkeys.plist" >> /private/var/tmp/del_symbolichotkeys.sh
echo "rm /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist" >> /private/var/tmp/del_symbolichotkeys.sh
echo "rm /private/var/tmp/del_symbolichotkeys.sh" >> /private/var/tmp/del_symbolichotkeys.sh
chown $3 /private/var/tmp/del_symbolichotkeys.sh
chmod 755 /private/var/tmp/del_symbolichotkeys.sh

#Write out a LaunchAgent to delete com.apple.symbolichotkeys.plist on login
defaults write /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist Label AIR.DeleteSymbolichotkeys
defaults write /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist ProgramArguments -array
defaults write /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist RunAtLoad -bool YES
/usr/libexec/PlistBuddy -c "Add ProgramArguments: string /private/var/tmp/del_symbolichotkeys.sh" /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist
chown -R $3 /Users/$3/Library/LaunchAgents
chmod 644 /Users/$3/Library/LaunchAgents/AIR.DeleteSymbolichotkeys.plist
echo "Created LaunchAgent to delete com.apple.symbolichotkeys.plist on login"

[galionschools]

This is slightly OT from the topic but has anyone noticed that after launching the Secure Browser application it's changing the location of screenshots made by a user? We're 1:1 MacBook Air's and I had a student come down earlier saying that when she used the screenshot keyboard shortcut (CMD+Shift+3/4) it wasn't saving any screenshots she was taking. Sure enough after doing some digging the com.apple.screencapture preference file in ~/Library/Prefences had it's location value changed from ~/Desktop to ~/Library/Application Support/OHSecureBrowser7.2/Profiles.

Nothing earth shattering, but my Google FU is weak today and I haven't seen any documents from SBAC or AIR stating this will occur.

[jared_young]

what is the best practice on deploying SBAC? There is not a pkg installer (I think the app is a .app installer) and when I packaged it myself it dropped it in the root folder and not the applications folder.

[Durkin]

So I'm using the script above that cbrewer provided and it does not seem to take effect until after I log into the JSS and pull up the logs and click "Flush All".

I have two Policies. One to install the secure browser and another one to disable Spaces. After both are completed I can go into the jss and open up the log for the policy I have to disable spaces and either click flush next to the computer or flush all. Then log out and back in on my test mac and the secure browser launches without a message about disabling spaces.

Any ideas?

In case it is relevant the Mac is running 10.10.3 and I am using the OH Secure Browser. My JSS server is 9.92.1466020067

[ksanborn]

This may be an ignorant question, so I apologize in advance, but how do you disable keyboard shortcuts using a config profile?

[rwhitehair]

Thank you cbrewer! You are a life saver!

[eob455]

This worked great but any suggestions on re-enabling Mission Control? We want to disable it for testing but it would be nice to give it back to those who use it.

[csjoberg]

This should be included.
https://www.jamf.com/jamf-nation/discussions/9503/disable-spaces-mission-control-for-network-users