Selecting a startup disk when you put a firmware password on a Windows single-boot Mac

Usually, when you put a firmware password on a Mac, you can double-check in System Preferences > Startup Disk to see if the proper startup disk (or any startup disk) is selected.

Since the default behavior of the firmware password is you needing to enter the password in order to boot from anything other than the startup disk, you probably want to have a startup disk selected (otherwise, you'll get the folder with a question mark inside of it when you boot up).

In most cases, this isn't that difficult, but if you set up a single-boot Windows installation, you may not always see it available for selection if you boot to recovery mode or boot to macOS from an external drive.

Instead, you may want to just boot into Windows (hold down the option key and enter the firmware password if you need to this one time), and then launch up the Bootcamp Control Panel, and you can set the startup disk there.

BlacklistRegex and WhitelistRegex on Santa

Acknowledgements

Thanks once again to @bur on the Mac Admins Slack for the info I'm documenting here.

BlacklistRegex and WhitelistRegex

In a previous blog entry, I talked about using Santa to block apps by certificate (and I briefly mentioned blocking by binary).

You can also block by path using regular expressions. Binary takes precedence over certificate, which takes precedence over regex, so unfortunately you can't really block Apple apps (like Safari) using regex, because Santa automatically whitelists them by certificate—you can block them only by binary.

You may notice in the Santa documentation for configuration that both WhitelistRegex and BlacklistRegex are listed as string types instead of arrays of strings. That is absolutely true, so if you wanted to whitelist a whole bunch of app paths, you'd have to have a massively long string like this:

<key>WhitelistRegex</key>
<string>^(?:/Applications/Adobe Acrobat DC)/.*|^(?:/Applications/LockDown Browser.app)/.*|^(?:/Applications/Microsoft Excel.app)/.*|^(?:/Applications/Microsoft PowerPoint.app)/.*|^(?:/Applications/Microsoft Word.app)/.*</string>

Same deal for a BlacklistRegex string.

Create a .mobileconfig profile for a certificate

If you want to create .mobileconfig profile from a certificate (for example, to import into Munki), you can use Apple Configurator 2 to do so.

If you have your certificate already in your keychain, launch up Keychain Access.app and find the certificate you want to make into a .mobileconfig profile.

Right-click the certificate and select Export NAMEOFTHECERTIFICATE (export it as a .cer).

Then launch up Apple Configuration 2.app.

Select File and then New Profile


Select Certificates and then Configure.

Find and select the certificate you exported earlier.

Select File and then Save.


Pick a filename for your .mobileconfig, which you can deploy however you want (as I previously mentioned, you can import this into a Munki repo).

Using Santa to block an .app

Acknowledgements

Special shoutout to @bur on the Mac Admins Slack for help with some command-line syntax.

Santa can be complicated, but doesn't need to be

Google has a project on GitHub called Santa, which is quite powerful and complicated. As the project's readme says, though: Documentation: This is currently limited..

I just wanted to do something simple: block an app, but I didn't see any straightforward documentation on how to do that. The closest I could find was the docs on certificate rules, but that was a bit incomplete.

So, first of all, something I was confused about at first was whether a configuration profile was necessary or not. It is not necessary. There are some default settings that just go by themselves. You need to configure settings only if you need to configure settings.

Blocking an app by certificate

If you have a blocking application rule, you can block by binary or by certificate. By binary may not be as helpful, because newer versions of an app will be a different binary. Let's say you want to block MacKeeper by certificate. (Install Santa first, so you can actually use it, including the santactl command.)

santactl fileinfo /Applications/MacKeeper.app --key "Signing Chain"
Signing Chain:
1. SHA-256 : 2df1460a9c76c4a63fa2d0d043fb0254f8fa69a99374f2a0b1e8eee885872614
SHA-1 : 2664b71c3db787226ff9715da4de32e9ad3e364f
Common Name : Developer ID Application: KROMTECH ALLIANCE CORP. (64424ZBYX5)
Organization : KROMTECH ALLIANCE CORP.
Organizational Unit : 64424ZBYX5
Valid From : 2013/10/14 04:00:13 -0700
Valid Until : 2018/10/15 04:00:13 -0700

2. SHA-256 : 7afc9d01a62f03a2de9637936d4afe68090d2de18d03f29c88cfb0b1ba63587f
SHA-1 : 3b166c3b7dc4b751c9fe2afab9135641e388e186
Common Name : Developer ID Certification Authority
Organization : Apple Inc.
Organizational Unit : Apple Certification Authority
Valid From : 2012/02/01 14:12:15 -0800
Valid Until : 2027/02/01 14:12:15 -0800

3. SHA-256 : b0b1730ecbc7ff4505142c49f1295e6eda6bcaed7e2c68c5be91b5a11001f024
SHA-1 : 611e5b662c593a08ff58d14ae22452d198df6c60
Common Name : Apple Root CA
Organization : Apple Inc.
Organizational Unit : Apple Certification Authority
Valid From : 2006/04/25 14:40:36 -0700
Valid Until : 2035/02/09 13:40:36 -0800

Then, add a block rule for it:

sudo santactl rule --blacklist --certificate --sha256 2df1460a9c76c4a63fa2d0d043fb0254f8fa69a99374f2a0b1e8eee885872614

You can always check on the other parameters by running

sudo santactl rule
which will output something like this:
No state specified

Usage: santactl rule [options]
One of:
--whitelist: add to whitelist
--blacklist: add to blacklist
--silent-blacklist: add to silent blacklist
--remove: remove existing rule
--check: check for an existing rule

One of:
--path {path}: path of binary/bundle to add/remove.
Will add the hash of the file currently at that path.
Does not work with --check. Use the fileinfo verb to check.
the rule state of a file.
--sha256 {sha256}: hash to add/remove/check

Optionally:
--certificate: add or check a certificate sha256 rule instead of binary
--message {message}: custom message

If you then try to run MacKeeper, you'll get a block message like this:

That's pretty much it. That isn't everything Santa can do. That's about the simplest thing you can do with Santa, but most of the documentation for Santa is about all of the other stuff you can do. I didn't see much about just how to simply block an .app, hence this blog post.

If munkiimport doesn’t generate an installer_item_hash in the pkginfo file

If you notice that running munkiimport on a .dmg doesn't result in an installer_item_hash generating, you might want to also run makepkginfo on that .dmg to double-check it's read-only:

makepkginfo /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg
WARNING: /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg is a writable disk image. Checksum verification is not supported.
WARNING: Consider converting /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg to a read-only diskimage.

“Grant access” problem when trying to open Word docs

If you're trying to open a Word doc, and it keeps saying you don't have permission (even when you own the document), asking you to grant access to the document, and then still not giving you access; then just quit out of Word completely, and then launch it up again. The document should open fine after that.

Failing Adobe Acrobat DC updates

Usually when new Acrobat updates come out, I can have clients pull them off the Munki server and install those updates automatically. Randomly, some clients will error out:

installer: The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)
installer:%42.031690
installer:PHASE:Preparing for installation…
installer: Package name is Adobe Acrobat DC (18.011.20038)
installer:PHASE:Validating packages…
------------------------------------------------------------------------------
installer: Upgrading at base path /
installer:%97.750000
installer:PHASE:Configuring the installation…
installer:%72.402678
installer:PHASE:Writing files…
installer:PHASE:Running package scripts…
installer:PHASE:Preparing Adobe Acrobat DC (18.011.20038)…
installer:%4.485919
installer:PHASE:Waiting for other installations to complete…
installer:STATUS:
installer:PHASE:Preparing the disk…
At first I thought maybe having the update require a logout might fix that issue, but it doesn't. The only working solution I've found is to delete the Acrobat folder, run
sudo managedsoftwareupdate --auto
and then Munki will see that Acrobat is missing and install both Acrobat and the update just fine.

