Hiding user accounts in Yosemite

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.

Managing automatic App Store and OS X update installation on Yosemite

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.

2014 in review

The WordPress.com 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.

Managing automatic installation of ConfigData and security software updates on Yosemite

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.

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

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.

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.

Managing OS X’s automatic security updates

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.

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.

fdesetup sync – fdesetup’s misunderstood command

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

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.

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

Performing password resets on Yosemite with unsetpassword

One issue that can crop up for Mac admins is the problem of “I don’t want to know my users’ passwords, but I need to set up their accounts.” When setting up accounts from a directory service like Active Directory or Open Directory, this problem can be avoided because it’s relatively easy to set up a Mac to use an account from a directory service without ever needing to know the user’s password.

The situation is different for local users with admin privileges on a machine though, as the Mac admin has two ways to proceed:

1. Set a password on the local account, then give the password to the user.
2. Set the password of the local account to be blank.

The first approach means that the Mac admin knows the password, which is a security issue. The second approach means that there’s no password at all and the user may opt to keep it that way, which is a greater security issue.

To help address this issue, the new unsetpassword tool in Yosemite allows an admin to set up a new local account with admin rights, then remove the account’s existing password and require a new one be set on the next login.

The unsetpassword tool does not have a man page. To learn how it works, run the following command in the Terminal:

unsetpassword --help

One thing to be aware of is that while the password is removed, the account’s login keychain is not and will still be set to use the previous password. On login, the user will be prompted to create a new keychain.

To demonstrate how to use unsetpassword, I’ve made a video showing the following process:

1. Running unsetpassword on the logged-in account
2. The Mac shutting down
3. Booting the Mac
4. Setting a new password on the next login
5. Choosing to create a new keychain

Note: The video has been edited to artificially reduce the amount of time it took to boot after the shutdown. Run time of the pre-edited video was 2 minutes, forty seconds.

Ten Things You Might Not Know About FileVault 2

One of the changes that Steve Jobs briefly mentioned in the course of the WWDC 2011 keynote address was that Apple had revamped its FileVault encryption solution for Mac OS X 10.7.x, changing it from encryption that primarily protected your accounts home folder to encryption that protects your whole boot volume. Since that initial announcement, FileVault 2 has evolved into an encryption solution that can be easily managed by both home users and enterprises alike.

That said, almost every technology solution has details and parts that aren’t generally well known and FileVault 2 is not different in that regard. To help Mac admins who are managing FileVault 2 in their own environment, I’ve put together a list of 10 things I’ve run across in my work with FileVault 2 that I’ve either been asked about frequently or which seem to be completely undocumented by Apple. Most of these I’ve previously documented in one form or another, so some of these may seem familiar. See below the jump for the list.

Forcing XProtect blacklist updates on Mavericks and Yosemite

One of the changes Apple made between Mountain Lion and Mavericks was how XProtect was updated. On 10.6.x – 10.8.x, Apple used /usr/libexec/XProtectUpdater to update XProtect’s blacklist. If you needed to force XProtect to update, you could run the following command with root privileges:

/usr/libexec/XProtectUpdater

Running that command with root privileges would force a check-in with Apple’s XProtect feed. If XProtect needed an update, running this command would check the current XProtect blacklist, detect that the online version was newer and pull down the new version. Once the new version had downloaded, XProtectUpdater would then exit.

If XProtect was up to date, running this command would check the current XProtect blacklist and detect that the online version was the same as what was currently loaded on the system. XProtect would then produce a notification that it was ignoring the update because the online version was not newer than the one already on the system. XProtectUpdater would then exit.

In 10.9.x and continuing on in 10.10.x, Apple moved the XProtect updates into Apple’s software update feed. As part of this change, the previous way of forcing XProtect by running /usr/libexec/XProtectUpdater no longer worked because /usr/libexec/XProtectUpdater did not exist on 10.9.x and higher.

Instead, you now need to use the softwareupdate command to force the update process. For more details, see below the jump.