Preventing users from disabling FileVault 2

FileVaultI’ve seen a few online questions about how to prevent users from turning off FileVault 2.

The first line of defense, of course, is to not give admin rights to those users. As of Mavericks, however, there is an additional tool — you can use a configuration profile to prevent turning off FileVault (or at least disable the controls in the Security and Privacy preference pane — very clever users with admin rights might still able to turn it off using Disk Utility or the command-line diskutil tool).

Here is a configuration profile that disables the “Turn off FileVault” button in the FileVault tab of the Security and Privacy preference pane.

Since admin users can also remove configuration profiles, you should probably also lock this profile, requiring a password to remove it. That’s an exercise left for the reader, but here’s a starting point…

Add something like this to the PayloadContent array:

    <string>Configures Configuration Profile security</string>
    <string>Profile Security</string>
Preventing users from disabling FileVault 2

Mavericks and Multiple Displays

In OS X 10.9 Mavericks, Apple changed multiple display behavior in the most dramatic way since 1987. By default, each display now has its own menu bar. Windows can be dragged from one display to another, but they cannot span displays. And putting an application into full screen mode affects only one display. You can use other displays, either with multiple applications, or with other full-screen applications. Apple describes this behavior as “Displays have separate Spaces”, and indeed the effect is almost like having multiple Macs connected to a single keyboard and mouse. I find that I like the new behavior, as I tend to put different applications on different displays.

This is a very different way of working with multiple displays, and might cause some confusion and annoyance for your users and support staff if they aren’t aware of the change, or if it affects their workflows. If you or your users prefer the “old” pre-Mavericks behavior, it’s simple to revert. Open the Mission Control preference pane in System Preferences, and uncheck “Displays have separate Spaces”. A logout is required to effect the change.

If you think you need to manage this for your users, to revert to pre-Mavericks behavior, set “spans-displays” in the “” preferences domain to TRUE.

% defaults write spans-displays -bool TRUE

You could probably use MCX or a configuration profile to manage this as well.

Mavericks and Multiple Displays

VPN menu in Mavericks

If you use Apple’s built-in VPN and rely on the VPN menu bar item, you might have noticed that that in Mavericks the menu item no longer shows the connection time by default.

That can lead people to believe the VPN connection has not been established, or for users to forget they are connected. It’s quite easy to turn the feature back on: just select “Show Time Connected” from the VPN menu item.

If you want to manage this for your users, the preference is stored in the “” domain as a boolean value under “VPNShowTime”:

% defaults read
VPNShowTime = 1;

You could almost certainly set this with MCX or a configuration profile.

VPN menu in Mavericks

Disabling iCloud as default save location

icloud-logo has a new post on disabling iCloud as the default save location for new documents.

This feature affects apps that can save to iCloud, and only if the user has an iCloud account configured for the current login.

Still, you might want to turn this off by default for all users in your organization so they don’t accidentally store company documents on Apple’s servers. The post shows a command-line way to change this setting for a single user. How might you do this for all users?

One way would be to install a computer-level profile that installs the right settings. Here’s one.

If installed as root using the /usr/bin/profiles tool:

sudo profiles -I -F DontSaveNewDocumentsToiCloud.mobileconfig

This setting will be applied Once to all users as they login.

DontSaveNewDocumentsToiCloud.mobileconfig was created using Tim Sutton’s mcxToProfile tool.

Disabling iCloud as default save location

Flash Dance

In comments on my previous post here, TGB makes some interesting points:

While you’re not wrong that Flash Player deployment isn’t ideal, and it should be as easy as dragging and dropping a pkg, I don’t see how the repackaging route is any more of a waste of time than any other product. Adium, Mactracker, Firefox, Chrome and a whole bucket of other apps all require packaging to be deployed. Sure, they might auto-update, but you have to get an initial version out there, not to mention getting your preferred default settings out too.

Most, if not all the items mentioned (Adium, Mactracker, Firefox, and Chrome) are distributed as “drag-n-drop” disk images where the user is expected to drag the application to the /Applications folder. I’d argue that is an industry standard deployment method. The software deployment system I use (Munki) can install items like this without the need to package them. If your software deployment mechanism does not, perhaps you should be requesting that feature from your vendor, since this is a very common distribution format, and code-wise, requires  little effort to support. When a new version of Firefox or Chrome comes out, I just download the disk image and directly import it into Munki — no packaging needed.

Adobe Flayer Player cannot be distributed as a drag-n-drop application disk image — it’s not an application. So the “correct” distribution format for this software is the Apple package format.

Preferred default settings is a completely different issue. As long as vendors use Apple’s preference file format, this is solved with MCX or Lion/Mountain Lion profiles.

TGB also writes:

Not to mention, with any of these products, testing them (yes?) is more time and effort-intensive than any actual packaging. 3/4 of deployment and integration is non-technical work. A couple of minutes difference doesn’t really matter in the scheme of QA, UAT and change management process (or are others just not doing that?).

