Summary of macOS 10.13.4 information and links

[RobertHammen]

About the macOS High Sierra 10.13.4 Update (build 17E199)

Apple Security Updates

About the security content of macOS High Sierra 10.13.4 (build 17E199), Security Update 2018-002 Sie...

Prepare your institution for macOS High Sierra 10.13.4
(Check out the new startosinstall flag --eraseinstall on 10.13.4 (requires APFS). Combined with --installpackage and/or --agreetolicense, this can be a really powerful combination for automating deployments or redeployments. You can now also use multiple --installpackage flags on the same command to install multiple packages after the OS install).

Use an external graphics processor with your Mac

Detecting user approved MDM using the profiles command line tool on macOS 10.13.4

New automated restart option added to macOS 10.13.4's softwareupdate command line tool

10.13.4 UAMDM

--
The three critical takeaways for everyone, are:

1) If you are not already enrolled in an MDM, trying to enroll a Mac in an MDM after 10.13.4 is deployed will require the user to approve the installation of the MDM profile with a physical mouse click (no VNC or screen sharing!), unless you are using DEP*. Macs enrolled in an MDM, then upgraded to 10.13.4 or later have the MDM profile automatically approved. This is UAMDM (User Approved MDM). Apple KB article on UAMDM

2) If you have a High Sierra Mac enrolled in an MDM prior to 10.13.4, you did not have to worry about UAKEL (User Approved Kernel Exension Loading) as you received an automatic bypass of this new feature, where High Sierra would prompt (once) for the user to "approve" non-Apple kernel extensions. Well, that auto bypass no longer exists in 10.13.4., You need to create a config profile whitelisting the Team IDs and perhaps the bundle IDs of any non-Apple kernel extensions that you wish to load (i.e. for security and A/V suites). For example, Jamf added this functionality in Jamf Pro 10.2.2, but you can also hand-craft and sign a profile and deploy it with any MDM (must be deployed via MDM, cannot be manually installed).

3) End users will also be notified (once per app, on the first launch of that app) if they open/use a 32-bit app, since it's assumed that macOS 10.14, like iOS 11, will not allow 32-bit apps to run. You can suppress this warning with a config profile as well.

Please make sure you read and understand the above three issues before you upgrade any Macs you manage to 10.13.4. You will also want to test if an issue, discovered in the betas, where the first time a new mobile account logged into a Mac, there was a prompt for admin credentials to add a SecureToken to the mobile account (whether encryption was enabled or not) is still present in the GM release of 10.13.4. Your users can cancel out of this dialog, but many admins find this a poor user experience.

For more on SecureToken and FileVault, see: this link

macOS High Sierra 10.13.4 is also no longer "forked" for mainstream Macs and iMac Pro; one version now for all currently-shipping Macs.

*Jeremy Baker figured out a way to remotely approve UAMDM, although I don't know if this still works with 10.13.4 GM: JerBecause

[donmontalvo]

Awesome post!

[bradtchapman]

I tried Jeremy Baker's script. It doesn't work on an unmodified Mac until you grant Accessibility to Script Editor. Also, you can't do this part programmatically because Accessibility Settings are now protected by SIP (/Library/Application Support/com.apple.TCC/TCC.db). It is sqlite3 formatted, so you could read from it. (sqlite3 {filename} 'select * from access;')

In other words, for JerBecause's exploit to work, a remote technician would have to 1) enable accessibility services for Script Editor, 2) paste in the script, then 3) run it, and 4) remove the entitlement from Accessibility when finished.

Nevertheless, I can envision a scenario where an office worker answers a call from someone pretending to be from tech support (do you know all your IT guys by name?), who tells them that their computer is not showing up in some report, and needs them to run a fix remotely to correct the issue. They start a Bomgar or LogMeIn session, five minutes goes by, and voila, system compromised with malicious MDM profile. That is why Apple created UAMDM, and now thanks to JerBecause's script, Apple will likely patch this workaround as well. The fastest way to kill it is by removing the Accessibility hooks within the Profiles pane only. If you're physically handicapped to the point that you can't use a mouse, but need MDM, let's face it—someone is going to have to help you with this part.

Fun fact: if you press Opt-Shift-K, instead of pasting the "apple" logo, it gets replaced with the command symbol . The embedded Proxima Nova font has the "Command" symbol mapped to Unicode U+F8FF, which is the "Private Use Area" that normally contains the Apple logo. You can see this for yourself by loading Font Book > 2 (Repertoire) > scrolling to the bottom. Many fonts include the Apple logo in their repertoire. Additional reading: FileFormat.info, Wikipedia, SuperUser, Harvard

[ThijsX]

Cool, great post! any installers already available?

[bradtchapman]

@txhaflaire : Yes. Jamf Pro 10.3 was posted yesterday, and macOS 10.13.4 was released today as well.

The standalone package hasn't hit the main Apple downloads site (you can search for packages named 'High Sierra', though!), but it is available in the Mac App Store right now.

[ThijsX]

@bradtchapman

