As part of Firefox 31’s release, Mozilla made a change to enable support for NT LAN Manager version 1 (NTLMv1) network authentication when connecting to sites that are using HTTPS to allow encrypted communication via SSL between Firefox 31 and the website in question. This is to address the change made in Firefox 30, which disabled support for NT LAN Manager version 1 (NTLMv1) network authentication for sites using either HTTP and HTTPS.
NTLMv1 authentication to sites using HTTP is still disabled by default. For more information on why HTTPS is now enabled while HTTP remains disabled, this Mozilla bug report discusses the issue.
A way to tell if the NTLMv1-using site you’re trying to access is using HTTP or HTTPS is to check the connection address. If it begins with https://, you should be OK. If it begins with http:// , Firefox 31 will still block NTLMv1 authentication.
If you need to enable NTLMv1 authentication for an HTTP site that uses NTLMv1 authentication, Mozilla has provided a workaround to non-Windows users of Firefox, in the form of a setting that can be toggled to allow NTLMv1 authentication. This workaround should allow Mac and Linux users to continue using NTLMv1 authentication on HTTP sites, which will allow access again to SharePoint-based or IIS-backed web applications. For those folks who need it, I have the workaround documented here.
The Linde Group has released a new tool on Github: AutoPkgr, a GUI interface for AutoPkg. In my working with the initial release today, I’ve been impressed with the problems it solves for Mac admins who want to get started using AutoPkg but aren’t sure where to begin.
To use AutoPkgr, you will need to have the following pre-requisites:
1. OS X 10.9.x
3. Acceptance of the Xcode license agreement.
4. A logged-in user to run the AutoPkgr application in. This user can be a standard user or have admin rights.
Once the prerequisites have been met, see below the jump for details on installation and configuration.
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:
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.
As part of Firefox 30′s release, Mozilla made a change to disable support for NT LAN Manager version 1 (NTLMv1) network authentication. This change affects sites using Microsoft’s SharePoint or IIS services. The Windows version of Firefox 30 should switch to using NTLMv2 authentication automatically, but NTLMv2 is not supported by Firefox on non-Windows platforms.
Update – 7-22-2014: Mozilla has released Firefox 31, which now allows access on non-Windows platforms to Sharepoint and IIS sites using HTTPS. For more details, see this post.
The result for non-Windows platforms is that access may be blocked when Firefox 30 users try to access those kinds of sites.
Mozilla has provided a workaround to non-Windows users of Firefox, in the form of a setting that can be toggled to allow NTLMv1 authentication. This workaround should allow Mac and Linux users to continue using NTLMv1 authentication, which will allow access again to SharePoint-based or IIS-backed web applications. For more details, see below the jump.
Back when Apple Remote Desktop 1.2 (ARD) was the main tool I used to administer my Macs remotely, I wanted to be able to run Unix commands remotely but needed a delivery vehicle that could send them over ARD. Payload-free installer packages were the answer.
Installer packages are Apple’s preferred way to install software. Apple built into ARD the ability to install software on remote machines using the Install Packages… function. One useful feature of installer packages is that you can have them run a script before or after the package is installed. You can even set up a number of scripts and have them run in the order you designate. Best of all, you can build a payload-free installer package that run scripts but does not install files. So, when I needed to run a Unix command on one or more of my managed Macs, I’d normally build a payload-free package and use the Install Packages… function to push it out to the relevant machines.
With Apple Remote Desktop 2 and later, Apple included a Send Unix Command… function. This gives you the ability to send a Unix command and get the feedback from the remote machine, without the extra work of building a payload-free installer package. However, the practice of building payload-free packages and using those to run my Unix commands stayed with me for the following reasons:
1. Ease of use – Running a script contained within a payload-free package does not require any special knowledge or training. All the person using it has to know is how to run an installation using an installer package.
2. Portability – When my management methods evolved beyond using ARD as my primary management tool, I found that different management tools had their own ways to deploy scripts but a common denominator of system management and deployment tools for Macs is that they can deploy installer packages. Using payload-free packages allows me to run scripts on managed machines in a consistent manner regardless of which management or deployment tool is being used.
When checking for Apple software updates today, my colleague Tim Sutton noticed that there was a problem with checking updates. When I checked for updates on my 10.8.x and 10.9.x Macs using the App Store and the command-line softwareupdate tool, I received the same error from both:
The operation couldn’t be completed. (NSURLErrorDomain error -1012.)
The reason for the error has its root in a change which Apple introduced with OS X 10.8.x, where Macs running 10.8.x and 10.9.x use an HTTPS URL to check for updates on Apple’s Software Update servers. It appears that the SSL certificate used to validate Apple’s Software Update service has expired as of Saturday, May 24th at 7:59:59 PM Eastern Daylight Time.
Since the certificate needs to be valid in order for connections to Apple’s Software Update servers to work properly, the certificate expiration is preventing the Software Update service from connecting.
When I checked for software updates on Macs running 10.7.5 and 10.6.8, they were unaffected by this issue. Macs running 10.7.x and older use an HTTP URL to connect to Apple’s Software Update servers, which means they do not use an SSL certificate to validate the connection.
Hopefully, Apple is able to get a new certificate in place soon. Once a valid certificate is in place, Apple’s Software Update service should begin working again for Macs running 10.8.x and higher.
Update: May 25th, 2014 – It appears that Apple has acted with dispatch to fix this issue. A new SSL certificate is now in place, with an expiration date of Tuesday, May 24, 2016 at 7:59:59 PM Eastern Daylight Time.