Flash is not needed by any business-critical application where I work, yet our users demand (or at least expect) it and Apple and Mozilla demand it stay up-to-date, or they will disable the plug-in. So for us at least, testing is quite minimal for Flash. If it installs and can display some Flash content, it’s good.

But yes, I do understand and sympathize with admins that must test each release of Flash with business-critical applications — and Adobe’s distribution format is not the key issue here; frequency of releases is. I’d argue that this is an impetus to reduce or eliminate your internal dependency on Flash.

Where I disagree with TGB: Adobe’s non-standard distribution adds more than a “couple of minutes” to preparing a new release of Flash for enterprise distribution. If we could be sure that Adobe will never change anything about their installer and updater, we could just figure out a process and repeat it for each new release. But Adobe can and has changed things, so for each release we must also test that our packaging/repackaging/custom deployment steps actually end up with the desired results. This is usually not a huge deal, but also cannot be ignored. But more importantly, theirs is a one-off solution. If we have to keep track of and test different deployment solutions for each vendor and product, we end up wasting a lot of time and effort, and making a lot of mistakes. Where would it end? Unique software deployment methods for each vendor? (Oh that there was only ONE unique deployment method for Adobe software!)

No, a line must be drawn. Here. No farther.

Flash Dance

Mountain Lion and Software Update

Mountain Lion introduces a small, yet significant change in how OS X clients communicate with Apple’s Software Update servers.

Mountain Lion clients by default now consult an HTTPS URL to check for updates on Apple’s servers.

This has the implication that you can no longer use DNS trickery with Mountain Lion clients to get them to access your internal SUS instead of Apple’s. Some organizations configured their internal DNS servers to resolve requests to to an internal server.

The appeal of this approach (DNS hijacking) was that you did not need to touch any client machine to get it to use your internal Softwar Update server; any client using your network would “automagically” use your internal Software Update server.

HTTPS connections do certificate verification of the host. Since your internal SUS can’t offer a certificate proving it is Apple’s server (because it’s not!) a Mountain Lion client will refuse to talk to it. (It’s also possible that your internal SUS is not accepting HTTPS connections anyway, but even if you were to turn that on, it would not help.)

HTTPS prevents exactly the sort of DNS impersonation that made this hack work in the first place. Apple has closed that door.

In order to use an internal Software Update server (either Apple’s or Reposado) with Mountain Lion clients, the clients must be explicitly pointed to your internal server via MCX or by setting the preference using:
defaults write /Library/Preferences/ CatalogURL <internalSUScatalogURL>

Mountain Lion and Software Update

Mountain Lion and MCX

In my last post, I asserted that Local MCX still works in Mountain Lion. And it does. But that doesn’t mean there aren’t issues to deal with.

There have been various reports of certain MCX settings not behaving correctly — for example, it appears that currently you can’t use MCX to manage Dock settings “Once” — only “Always” management works. (And that’s not useful for us — it doesn’t allow one to set certain Dock defaults and then leave the Dock alone for the user to modify as they’d like.)

There’s another challenge if you use Local MCX in an alternate local DirectoryService node, as described here:

In Mountain Lion, dscl refuses to write to non-default local nodes:

# sudo dscl /Local/MCX create /Computers/foo
create: Invalid Path
<dscl_cmd> DS Error: -14009 (eDSUnknownNodeName)

This makes manipulating things in a non-default local node much harder than it was in Leopard through Lion.

You can still copy files into /private/var/db/dslocal/nodes/MCX, and that can serve as a workaround for now. All of the packages I use to configure Local MCX do exactly that — they install plist files into /private/var/db/dslocal/nodes/MCX/computergroups. But there is one major exception.

I have one package that does the setup for Local MCX. It makes sure the /Local/MCX node is present, makes sure it is in the search path, and makes sure that an appropriate record exists in /Local/MCX/Computers to represent the current local machine. This requires writing to the /Local/MCX node to dynamically create the computer record. We can’t just install a file, because the contents of the data in the computer record are unique for each computer.

So there’s our problem: we can’t use dscl to create a computer record in the /Local/MCX node, yet we must dynamically create an object in that node.

There are two solutions, both which rely on the fact that all objects in Local DirectoryService nodes are actually just plist files.

The first:  We could use another plist creation tool to create the needed plist. We could use defaults or PlistBuddy, for example. But that would require us to take the time to figure out how to use one of those tools to create a file that is the same as if dscl created it.

The second: Use dscl to create the record in the /Local/Default node. Then just move the plist from /private/var/db/dslocal/nodes/Default/computers/foo.plist to /private/var/db/dslocal/nodes/MCX/computers/

The second approach is the one I decided to take, since it seemed easier.

Here is the script I currently use for initial Local MCX setup. If you are currently using Local MCX on Lion or earlier, I hope it is of some help if you want to continue to use Local MCX on Mountain Lion.

Mountain Lion and MCX