Not sure if there's a less involved way to fix that. And it seems to happen only for a few clients randomly.

When DEP nag won’t work but Setup Assistant will to enroll in your MDM

Explanation
Symptoms
Workaround
Automating
Other Considerations

Explanation

The two-days-later update: after doing troubleshooting with our MDM, asking around to other Mac admins, Google searching, and creating an enterprise case with Apple, I finally got back a definitive answer from Apple, which is that this functionality is essentially broken in Sierra (10.12.6). They're saying it should be fixed in High Sierra beta (10.13.4 right now). It makes a lot of sense. Almost all of our fleet is 10.12.6 (as of this writing, anyway), and the few computers that did work were on 10.13.2 or 10.13.3 (so not beta but still working).

So there you go. Either use the workaround below or upgrade to 10.13 if you're having this issue.

Symptoms

We have a bunch of computers that refuse to get a DEP (Device Enrollment Program) nag, even though they get the DEP prompt using Setup Assistant.

I tried blowing out a bunch of files and folders by following the Reset an enrollment section of How to troubleshoot your DEP/MDM Enrollments (on the MicroMDM blog but with generic instructions that can work for any MDM). That worked, but it requires you to go through the Setup Assistant.

I tried creating two fresh (never booted) AutoDMG-created images—one that skips the Setup Assistant and one that doesn't. If I don't skip the Setup Assistant, it obviously works. Here's the weird thing, though: if I do skip the Setup Assistant, then running

