Tag Archives: mdm

Mac OS X Programming Unix

Mac DevOps Conference

There’s another new conference in town! Well, not my town, but Vancouver. MacDev Ops is a hot topic. One that will only increase in the coming years. Thanks to Mat X and Brian Warsing for bringing about a brilliant conference.

Screen Shot 2015-03-23 at 10.43.50 PM

The conference will be held on June 19, 2015 and is an easy $99 if you sign up soon. Also, submit a talk if DevOps is your thing. They’re looking to bring the following topics to the table:

  • Puppet, Chef and other automation from Desktop to Cloud and back
  • Software deployment with Munki and AutoPkg: the app ecosystem surrounding it
  • Cool tools: demo of awesome Mac Admin projects from GitHub
  • DevOps: How to adopt Automation and Best practices in IT operations
  • Dev skills: workshops on Ruby, Git, Python, Javascript for Mac Admins
  • MDM: Profiles and Mac configuration management in the cloud

This is sure to be a good one. Check it out here!

Bushel Product Management

Interview with Chuck Joiner of MacVoices re: Bushel

My third podcast in the last couple of months, this time with Chuck Joiner again, of MacVoices. And we talked a pretty good bit about Bushel and Mobile Device Management. Thanks to Chuck formatting this whole thing pretty awesome and helping bring my explanations to a point where they actually make sense!


Bushel iPhone Mac OS X Mac OS X Server Mac Security Mass Deployment

Enroll Devices Into Bushel

To manage a device from Bushel, it must first be added to your Bushel. The technical whiz-bang name for that process is Enrollment. We currently provide 3 ways to enroll devices into your Bushel. All three are available on the Enrollment page when you’re logged into Bushel.

Screen Shot 2014-09-11 at 11.41.46 AM

The first and best way to enroll devices into your Bushel is an Apple program called the Device Enrollment Program, or DEP for short. DEP is a way of tying devices to your Bushel so that they cannot be removed from the device, even if the device is wiped. Other than through DEP,  all enrollment into your Bushel is optional on the devices and so devices can be unenrolled at will. DEP requires an actual DEP account with Apple, which you can sign up for at https://deploy.apple.com/qforms/open/register/index/avs.

The second way to enroll devices into your Bushel is via Open Enrollment. When you Configure Open Enrollment you create a link that allows your users to enroll without logging into the portal. Simply open Open Enrollment from the Enrollment page and click Enable. Once enabled, you’ll see the URL to enroll devices.

Screen Shot 2014-09-11 at 11.43.44 AM

The third way to enroll devices is manually. Simply log into your Bushel, click on Enrollment and then click on the Enroll button for Enroll This Device. When prompted for “Who will this device belong to?” enter the username (e.g. the user’s name in front of their email address most likely or the username for your email system if it’s something different than that). Also provide the email address itself in the Email Address field and then click Enroll This Device. Now, if you want to enroll the device you’re using, simply complete the screen prompts for the profile installation and you’ll be good to go. Or, you can save the mobileconfig file that’s downloaded and send it to others in order to allow them to install it as well. Simply cancel the installation process (most easily done from a Mac) and distribute the Enroll.mobileconfig file as needed. You can also put a user’s name in front of the file name, so you know which will enroll each user. If you need to enroll 3 or 4 people in other countries or cities, this might be the best option!

Screen Shot 2014-09-11 at 11.48.46 AM

OK, so we basically gave 4 ways to enroll. But that’s because we’re trying to make it as easy as possible to enroll devices into your Bushel.


Mass Enroll iOS Devices Into Bushel

When you add a bunch of devices to an MDM, we call it mass enrolling. Adding iPads, iPhones and iPods to your Bushel can be done through Apple Configurator. Apple Configurator automates the enrollment process, but when working with Bushel the enrollment profile has the username and email address, if you’re using email. This means that you would only want to use a mass enrollment option with Bushel if you are not using email, if all of your users will have the same generic email address or if your users will enter their own email information.

