BlacklistRegex and WhitelistRegex on Santa


Thanks once again to @bur on the Mac Admins Slack for the info I'm documenting here.

BlacklistRegex and WhitelistRegex

In a previous blog entry, I talked about using Santa to block apps by certificate (and I briefly mentioned blocking by binary).

You can also block by path using regular expressions. Binary takes precedence over certificate, which takes precedence over regex, so unfortunately you can't really block Apple apps (like Safari) using regex, because Santa automatically whitelists them by certificate—you can block them only by binary.

You may notice in the Santa documentation for configuration that both WhitelistRegex and BlacklistRegex are listed as string types instead of arrays of strings. That is absolutely true, so if you wanted to whitelist a whole bunch of app paths, you'd have to have a massively long string like this:

<string>^(?:/Applications/Adobe Acrobat DC)/.*|^(?:/Applications/LockDown*|^(?:/Applications/Microsoft*|^(?:/Applications/Microsoft*|^(?:/Applications/Microsoft*</string>

Same deal for a BlacklistRegex string.

Create a .mobileconfig profile for a certificate

If you want to create .mobileconfig profile from a certificate (for example, to import into Munki), you can use Apple Configurator 2 to do so.

If you have your certificate already in your keychain, launch up Keychain and find the certificate you want to make into a .mobileconfig profile.

Right-click the certificate and select Export NAMEOFTHECERTIFICATE (export it as a .cer).

Then launch up Apple Configuration

Select File and then New Profile

Select Certificates and then Configure.

Find and select the certificate you exported earlier.

Select File and then Save.

Pick a filename for your .mobileconfig, which you can deploy however you want (as I previously mentioned, you can import this into a Munki repo).

askForPassword and askForPasswordDelay in macOS 10.13 (High Sierra)

Update: Apparently 10.13.4 just breaks this completely (defaults write commands won't do anything any more). Thanks to tristan on the MacAdmins Slack for pointing this out.

In macOS 10.12 (Sierra) and earlier, you could go to System Preferences > Security & Privacy > General > Require password ________ after sleep or screen saver begins, and that would populate the askForPassword and askForPasswordDelay keys in ~/Library/Preferences/ for the user.

In macOS 10.13 (High Sierra), setting that preference in the GUI will not make it appear in the relevant .plist file. However, setting the preference with

defaults write askForPassword -bool TRUE
defaults write askForPasswordDelay -int somenumber
will make the change reflect in the GUI, and setting a .mobileconfig profile will also override what's set in the GUI.

Oddly enough, Apple's own documentation makes it sound as if those two keys exist only in 10.13 and later:

Importing custom .mobileconfig profiles into Mosyle MDM

Acknowledgements: Full credit to Tom Case on the MacAdmins Slack for this tip.

It's not immediately obvious that you can import custom .mobileconfig profiles into Mosyle MDM, but apparently you can if you go to Management > Certificates > (click on profile or add new one) > Select the file.

Those can be any .mobileconfig files—they do not have to be actual certificates.

Using Munki to manage Mac preferences with .mobileconfig profiles

You may sometimes script preferences using defaults write commands (don't edit the .plist files with a text editor directly). For example, you might change Munki client preferences using a command like:

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL ""
That's fine to do, but if you're actually managing Munki client preferences (not just for Munki-related settings but for other third-party or macOS settings), why not use Munki's built-in support for .mobileconfig profiles?

There are several methods to get or generate .mobileconfig profiles. I'm listing them below in order of preference from top recs to not-to-top recs.

Just finding existing profiles

Chances are if you want to manage a setting, someone else has also wanted at some point to manage that setting. mobileconfig is a great Google search for finding those.

Using mcxToProfile to generate a profile

You can create .mobileconfig profiles from existing .plist preference files you already have on a sample client machine. Just download Tim Sutton's mcxToProfile.

Then you can run something like

./mcxToProfile --plist /Library/Preferences/ManagedInstalls.plist --identifier MunkiPrefs
and then you can hand-edit the resulting .mobileconfig file to get out anything extraneous (for example, if all you want to set is the SoftwareRepoURL).

Generating Profiles with Apple Configurator

Apple Configurator is another option.

Just click File and select New Profile.

Once you've selected everything you want to configure, click Save.

The code it produces is (like mcxToProfile's) clean and easy to edit. And, yes, you usually want to edit down .mobileconfig profiles to be only the things you actually want to manage. Omit (i.e., delete) anything that you want your users to be able to manage themselves.

Generating profiles with Profile Manager

If you're using, there's a built-in way to generate profiles.

I usually create a test device group with no actual devices in it.

Then, under Settings, select Edit.

Find the type of setting you want to edit (there are some generic settings and then others specific to iOS or macOS). and click Configure and check off all the stuff you want configured.

Then once you've closed out of the editing settings space, click Save for the whole device group. This will allow you to download the settings.

Click the Download button and select macOS.

Now we're getting to why I seldom use Profile Manager. It adds in a bunch of binary gobbledygook and shoves all of the tags together so it's not easy to read. So, yeah, you can use it... but not fun.

Update: Apparently, you can tidy up the XML fairly easily if you want. Thanks to Ian Vonesh for the tip.

Whichever method you use, though, you can just import the .mobileconfig directly into Munki and push it out to your clients (be sure to test for unexpected behavior first before moving to production).

Can’t change Safari homepage in Sierra, even with no profiles managing homepage

So I came across something weird that's affected only my 10.12.4 clients (none of my 10.11.6 clients seem to be affected by this). Even though I have only one Safari profile enabled, which is set-once and doesn't manage the homepage, my 10.12.4 clients are unable to change the homepage in Safari manually. Whatever the homepage was is stuck like that. If you enter a new homepage in the Safari preferences, it will just not take and revert back to the old homepage once you hit Enter or click out of the address entry field.

The only workaround I've found for this is to delete all profiles (again, even though I don't have any profiles managing the Safari homepage):

sudo profiles -D
Are you sure you want to delete all configuration profiles? [y/n]:y
reboot the computer, and then reinstall (via Munki) all the previously installed profiles (yes, including the set-once profile for Safari that was installed before)... and then I'm able to change the homepage on the client manually. Very bizarre.

Also, after testing on a couple of other clients, there do seem to be situations in which the Safari profile was never set at all, and you still can't modify the homepage, even after deleting any other profiles and rebooting, and it's not account-specific either (freshly created account experiences it, too). It's a real head-scratcher.

Set ShoreTel Communicator server name with a profile

When you install ShoreTel Communicator's Mac app, it launches up and asks you for a server name, username, and password. The username and password will be specific to each user, but the server name will likely be the same for everyone, at least at a small- or medium-sized organization.

So if you have Mac clients and some way to distribute profiles to them, you can use a .mobileconfig profile to pre-fill-in the server information. I've posted an example on GitHub, so you can just modify that to fit your organization's needs.

Once that's deployed, when people install ShoreTel Communicator for the first time, the server address will be in already, and they'll just have to fill in their usernames and passwords.

Using a profile to re-enable Safari plugins

Recently (not sure the exact date), Apple started disabling certain Safari plugins by default. That's great for security, but it's not that great for usability, especially if users actually want to use those plugins.

If you want your users to enable plugins themselves manually, they can follow Apple's instructions at How to use Internet plug-ins in Safari for Mac.

If you'd like to deploy a .mobileconfig profile, though, I've posted a sample one on GitHub that enables Flash, Java, and Silverlight (ask first, not just on all the time).

Rod Christiansen has a more comprehensive sample up (more plugins).

In addition to the plugins being generally enabled or disabled (with 0 or 1 / false or true), there is also a first-visit policy to look at.

This is the default setting (blocking):

PlugInFirstVisitPolicy = PlugInPolicyBlock;

This is the setting in the profiles I linked to:

PlugInFirstVisitPolicy = PlugInPolicyAsk;

And this is if you want it on (not asking):

PlugInFirstVisitPolicy = PlugInPolicyAllowWithSecurityRestrictions;

Missing Updates tab in Apps part of iTunes

This is a bit of an esoteric problem and fix, but I didn't see this documented anywhere else.

I originally deployed this profile to disable the iTunes welcome screen and check for updates, because I didn't want to bother the user with prompts for updating the iTunes app.

missingupdatestab What I didn't realize is that also disables the Updates tab in the Apps part of iTunes. So I had to actually update the profile to keep the welcome screen off but bring the check for updates back.

updatestabback Once I did that, the Updates tab reappeared.

Forcing a Chrome homepage on Macs

Nick McSpadden has a great (and thorough) write-up on Deploying and Managing Google Chrome: The Rough Guide, and his recommendation is to have some initial Master Preferences that set a default, which can be overriden.

In some cases, though (for example, we have some machines that will be used for Hour of Code next week that will be set to as the homepage), you may want to force the homepage, in which case a profile may be the way to do it. There's a great template for a Chrome profile on JAMF Nation. Just paste that into a text file, edit it, and then save it with a .mobileconfig extension, and then you can distribute the .mobileconfig using Munki or ARD.