In a number of Mac environments, there is a need or requirement for a login banner (otherwise known as a lock message). This message appears in the following locations:
- FileVault 2 pre-boot login screen
- OS login window
- Screensaver lock window
Brevity is best, as staying within a maximum of three lines permits the banner text to be displayed consistently in all three locations. Exceeding the three-line limit may result in the text being cut off and not fully displayed.
You can set this banner text from the command line using the following defaults command, which should be run with root privileges:
/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"
Being able to consistently set when lines begin and end can be challenging though, as the defaults command is not able to interpret a newline command natively. However, it is possible to set a multi-line login banner and be able to consistently set when lines begin and end. For more details, see below the jump.
While discussing various issues with a colleague, he mentioned that he was seeing the root account enabled on several machines where it should not have been. In general, the root account on macOS is not needed for system administration and should be disabled so he asked if there was a way to use the dsenableroot command to disable the root account without also needing to provide a password.
Unfortunately, disabling the root account by using the dsenableroot -d command does require providing a password as part of the command.
However, it is possible to disable logins to the root account without using the dsenableroot -d command. For more details, see below the jump.
Every so often, it’s necessary to resize the boot drive of an existing virtual machine. The process of resizing the VM’s boot disk from outside the VM is usually pretty straightforward:
1. Shut down the VM
2. Go into the VM’s drive settings
3. Resize it to the desired size
4. Power on the VM.
However, when the VM boots up, the disk space used by the OS won’t have changed.
However, the OS can detect that there is available unallocated disk space that it isn’t using.
Fortunately, this is a correctable condition and the fix can be applied without needing to shut down the VM or boot from another drive. For more details, see below the jump.
It can be difficult to provide consistent access for Mac admins when using a local admin account on FileVault 2-encrypted Macs, due to the way password changes are handled for FileVault 2-enabled accounts. The reason for the difficulty is that FileVault 2’s encryption doesn’t care about passwords, it only cares about encryption keys.
When an account on a particular Mac is enabled for FileVault 2, the account’s password is used to generate an key which can be used to unlock the encrypted Core Storage volume that FileVault 2 sets up on the Mac. When the password for the enabled account gets changed, the password and its associated key are updated by first requesting the previous password (and its associated key) to authenticate the change to the new password and associated key.
Assuming that the old password is provided as part of the password change process, no problem. However, if the old password is not provided as part of the password change process, the new password does not get an associated key to unlock FileVault 2 because the old password’s key was not invoked to authorize the change to a new key. The result of this is that the new password can be used to log into the OS and provide whatever password authorization duties are needed for the OS, but you still need the account’s old password to log into the Mac at the FileVault 2 login screen.
The usual fix for this situation is to run the following commands with root privileges:
1. Remove the user from the list of FileVault 2-enabled accounts
fdesetup remove -user username_goes_here
2. Add the user back to the list of FileVault 2-enabled accounts
fdesetup add -usertoadd username_goes_here
When the account is re-enabled using the fdesetup add -usertoadd command, a new key is set up for the user and the passwords are back in sync. However, there are two drawbacks to this approach if a Mac admin wants to automate this:
- You need to provide the password in a non-encrypted format of the account being enabled.
- You need to provide in a non-encrypted format either a recovery key or the password of another FV 2-enabled account on the Mac.
In short, the passwords and/or recovery key used to remove and re-enable the account in question need to be provided “in the clear”, where anyone successfully intercepting the passwords will be able to read them.
Fortunately, for those Mac admins who have a way to capture and escrow FileVault 2 personal recovery keys, there is an alternative to enabling the local admin account. For more details, see below the jump.
A lot of Mac admins need to test software in their environment against both the shipping version of macOS and older versions of OS X. However, getting older OS installers from the Mac App Store (MAS) can be problematic if the Mac you’re using isn’t able to run the older OS as its own operating system. If the Mac you’re using isn’t itself able to run the older OS, a request to download the OS installer from the MAS will result in an error message like the one shown below.
If you’re in this situation, but also have VMware Fusion or a similar virtualization solution available, there is a way to download the desired older OS installer using a VM running the shipping version of macOS. For more details, see below the jump.
As part of assisting a colleague with a customer today, I needed to figure out how to enable the debug logging for Microsoft AutoUpdate. For Mac admins with a similar need, please see below the jump for details.
On some occasions, it’s useful to be able to make a full backup of a system on an ad-hoc basis. One example would be making a complete backup of a Mac’s boot drive before sending it in to Apple for a repair, as Apple may swap out or erase the Mac’s existing boot drive as part of the repair process if their tools indicate a drive problem.
When I’ve needed to do this, I’ve used DeployStudio for this task. The reason why is that DeployStudio includes the ability to do the following:
- Create an asr-ready disk image from a Mac’s boot drive containing the OS and all other data.
- Restore the disk image to an available volume on the same or different Mac, and setting the target volume to be bootable.
These capabilities were originally designed to allow monolithic images to be created from one Mac for distribution to other Macs, but these capabilities also allow DeployStudio to create on-demand backups of a Mac’s boot drive. For more details, see below the jump.