As mentioned, an enrollment profile automatically adds your devices to your Bushel. To obtain the enrollment profile:

  • Log into your Bushel.
  • Click on Devices.
  • Click on Enroll for Enroll This Device.
  • Click on Enroll This Device.Bushel Enroll iPhone, iPad or iPod touch.
  • Once the profile is downloaded, it will automatically attempt to enroll the computer you are downloading it from in the Profiles System Preferences pane.

Screen Shot 2014-10-17 at 11.05.41 AM

  • Click on Cancel.
  • Click on the downloads link in Safari.
  • Click on your Downloads folder.

Screen Shot 2014-10-17 at 11.08.55 AM

  • You have now downloaded the .mobileconfig file that will enroll devices into your Bushel

Add the Profile To Apple Configurator:

To deploy the profile through Apple Configurator:

  • Open Apple Configurator.
  • Click on Supervise in the row of icons along the top of the screen.
  • Drag the profile (by default currently called MDM-iOS5.mobileconfig) from the Finder into the list of Profiles.Screen Shot 2014-10-17 at 11.21.09 AM
  • The profile then appears in Apple Configurator (in this example, called jasper Bushel Profile but would be called your organization’s name followed by Bushel Profile for you).

Deploy The Bushel Enrollment Profile Through Apple Configurator

Once the profile is installed in Apple Configurator, let’s deploy it. In this example, don’t configure any other options. To deploy:

  • Open Apple Configurator.
  • Click on Prepare.
  • Click on the Install Profiles button in the Profiles section of the Settings pane.Screen Shot 2014-10-17 at 11.24.37 AM
  • Click Next.Screen Shot 2014-10-17 at 11.25.02 AM
  • Check the box for the enrollment profile.Screen Shot 2014-10-17 at 11.25.48 AM
  • Click Next.
  • Follow the prompts on the screen of the device to install the profile.

If you then wish to remove the device from your Bushel (aka unenroll), simply remove the enrollment profile by opening the Settings app, scrolling down to the Profiles section and tapping on the Remove button for the profile you just installed.

iPhone Mac OS X Mac OS X Server Mac Security

Casper 9.62 Is Out!

Casper 9.62 is now out! And holy buckets, look at all the stuff that got fixed in this release:



PS – There’s also some api improvement goodness!

Bushel iPhone Mass Deployment

How To View What Payloads Do To Devices

You can see exactly what Bushel, and other MDM platforms do to your OS X devices using the System Information utility. As with all Mobile Device Management (MDM) solutions that interface with OS X, you can use the About this Mac menu item under the Apple menu at the top of the screen to bring up the System Information utility. When you open this tool, you will see a lot of information that can be derived about your devices. Scroll down the list and click on Profiles. Here, you will see all of the Device and User profiles that have been installed on your computer, the payloads within each profile and the keys within each payload.

Screen Shot 2014-12-01 at 12.00.11 PM

Inside each profile there are a few pieces of information that define how the profile operates on the computer. Click on one to see the specific details for each Payload. Payloads are a collection of settings that a policy is changing. For example, in the above  screenshot, allowSimple is a key inside the com.apple.mobiledevice.passwordpolicy payload. This setting, when set to 1 allows simple passcode to be used on the device. When used in conjunction with the forcePIN key (as seen, in the same payload), you must use a passcode, which can be simple (e.g. 4 numeric characters).

Using these settings, you can change a setting in Bushel and then see the exact keys in each of our deployed payloads that changed when you change each setting. Great for troubleshooting issues!

Bushel iPhone Mac OS X Mac OS X Server Mac Security Mass Deployment

Bushel Goes Into Invitation Mode!

Yesterday the Bushel team finished some new code. This code allows you to refer your friends to Bushel! This skips the codes that everyone was waiting for and lets people create accounts immediately!

