Archive for December, 2014

Hiding user accounts in Yosemite

December 31, 2014 7 comments

On December 8th, 2014, Apple posted a KBase article showing a way to hide user accounts in Yosemite that was different than the methods available in previous versions of OS X.

In Yosemite, you can add an IsHidden user attribute to the user’s account record and set a specific value in order to hide or unhide the account:

  • Hide: Set the IsHidden user attribute’s value to 1
  • Unhide: Set the IsHidden user attribute’s value to 0

It’s also possible to unhide a hidden account by deleting the IsHidden user attribute from the user’s account record. For more details, see below the jump.

Read more…

Managing automatic App Store and OS X update installation on Yosemite

December 29, 2014 10 comments

To go along with the automatic installation of security updates, there are also options in Yosemite’s App Store preferences in System Preferences to have your Mac automatically install available updates for OS X and updates for applications from the Mac App Store. For more details, see below the jump.

Read more…

2014 in review

December 29, 2014 Leave a comment

The stats helper monkeys prepared a 2014 annual report for this blog.

Here's an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 1,000,000 times in 2014. If it were an exhibit at the Louvre Museum, it would take about 43 days for that many people to see it.

Click here to see the complete report.

Categories: Technical

Managing automatic installation of ConfigData and security software updates on Yosemite

December 27, 2014 2 comments

As mentioned previously, the updates for XProtect’s blacklist moved into Apple’s software update feed starting in Mavericks. Gatekeeper updates are also included in the software update feed on Mavericks and Yosemite, so both XProtect and Gatekeeper updates are being delivered to machines using the same delivery mechanism.

To help distinguish Gatekeeper and XProtect updates from other updates in the software update feed, Apple marks them as being ConfigData updates. For more details on this and how you can manage their automatic installation, see below the jump.

Read more…

Adding a self-signed Casper Root CA as a trusted root

December 24, 2014 1 comment

Since Elliot Jordan’s presentation at JAMF Nation User Conference 2014, I’ve started using AutoPkgr in combination with Shea Craig’s JSSImporter to automatically package and upload a number of software packages to my Casper servers.

Having AutoPkgr handle this task has been great, but I’ve had to do some additional work to make sure that JSSImporter was OK with Casper using SSL certificates issued by its own internal certificate authority instead of by a third-party external certificate authority like Verisign. On top of that, the urllib3 library used by JSSImporter added a new warning that is triggered by HTTPS requests that use an certificate that can’t be validated. Since the Casper server was signing its own certificates using its own internal certificate authority, this warning was being triggered on every AutoPkg recipes’ run, which sometimes resulted in interesting emails like the one below.

Screen Shot 2014-12-24 at 9.26.24 AM

I could have installed the Casper agent on the VM that I was using to host AutoPkgr, which would have installed the root certificate for the Casper server’s internal certificate authority. However, I didn’t necessarily want to have Casper manage the VM as that would have consumed one of my available Casper licenses on a machine that didn’t need management.

However, I did want to get the root certificate for the Casper server’s internal certificate authority installed on the VM. That would allow the Casper server’s SSL certificate to be recognized as a validated certificate and fix the issues I was having with not having a validated certificate.

For details on how I fixed this, see below the jump.

Read more…

Managing OS X’s automatic security updates

December 24, 2014 2 comments

On Monday, December 22nd, Apple released OS X NTP Security Update 1.0 to fix a vulnerability in ntpd. What caught many folks off-guard was that this update installed itself in many cases, without action or authorization by the human using the Mac in question.

Security Update Installed notification

This marked the first time Apple has used its capability to push and automatically install an OS X security update, though the actual capability has been in OS X since OS X 10.8.x. Apple has used a similar capability in OS X 10.9.x and later to push updates for Apple’s XProtect and Gatekeeper.

So how did Apple make OS X NTP Security Update 1.0 install automatically? See below the jump for more details.

Read more…

fdesetup sync – fdesetup’s misunderstood command

December 21, 2014 3 comments

Apple’s fdesetup tool includes a number of commands, including fdesetup sync. In the fdesetup manpage, sync is listed with the following description:

Synchronizes information from Open Directory to FileVault

Screen Shot 2014-12-21 at 10.55.50 AM

Since the description is brief and vague, misunderstandings about what fdesetup sync‘s functions were almost inevitable. Based on my research, here’s fdesetup sync does:

1. Automate the disabling of FileVault 2-enabled accounts

fdesetup sync checks with a Mac’s directory service (Active Directory, Open Directory, OpenLDAP, etc.) to see which accounts have been removed. If an account has been removed from the directory service, running fdesetup sync on an encrypted Mac will automatically remove the account from the list of FileVault 2 enabled accounts. The sync only affects the account’s FileVault 2 status and will not remove the account or account home folder from the Mac.

An important thing to know is that fdesetup is only checking to see if the account is there or not there. It’s unable to determine if an account has been set to be disabled. If an account has been disabled but the account is still there, fdesetup sync will not change the FileVault 2 status of the account in question.

2. Automate the update of accounts’ user pictures

fdesetup sync checks with a Mac’s directory service (Active Directory, Open Directory, OpenLDAP, etc.) to see which accounts have user pictures associated with the account. If an account’s user picture is updated on the directory service, running fdesetup sync will allow the updated user picture to also be displayed on the FileVault 2 pre-boot login screen.

In many cases, this information will also have been updated automatically by the OS without the need for fdesetup sync to be run.

With those capabilities in mind, here’s two common misunderstandings I’ve seen or heard of in connection with fdesetup sync:

1. fdesetup sync updates the passwords at the pre-boot login screen

It does not. Based on my research, it appears that this job may be handled by opendirectoryd’s FDESupport module. I haven’t confirmed that with Apple though, so for the moment, treat this information about FDESupport as being my opinion rather than a fact.

2. fdesetup sync can automatically add accounts to a FileVault 2-encrypted Mac.

It does not, and the manpage for fdesetup is explicit about this point elsewhere in the manpage.

Screen Shot 2014-12-21 at 11.59.00 AM

NOTE: The manpage for fdesetup has a typo where it refers to a fdesetupsyncusers” command. This is actually referring to fdesetup sync.

%d bloggers like this: