Safari Sharepoint Plugin -- trusting sites

[flyboy]

My organization has just changed intranet platforms and is now heavily leveraging SharePoint and Yammer. Does anyone have any ideas for how to pre-populate sites into the trust settings for the Safari SharePoint Plugin? Yes, I know there are security implications with doing this, but right now we're looking at can we do this and then will circle back around to whether or not we should. Effectively I'm trying to find a way to prevent users from getting the "Do you want to trust the website “intranet.mydomain.org” to use the “SharePoint Browser Plug-in” plug-in" popup.

Thanks!

[JPDyson · Accepted solution]

Yes. It's not as easy as it used to be, but I'm almost over complaining about JAMF needlessly deprecating MCX. Almost...

Best granular way to do it now-a-days is a custom config profile payload. Start by creating a fresh profile and trusting the site the way you normally would - install the plugin, visit the site, and trust it. Then you can go into Safari's Preferences > Security > Plug-in Settings and adjust the settings as needed. Once this is set, grab a copy of ~/Library/Preferences/com.apple.Safari.plist from that Mac and convert it to XML:

plutil -convert xml1 /path/to/copy.plist

At this point you can open up the XML-formatted plist file and edit out all of the various keys other than ManagedPluginPolicies (note that this would capture any other plug-in settings you've set, which is why I recommended a fresh profile), and save the resulting "plist snippet". In your JSS, create a user-level Config Profile, and go to Custom Settings. Set your Preference Domain to com.apple.Safari, and upload the plist snippet you made.

Keep track of your snippets; if you needed to make a simple edit, it's easier to start from the snippet and just update a version number or URL. We manage several plugins in way - it allows us to apply the current gatekeeper settings via SUS and, on a site-by-site basis, allow outdated plugins to run (or run in un-sandboxed mode, which is un-safe mode).

HTH.

[JPDyson · Accepted solution]

Yes. It's not as easy as it used to be, but I'm almost over complaining about JAMF needlessly deprecating MCX. Almost...

Best granular way to do it now-a-days is a custom config profile payload. Start by creating a fresh profile and trusting the site the way you normally would - install the plugin, visit the site, and trust it. Then you can go into Safari's Preferences > Security > Plug-in Settings and adjust the settings as needed. Once this is set, grab a copy of ~/Library/Preferences/com.apple.Safari.plist from that Mac and convert it to XML:

plutil -convert xml1 /path/to/copy.plist

At this point you can open up the XML-formatted plist file and edit out all of the various keys other than ManagedPluginPolicies (note that this would capture any other plug-in settings you've set, which is why I recommended a fresh profile), and save the resulting "plist snippet". In your JSS, create a user-level Config Profile, and go to Custom Settings. Set your Preference Domain to com.apple.Safari, and upload the plist snippet you made.

Keep track of your snippets; if you needed to make a simple edit, it's easier to start from the snippet and just update a version number or URL. We manage several plugins in way - it allows us to apply the current gatekeeper settings via SUS and, on a site-by-site basis, allow outdated plugins to run (or run in un-sandboxed mode, which is un-safe mode).

HTH.

[bentoms · Accepted solution]

@Berrier Other than what @JPDyson said, there is also this Apple KB

[flyboy]

Thanks @bentoms and @JPDyson . I figured the way you guys mention doing it was the way to go. We are actually considering not deploying the plugin at all since it's an Office 2011 plugin and not included in Office 2016.