Screen Shot 2014-11-24 at 10.07.02 PM

From your home screen, click on Invite Friends. Or from the Account screen, scroll down to the section that says “Invite friends to join Bushel”. From here, you can post codes to Facebook, Tweet codes, post codes to LinkedIn and even email them.

We’re not going into general availability just yet. But we’re definitely making it easier long-term to sign up and use Bushel! We hope you love it as much as we do!

Since we’re still architecting how these final screens look, the final features and stress testing the servers, also if you’re testing the system please feel free to fill out our feedback form so we know what you think of what we’re doing and where we’re going!

Or if you’re still waiting for a code, use this link to skip that process https://signup.bushel.com?r=fd0fcf9e6d914a739d29c90421c0fb45.


Bushel Interview with Tech.mn

Slowly but surely information about what I left 318 to do has been leaking out. And I wouldn’t say leaking. More like being broadcast to the world. I’ve worked on a few little things here and there at JAMF Software since my arrival. But my core duty is to shepherd the development and strategy behind a new Mobile Device Management tool called Bushel. A little more about Bushel is available here, and I’ll likely post more about it here when the time is right:


And to access the Bushel site:


And some of the writing that are now finding their way onto the Bushel blog:



Mac OS X Mac OS X Server Mac Security Mass Deployment

Encrypt OS X Yosemite Server

Encrypting a volume in OS X Yosemite couldn’t be easier. In this article, we will look at three ways to encrypt OS X Yosemite volumes. The reason there are three ways is that booted volumes and non-booted volumes have different methods for enabling encryption.

Encrypting Attached Storage

For non-boot volumes, just control-click or right-click on them and then click on Encrypt “VOLUMENAME” where the name of the volume is in quotes.


When prompted, provide an encryption password for the volume, verify that password and if you so choose, provide a hint.


Once the encryption process has begun, the entry previously clicked on says Encrypting “VOLUMENAME” where the name of the volume is in quotes.

Before you can encrypt a volume from the command line you must first convert it to CoreStorage if it isn’t already. As volumes on external disks aren’t likely to be CoreStorage, let’s check using diskutil along with corestorage and then list:

diskutil corestorage list

Assuming your volume was already formatted with a non-corestorage format and isn’t listed, locate the volume and document the disk identifier (in this case disk2s3). Then, run diskutil corestorage along with the convert verb and the disk, as follows (no need to run this command if it’s already listed):

sudo diskutil corestorage convert disk2s3

The output should look similar to the following:

Started CoreStorage operation on disk2s3 Reco
Resizing disk to fit Core Storage headers
Creating Core Storage Logical Volume Group
Attempting to unmount disk2s3
Switching disk2s3 to Core Storage
Waiting for Logical Volume to appear
Mounting Logical Volume
Core Storage LVG UUID: 19D34AAA-498A-44FC-99A5-3E719D3DB6FB
Core Storage PV UUID: 2639E13A-250D-4510-889A-3EEB3B7F065C
Core Storage LV UUID: 4CC5881F-88B3-42DD-B540-24AA63952E31
Core Storage disk: disk4
Finished CoreStorage operation on disk2s3 Reco

Once converted, the LV UUID (LV is short for Logical Volume) can be used to encrypt the logical volume using a password of crowbar to unlock it:

sudo diskutil corestorage encryptvolume 4CC5881F-88B3-42DD-B540-24AA63952E31 -passphrase crowbar

The output is similar to the following:

Started CoreStorage operation on disk4 Reco
Scheduling encryption of Core Storage Logical Volume
Core Storage LV UUID: 4CC5881F-88B3-42DD-B540-24AA63952E31
Finished CoreStorage operation on disk4 Reco

According to the size, this process can take some time. Monitor the progress using the corestorage list option:

diskutil corestorage list