Cool, Thanks! need the .pkg installers for deployment via Self Service, something with bandwith struggles and couple of hundred devices.

[RobertHammen]

@txhaflaire No direct download links yet, but if you want to poke around, there is always SUS Inspector

[dan-snelson]

Thanks, @RobertHammen.

[dpertschi]

@RobertHammen I've got bookmarks, snippets, clippings, screenshots and illegible written notes on all of that littered all over the place. Thanks for organizing it!

32-bit app warning - profile to suppress? Do tell, what's the syntax?

[mm2270]

Thanks for the post @RobertHammen Very informative.
One question I'm trying to find an answer on. Do the new SecurityUpdate2018-002 patches for El Cap and Sierra require that the previous SecurityUpdate2018-001 patches have been applied first on those respective OSes, or does this new one supersede that update? It may not be that important, but I still have some machines pending check-in in our fleet to run the previous patches, and I'm wondering if I should replace the update being pushed with this new version and it will just work, or if it will fail because the previous update wasn't applied.

I'll probably set up a test machine to run this on to see, but was just wondering if anyone knew or figured this out already.

[RobertHammen]

@mm2270 Security Updates are typically cumulative - meaning it's OK to skip -001 as long as you get -002. I haven't actually compared the package sizes, but usually the updates get larger as the year goes on...

[RobertHammen]

@dpertschi Of course, the prolific @rtrouton has a profile to disable the 32-bit application warning in his GitHub repo

Error looks something like this:

[McAwesome]

I'm testing this on some lab machines that are AD bound. I got the attached pop up on one account, but only on one account. I'm using a mix of previously signed in and new to this machine accounts. I see above that this issue is known, but since it's intermittent I can't figure out how much of an impact it will have for us. Anyone have more information on what triggers this?

[donmontalvo]

@McAwesome This came up during Beta testing, search developer.apple.com for lots of heat on this. Apparently the fix didn't get added, where LDAP users would automagically get their SecurityToken? FWIW can you confirm you're on the public release though?

[McAwesome]

@donmontalvo Confirmed, from official released 10.13.3 updated through the App Store to 10.13.4.

[RobertHammen]

This is indeed the "poor user experience" referred to in my original post. Please open an AppleCare Enterprise case, or file a radar on this, if you find this behavior to be problematic. To me, it's the replacement for the old "Keychain password" dialog that confounds users.

[McAwesome]

@RobertHammen I've contacted our org's Apple rep and he's forwarding the issue.

[ThijsX]

There they are!

Download macOS High Sierra 10.13.4 Update -> https://support.apple.com/kb/DL1962?viewlocale=en_AU&locale=en_AU
Download macOS High Sierra 10.13.4 Combo Update -> https://support.apple.com/kb/DL1959?viewlocale=en_AU&locale=en_AU

[RobertHammen]

10.13.4 Combo Update
10.13.4 Update (from 10.13.3)
Security Update 2018-002 (Sierra)
Security Update 2018-002 (El Capitan)

[znilsson]

• Mac on 10.13.3 has one MDM profile, should have 5 from Jamf
• user upgrades to 10.13.4, still only the one MDM profile
• No apparent way to fix this problem, because we can't delete the ConfigurationProfiles folder, profiles won't push down from Jamf, and there's no other way to force it.

Wat do?

[aaronpolley]

@znilsson do any of these help?

sudo jamf reenroll
sudo jamf removeMdmProfile
sudo jamf mdm

If the MDM profile is there fine but you're just not getting config profiles, see what the inventory record says under History/Management. See whats scoped and why it failing

[McAwesome]

@znilsson I've seen on some test machines that the MDM profile has to be manually accepted before it'll start working again even on machines that, according to Apple, shouldn't need any action taken. Have you approved those?

[Look]

You had me at --eraseinstall

[znilsson]

@aaronpolley Unfortunately my user has been off network for a couple days so unable to test. I reenrolled manually using a QuickAdd, didn't fix it. I ran sudo jamf mdm, that didn't do anything. My next attempt will definitely be to try removeMdmProfile, I have to wait until he's back on network first is all.

Unfortunately the inventory record doesn't help. I can see all my profiles are scoped, and the inventory just says they aren't there. No explanation, they just aren't there. One clue is that the record in jamf says MDM capability: No, meaning Jamf doesn't think this Mac is MDM capable, despite the Mac having the Jamf MDM profile on it. And @McAwesome, I checked, there is no option to allow it from the user side, it's already valid and doesn't require any further approval.

It's a pretty crap situation.

[mtward]

@znilsson

If you have SSH on:

First:

sudo jamf removeFramework

Next: Re-Enroll w/ QuickAdd or Recon.app remote enrollment

That should do the trick.

EDIT: Great OP @RobertHammen

[Jconary82]

Just wanted to add that after a quick add you need to approve the profile in system preferences.

1: Choose Apple menu > System Preferences, then click Profiles.
2: Select your enrollment profile that has a badge: .
3: Click the Approve button on the right, then follow the onscreen instructions.

But the SecureToken prompt still comes up when new users enroll. When bypassed the login time is extremely long on my test mac.