As part of the man page for fdesetup, Apple provides a sample plist file as a guide for those who want to import authentication credentials as part of running commands with fdesetup.
As part of the plist, there are two plist keys that reference using a keychain which contains the private key for an institutional recovery key:
For KeychainPath, you will need to provide the file path to the keychain as the plist value. For KeychainPath, you will need to provide the password that unlocks that keychain.
For example, if you put the keychain file into the /tmp directory, you would reference /tmp/filename.keychain as the KeychainPath plist value. If the password to unlock that keychain is seKritPassword, you would reference seKritPassword as the KeychainPassword plist value.
One particular thing to note is that the KeychainPath entry on the fdesetup man page references that this works with certain fdesetup commands, but does not specify which commands are applicable.
As of OS X 10.9.4, it appears that you can leverage the KeychainPath and KeychainPassword plist keys with the following two fdesetup commands.
If using the current institutional key to authenticate, the plist should look like this.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>KeychainPath</key> <string>/path/to/filename.keychain</string> <key>KeychainPassword</key> <string>password</string> </dict> </plist>
If you are using the current institutional key to authenticate a change to a new institutional recovery key, you can also embed the public key of the new institutional recovery key in the plist. In that case, the plist will look like this.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>KeychainPath</key> <string>/path/to/filename.keychain</string> <key>KeychainPassword</key> <string>password</string> <key>Certificate</key> <data> (Certificate data goes here.) </data> </dict> </plist>
VMware has released the VMware Fusion Technology Preview July 2014 as of Jul 3, 2014. One of the new items included in the Features list was this one:
Support for viewing VMware Fusion Professional to VMware Workstation, VMware ESXi, VMware vSphere servers in the library (File > Connect to Server)
When I investigated, it looks like this feature brings to VMware Fusion something that’s been in VMware Workstation for a while: a way to manage free ESXi and paid vSphere servers.
For more details, see below the jump.
Since Casper 9.x was first released, I’ve been preparing for my shop’s own upgrade from Casper 8.x to 9.x. As of the morning of Saturday, June 28th, those preparations have ended with my shop’s successful upgrade to Casper 9.32. When I mentioned this on Twitter, I heard from a few folks who mentioned that they were planning to also do this in the near future and @theycallmebauer asked if I was going to post about my experience.
I thought that was a good idea, so please see below the jump for the details.
One of the more interesting functions in Apple’s fdesetup tool is the authrestart verb, which allows a FileVault 2-encrypted Mac to restart and bypass the FileVault 2 pre-boot login screen. Instead, the Mac reboots as a unlocked system and goes straight to the regular login window.
When you run the fdesetup authrestart command, it asks for a password or a personal recovery key. The password must be an account that has been enabled for FileVault 2 (i.e. an account that shows up at the FileVault 2 pre-boot login screen.) After that, it puts an unlock key in system memory and reboots. On reboot, the reboot process automatically clears the unlock key from memory.
For those who want to automate this process, Apple added some functionality to fdesetup authrestart in Mavericks to support importing the authentication via a properly formatted plist. The plist needs to follow the format below:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Password</key> <string>password</string> </dict> </plist>
You would store either the password of an existing FileVault 2-enabled user or the existing personal recovery key in the Password key in the plist.
Once the plist has been set up and properly formatted, run the following command to run the authrestart process and reference the password or recovery key in the plist file for authentication.
sudo fdesetup authrestart -inputplist < /path/to/filename.plist
The man page for fdesetup also indicates that you can use a keychain with both the private and public keys associated with an institutional recovery key to authenticate the authrestart process. Based on the manpage, you should be able to run the following command to run the authrestart process and reference the institutional recovery key for authentication.
sudo fdesetup authrestart -key /path/to/filename.keychain
As of OS X 10.9.3, this does not appear to work. Instead of being prompted for the keychain's password and the Mac restarting, an Error: Unable to restart message is displayed and nothing else happens.
If manually restarted, the Mac will reboot to the FileVault 2 pre-boot login screen.
I've filed a bug with Apple at bugreport.apple.com about this behavior. If you want to also file a bug report on this, please reference the following bug ID when submitting your report:
I’ve got the details of my bug report posted at Open Radar:
I’ll be collaborating with my colleague Jeremy Reichman to give a session at the Penn State MacAdmins Conference 2014, which is being held from July 8th – 11th, 2013 in State College. For those interested, our talk will be on Friday, July 11th.
For a description of what we’ll be talking about, please see the Extending OS X Management Systems with Scripting session description. You can see the whole list of speakers here on the Sessions page.
I’ll be speaking about FileVault 2 at the Penn State MacAdmins Conference 2014, which is being held from July 8th – 11th, 2013 in State College. For those interested, my talk will be on Thursday, July 10th.
A while back, I wrote a post on fixing Casper Mac MDM enrollment. This post covered my experiences with Casper 8.7.x and provided a method to automatically fix any problems with the MDM certificate. Unfortunately, the method that works in 8.7.x does not work in 9.x because the command that I use to do the MDM enrollment in Casper 8.x is jamf mdm. As part of the change from Casper 8.x to 9.x, the function performed by the jamf mdm command is now handled by the jamf manage command in Casper 9.x. The jamf mdm command itself does not exist in Casper 9.x
To duplicate the general process which I’m using in Casper 8.x, I needed to run the following commands:
/usr/sbin/jamf removeMdmProfile -verbose /usr/sbin/jamf manage -verbose /usr/sbin/jamf recon
The issue I ran into is that jamf manage waits until all policies are finished running, which meant that the MDM fix is running after the jamf recon command completes its inventory update and sends it on to the Casper server. The consequence is that the Casper server would never be informed that the machine had actually been fixed, which potentially cues an infinite loop of fixing a problem which is already fixed.
So I had two issues:
1. I wanted to fix my problem with a Casper smart group that would contain only affected machines and an associated Casper policy that would fix the machines in the smart group. This would allow the problem to be automatically detected and then fixed without the need for human intervention.
2. I needed to make reasonably sure all policies were finished running before trying to run the jamf manage command. Otherwise, running jamf manage would result in the recon running before the MDM certificate gets fixed.
On top of that, I preferred that jamf manage only be run once rather than building a process that potentially ran it a large number of times.
To sum up:
A) I wanted to fix the problem automatically with a Casper policy.
B) I couldn't directly fix this with a Casper policy. Running the commands above using a policy would mean that jamf manage and jamf recon would not run in the order I wanted them to, with the undesired "infinite loop" consequences described above.
Shea Craig gave me the idea of using a LaunchDaemon and script to run the commands I needed, but I still needed a reliable way of determining if Casper policies were running. Shea's approach relies on killing the jamf process as needed, but that ran the risk of interrupting any active policies or other tasks that were running.
After mulling over the problem for a while, I thought of another way to determine if a policy was running. /var/log/jamf.log is updated when Casper policies or check-ins run on an individual Mac, so if the log hasn't been updated in a while, it is very unlikely that a policy is running.
Using this idea, I wrote a script and an associated LaunchDaemon to perform the following tasks:
1. Verify that the Mac can contact the Casper server.
2. Verify that /var/log/jamf.log has not been written to in the past five minutes.
3. If /var/log/jamf.log has not been written to in the past five minutes, fix the MDM certificate and communicate that it is fixed to the Casper server.
4. Delete itself and its associated launchdaemon.
For the details, see below the jump.