In all of these commands, replace core storage w/ cs for less typing. I’ll use the shortened version as I go. I know that we rarely change passwords, but sometimes it needs to happen. If it needs to happen on a core storage encrypted volume, this can be done from the command line or a script. To do so, use diskutil cs with the changevolumepassphrase option. We’ll use -oldpassphrase to provide the old password and -newpassphrase to provide the new passphrase.

diskutil cs changeVolumePassphrase FC6D57CD-15FC-4A9A-B9D7-F7CF26312E00 -oldpassphrase crowbar -newpassphrase hedeservedit

I continue to get prompted when I send the -newpassphrase, so I’ve taken to using stdin , using -stdinpassphrase. Once encrypted there will occasionally come a time for decrypting, or removing the encryption, from a volume. It’s worth noting that neither encrypting or decrypting requires erasing. To decrypt, use the decryptVolume verb, again with the -passphrase option:

diskutil cs decryptvolume 4CC5881F-88B3-42DD-B540-24AA63952E31 -passphrase crowbar

FileVault 2: Encrypting Boot Volumes

Boot volumes are configured a bit differently. This is namely because the boot volume requires FileVault 2, which unifies usernames and passwords with the encryption so that users enter one username and password rather than unlocking drives. To configure FileVault 2, open the Security & Privacy System Preference pane and then click on the FileVault tab. Click on the lock to make changes and then provide the password for an administrative account of the system. Then, click on “Turn On FileVault…”


If there are multiple users, enable each user who should be able to boot the system. On a server, this only needs to be administrators as you likely don’t have the password for end users.


When prompted with the Recovery Key, document it and then click on Continue. Choose whether to restore the recovery key with Apple. If you will be storing the key with Apple then provide the AppleID. Otherwise, simply click the bullet for “Do not store the recovery key with Apple” and then click on the Continue button.

When prompted, click on Restart to reboot and be prompted for the first account that can unlock the FileVaulted system.


Once encrypted, the FileVault tab in the Security & Privacy System Preference pane shows the encryption status, or percent during encryption.

Use the Enable Users… button to enable additional accounts to unlock the volume (note: by default accounts cannot login until their account has been added here).

That’s it. Managing FileVault 2 using the System Preferences is about as easy as it can get. But for those who require mass management, Apple has provided a tool called fdesetup for that as well.

Using fdesetup with FileVault 2

FileVault 2 now comes with a nifty configuration utility called fdesetup. To use fdesetup to encrypt the boot volume, first check FileVault’s status by entering the fdesetup command along with the –status option (wait, no — required any more!):

fdesetup status

As with most other commands, read the help page before starting to use just in case there are any changes to it between the writing of this article and when you kick off your automated encryption. Done using the help verb:

fdesetup help

After confirming FileVault is off, enable FileVault with the enable option, as follows:

sudo fdesetup enable

Unless additional parameters are specified, an interactive session prompts for the primary user’s short name and password. Once enabled, a Recovery key is returned by the fdesetup command. You can also cancel this by just hitting Control-C so we can look at more complicated iterations of the command. It should be recorded or otherwise stored, something easily done by mounting in a script (e.g. a write-only share in a script for key escrowing). If more complicated measures are needed, of course check out Cauliflower Vest at code.google.com. The fdesetup command is now at version 2.36:

fdesetup version

Now, if you run fdesetup and you’ve deployed a master keychain then you’re going to have a little more work to do; namely point the -keychain command at the actual keychain. For example:

sudo fdesetup enable -keychain /Library//Keychains/FileVaultMaster.keychain

To define a certificate:

sudo fdesetup enable -certificate /temp/filename.cer

Adding additional users other than the one who enabled fdesetup is a bit different than the first:

sudo fdesetup add -usertoadd robin

To remove users, just remove them with a remove verb followed by the -user option and the username:

sudo fdesetup remove -user robin

The remove and add options also offer using the -uuid rather than the username. Let’s look at Robin’s uid :

dscl . read /Users/robin GeneratedUID | cut -c 15-50