sudo profiles -N
doesn't work (skips to the next line in the terminal) and
sudo /usr/libexec/mdmclient dep nag
either gives me this error:
[ERROR] Unable to get activation record: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.ManagedClient.cloudconfigurationd" UserInfo={NSDebugDescription=connection to service named com.apple.ManagedClient.cloudconfigurationd}
or spits back the activation record dictionary (but with no actual nag appearing):
Activation record: {
AllowPairing = 0;
AwaitDeviceConfigured = 0;
ConfigurationURL = "https://mymdmsenrollmentsurl.com/withabunchofotherstuffattheend";
IsMDMUnremovable = 1;
IsMandatory = 1;
IsSupervised = 1;
OrganizationAddress = "Our Address";
OrganizationEmail = "Our email";
OrganizationMagic = someidentifier;
OrganizationName = "Our organization name";
OrganizationPhone = Our organization phone;
SkipSetup = (
Passcode,
Registration,
Location,
Restore,
AppleID,
TOS,
Biometric,
Payment,
Zoom,
Siri,
Diagnostics,
FileVault,
iCloudDiagnostics
);
}
Now, if I actually just delete the /var/db/.AppleSetupDone file at this point and then go through the Setup Assistant, the Mac will DEP-enroll into the MDM.

So there is no network issue here (I've also tested there being no network issue on these devices by temporarily tethering them to my phone to go outside of our school's firewall—same issue).

So I really have no idea what's going on here. My MDM has all of the log information and all of my tests and insists it's not a problem on their end, but it's not the network, and it's not the image (again, a freshly created never-booted image).

Workaround

So, as yet, I don't have a solution for this. Maybe I'm the only one experiencing this. I've asked around on the Mac Admins Slack, contacted my MDM directly, contacted our Apple rep directly, done a ton of Google searches. Seems a bit weird that it's just us with a never-booted image having issues on and off network.

There is good news, though. I don't have to do Setup Assistant for every single computer or do (much worse) a factory reset on each machine to DEP-enroll it (and, yes, we have a whole deployed fleet already that needs to be DEP-enrolled).

I found that if I take the ConfigurationURL from the activation record dictionary and just put that in Safari, it will download and try to install the MDM profile in a DEP way (not just in a non-DEP way).

So the only real missing piece is the actual notification that pops up. Notifications aren't blocked (again, on a never-booted AutoDMG-created image, why would they without some custom script explicitly doing so).

Update (18/02/08): At least one other person, using another MDM, has not found this to work. Safari just loads a blank page and doesn't download and install the enrollment profile. I'm using Mosyle, and this works for Mosyle at least, as of this writing.

Automating

If that works for you (putting the ConfigurationURL in Safari and installing the profile via System Preferences), you can try also automating the workaround by having the .mobileconfig delivered as a payload to /tmp and then running a script like this as a postinstall script:

#!/bin/bash

# Install profile
/usr/bin/profiles -I -F "$3"/tmp/NAMEOFDEPPROFILE.mobileconfig
Had to run the separate profiles command because Munki will not support managing enrollment profiles.

Other Considerations

You don't have to use Safari to go to the ConfigurationURL, but it's handy to do so, because Safari, after downloading the enrollment profile, will just launch up System Preferences and try to install the profile. If you use another browser (e.g., Chrome), it will just download the profile, and you'll have to open it to get it to launch System Preferences to prompt for an install.

Yes, you can also just enroll in the MDM without using DEP, but Apple—with High Sierra's APFS default and the iMac Pro's secure boot—is moving more toward making macOS like iOS, so it's possible that DEP-enrolled devices may be treated differently or have different functionality from non-DEP-enrolled (but still MDM'ed) devices. Probably safest to do a DEP-enroll into the MDM.

MacBook Air keyboard backlight disabled with a “do not enter” sign

Acknowledgements: Hat tip to my colleague Jerold for stumbling upon this fix.

We had a user come in with a MacBook Air whose keyboard backlight wouldn't turn on. If you pressed the F5 or F6 key to turn it up or down, there would be on-screen feedback but instead of a indicator bar showing it going up or down, there would be only a "do not enter" sign appearing.

We tried an SMC reset and an NVRAM reset, to no avail.

Finally, Jerold just thought "Why don't we plug it into an external monitor?" For some reason, that fixed it (even after unplugging it from the external monitor).

So if you run into this issue, that may not be a sure fix, but it's certainly something to try!