Yes, I used cut. If you have a problem with that then take your judgmental fuc… Nevermind. Take that GUID and plug it in as the uuid using the -uuid option. For example, to do so with the remove verb:

sudo fdesetup remove -uuid 31E609D5-39CF-4A42-9F24-CFA2B36F5532

Or for good measure, we can basically replicate -user w/ -uuid for a nice stupid human trick:

sudo fdesetup remove -uuid `dscl . read /Users/robin GeneratedUID | cut -c 15-50`

All of the fdesetup commands can be run interactively or using options to define the variables otherwise provided in the interactive prompt. These are defined well in the man page. Finally, let’s look at -defer. Using -defer, you can run the fdesetup tool at the next login, write the key to a plist and then grab it with a script of some sort later.

sudo fdesetup enable -defer /temp/fdesetupescrow.plist

Or define users concurrently (continuing to use the robin test user):

sudo fdesetup enable -user robin -defer /temp/fdesetupescrow.plist

FileVault accounts can also use accounts from Directory Services automatically. These need to synchronize with the Directory Service routinely as data is cached. To do so:

sudo fdesetup sync

This is really just scratching the surface of what you can do with fdesetup. The definitive source for which is the man page as well as a nicely done article by Rich Trouton.

Encrypting Time Machine Backups

The last full disk encryption to discuss is Time Machine. To encrypt Time Machine backups, use Time Machine’s System Preference pane. The reason for this being that doing so automatically maintains mounting information in the Operating System, rather than potentially having an encrypted drive’s password get lost or not entered and therefore not have backups run.

To enable disk encryption for Time Machine destinations, open the Time Machine System Preference pane and click on Select Backup Disk… From the backup disk selection screen, choose your backup target and then check the box for “Encrypt backups”. Then, click on Use Disk.

At the overlay screen, provide a backup password twice and if you would like, a hint as to what that password is. When you are satisfied with your passwords, click on the Encrypt Disk button.

Now, there are a couple of things to know here. 1. Don’t forget that password. 2. If you use an institutional FileVault Key then still don’t forget that password as it will not work. 3. Don’t forget that password…

Scripty CLI Stuff

We’ve always been able to enable FileVault using scripts thanks to fdesetup but now Apple’s taken some of the difficulty out of configuring recovery keys. This comes in the form of the changerecovery, haspersonalrecoverykey, hasinstitutionalkey, usingrecoverykey and validate recovery options. These options all revolve around one idea: make it easier to deploy centrally managed keys that can be used to unlock encrypted volumes in the event that such an action is required. There’s also a -recoverykey option, which indicates the number of the key if a recovery key is being used.

To use the fdesetup command to check whether a computer has a personal recovery key use the haspersonalrecoverykey verb, as follows:

fdesetup haspersonalrecoverykey

The output will be a simple true or false exit. To use the fdesetup command to check whether a computer has an institutional recovery key, use the hasinstitutionalrecoverykey verb, as follows:

fdesetup hasinstitutionalrecoverykey

To enable a specific personal recovery key, provide it using the changerecovery verb, as follows:

fdesetup changerecovery -personal

This is an interactive command, so when prompted, provide the appropriate personal key. The removerecovery verb can also be used to remove keys. And my favorite, validaterecovery is used to check on whether or not a recovery key will work to unlock a host; which can be tied into something like an extension attribute in Casper in order to store a key and then validate the key every week or 4. This helps to make sure that systems are manageable if something happens.

The enable verb also has a new -authrestart which does an authenticated reboot after enabling FileVault. Before using the -authrestart option, check that a system can actually run it by using fdesetup with the supportsauthrestart verb and it will exit on true or false.

Defer mode is nothing new, where FileVault waits until a user password is provided; however, a new verb is available called showdeferralinfo which shows information about deferral mode. This is most helpful as a sanity check so you don’t go running commands you already ran or doing things to systems that have already been provided with tasks to perform otherwise.

Overall, there’s a lot of really enterprise-friendly options new in Yosemite that those who do larger-scale deployments of Yosemite will be interested in using!


Encrypting data in OS X can take on other forms as well. The keychains encrypt passwords and other objects. Additionally, you can still create encrypted dmgs and many file types have built in encryption as well. But the gist is that Apple encrypts a lot. They also sandbox a lot and with the addition of gatekeeper are code signing a lot. But encrypting volumes and disks is mostly about physical security, which these types of encryption provide a substantial solution for.

While all this security might seem like a lot, it’s been in Apple’s DNA for a long time and really security is about layers and the Mac Systems Administrator batbelt needs a lot of items to allow us to adapt to the changing landscape of security threats. OS X is becoming a little more like iOS as can be expected and so I would suspect that encryption will become more and more transparent as time goes on. Overall, the options allow encrypting every piece of data that goes anywhere near a system. The mechanisms with which data is now encrypted are secure, as is the data at rest. Once data is decrypted, features like Gatekeeper and the application layer firewall supplement traditional network encryption to keep well secured.

iPhone Mac OS X Mac OS X Server Mac Security Mass Deployment

Creating Users In Yosemite Server

There are three ways to create users in Yosemite Server (the Server app running on Yosemite if you’re so bored you feel the need to try and correct me). The first is using the Server app, the second is using the Users & Groups System Preference pane and the third is using the command line. In this article we will look at creating users in the Server app.

To do so, open the Server app and connect to your server. Then click on the Users entry in the ACCOUNTS list. The list of users is displayed, based on the directory domain(s) being browsed. A directory domain is a repository of account data, which can include local users, local network users and users in a shared directory service such as Open Directory and Active Directory.


The drop-down list allows you to see objects that are stored locally as well as on a shared directory server. Click on the plus sign to create a new account in the chosen Directory Domain.


When prompted, provide the following information about the new user:

  • Full Name: Usually the first and last name of the user.
  • Account Name: A shorter representation of that name with no spaces or special characters.
  • Email addresses: The email address to use if the account is going over quotas, has calendar invitations sent, or used for email hosted on the server, etc.
  • Password: The password the user will use to access services on the server.
  • Verify: The password a second time to make sure there are no spelling errors.
  • Allow user to administer this server: Optional field that grants the user administrative access to the server.
  • Home Folder: Optional field that by default creates local home directories for users that use the account but that also allows you to select a directory shared using the File Sharing service as a location for home folders. Each user in OS X has a home folder, this option defines whether that folder will reside on their computer or on a central server.
  • Keywords: Tags to make it easier to find users (a new feature for the Server app in Yosemite Server, but an old feature in the old Workgroup Manager).
  • Disk Quota: Define the amount of space an account can take up on servers.
  • Notes: Any information you’d like to enter to remember things about the user.

Note: Optionally, you can also drag an image onto the image shown in the New User screen if you’d like the user to have an avatar as done in the above screenshot.

Once the account details are as you would like, click on the Done button. The account will then be displayed in the list of available accounts. If the server has not been made an Open Directory server then you can only create local users through the Server app.

Once the account is created, right-click click on the user to see the option to edit the account you just created, edit their access to services hosted on the server, configure email information and change their password.


Click Edit User. Here, you have two new features. You can add the user to groups and use the checkbox for “log in” to disable the account.


Click Cancel and then using the cog wheel menu while the user is highlighted, note that you can, click on Edit Access to Services. Here, uncheck each service that the user should not have access to. If the service isn’t running then it’s not a big deal. You can highlight multiple accounts concurrently and then use this option to disable services for users en masse. Here, you can also edit your user templates (which are settings inherited by new users who you select that template for) as well as edit advanced options, such as changing the UID, default group, short name, aliases, default shell and home directory path. As the screen indicates, only change this stuff if you know exactly what you’re doing.