10.12 Sierra Archives - Page 2 of 2

3 Undocumented macOS Mojave 10.14 Enterprise Fixes

In this article, I will talk a little bit about the current state of Apple’s Documentation. After that, I will show you 3 Undocumented 10.14 Mojave fixes that can help you as a MacAdmin.

Documentation, Documentation, and Documentation. Say it three times fast! MacAdmins just want Apple to provide proper documentation for features, controls and security settings and Enterprise Fixes. In some cases, Apple provides excellent documentation. An example of this would be the T2 Security Chip Security Overview released in October of last year. In other cases when it comes to binaries like sysadminctl not so much.

I tried to searching for something that specifically mentions SecureToken or sysadminctl and came up empty.

The best that I could find was a document called “If you see authentication server errors when turning FileVault on in macOS High Sierra“. This article does not even mention SecureToken. You can get a few nuggets of information by checking the sysadminctl binary options but sysadminctl doesn’t have a man page. I even performed a search on developer.apple.com/documentation as you can see in the picture above. I will be writing about sysadminctl next week. Maybe I can create a MacAdmins version of a sysadmincatl man page! Yet when I search for “SmartCard” three documents show up. SmartCard support is a small piece in the overall macOS pie, yet has multiple documents! Side Note: Shout out to all my peeps in the MacAdmins.slack.com #SmartCard channel (about 5 people) 🙂

Documentation is getting better.

If you have been keeping track, Apple documentation is getting better. If you look at the “What’s new in the updates for macOS Mojave” page you will see a large number of fixes. Eagle eye MacAdmins will be first to spot “Enterprise Content”, this is the stuff MacAdmins are interested in.

10.14.2

10.14.3

10.14.4

Check out that first one under 10.14.4! As noted in my previous article, I fought to get that one fixed since 10.14.0. It’s really great to see that fix get mentioned in the Enterprise Content area.

What do you mean undocumented fixes ?

Apple is constantly fixing things behind the scenes. MacAdmins continue to file radars, call Apple Care, test beta releases, submit feedback and submit Apple Enterprise Support tickets. Defects and bugs ARE getting fixed but are not listed in Apple’s Enterprise Content listing. I am not totally sure why certain fixes do not make the list.

Maybe Apple wants to keep the list short while focusing on the major fixes. I wish Apple would list more of them, even if they posted them in an enterprise only area. An example of this would be AppleSeed for IT. If you are part of an Enterprise or School you can be selected to join the program. I highly recommend joining if you are not a member already. You can read the FAQ about joining eligibility here. Inside you will find links to macOS beta downloads and beta documentation. Each beta release (Sometimes up to 6 releases per combo update) will show what has been fixed between updates. This is great information for any MacAdmin to have so you can stay on top of what’s going on.

3 Apple Enterprise fixes included in 10.14.0 – 10.14.4

1. macOS 10.14 Mojave can now provide FV2 Authenticated Restarts for Combo and startOSinstalls.

In 10.14 macOS Updates and Upgrades are now able to perform Authorized Restarts. This feature was not an option in previous releases. This is a pretty big deal, especially for #MacEDU and Enterprise customers who have computer labs.

Previously if you installed a macOS update and the system was FV2 encrypted it would restart but STOP at the FV2 unlock screen. If you performed this update remotely you would lose control of the machine. Things get worse at FV2 login window because firmware will shut the Mac down after 5 minutes of inactivity. The same problem will happen when you start a macOS Upgrade. You will be disappointed after returning from lunch thinking the update is complete only to find the Mac turned OFF. You then power the Mac back on only to find the installer has just started with 40 minutes remaining. With 10.14 if you kick off a combo update or macOS upgrade the installer will perform an Authorized Restart and you will never get stuck at the FV2 prompt again!

For startosinstall you just have to store the mojave.app in a folder like /Users/Shared. Then kick it off with this command – sudo /Users/Shared/Install\ macOS\ Mojave.app/Contents/Resources/startosinstall –nointeraction The –nointeraction option will prevent license agreement message.

2. Installing software updates using the -R restart option at the login window now properly restarts the Mac to the installer. (10.14.4)

When Apple released the T2 security chip they also added additional options to the softwareudpate binary so it could handle BridgeOS updates. Installing a combo update on a T2 Mac is now a multi-step process. Using softareupdate step one remains unchanged, it will download the combo update from Apple which in turn stores in /Library/Updates. For step two, the Mac reaches out to Apple’s personalization service (gs.apple.com) verify the BridgeOS and combo update. When the verification is complete you will have a new folder in /Library/Updates called PersonalizedManifest.

You are automate the entire process by using sudo softwareupdate -iaR. Options -i will install the update, -a will download all updates and -R will perform an automated restart. The process works just fine if you are the logged in user. If the system needs to update the BridgeOS the Mac will shutdown and then will power back on with the T2 Chip to install the BridgeOS update. If the system does not require a BrigeOS update the system will restart to the update installer. The problem comes in if you try to automate the install from the login window using the softwareupate -R or –restart option. Softwareudpate will run run through the process listed out above only to stop at the very end and be unable to restart.

Looks great until the very end, when at the login window the system will NOT restart!

Once all your Macs are updated to 10.14.4, you can now use the -R restart for all situations. Softwareupdate can now restart the Mac if it’s at loginwindow.

3. 10.14 FV2 Authorized restarts can use the PRK (Personal Recovery Key) again.

When 10.13 arrived you could no longer perform FV2 Authenticated restarts using the PRK (Personal Recovery Key). This feature was just flat out broken. This previously worked in 10.12 Sierra and below. NOTE: You could still perform an Authorized restart with your FV2 name and password. An example of a PRK Authorized restart would be if you are a JAMF Pro customer and had a policy that installed a package but it also required a restart. You could select the option “Perform Authenticated Restart” Jamf would then send a fdesetup authrestart using the PRK. The package would install and then the system would perform an FV2 authorized reboot so the user did not have to enter in the password at the FV2 unlock screen.

10.12, 10.11 & 10.10 – Works!

sudo fdesetup authrestart = Enter a password for ‘/’, or the recovery key:

10.13 – Doesn’t work

sudo fdesetup authrestart = Enter the user name: ( hit the enter key to toggle Recovery Key Entry) = Error: Missing user name. Error: Unable to restart (error = -54).

10.14 – Works again!

sudo fdesetup authrestart = Enter the Username: (again hit the enter key to toggle Recovery Key Entry) Enter the current recovery key:

I hope that at least one of the fixes I mentioned in this article helps you. In the future I would love to see more documented Enterprise fixes listed in the combo update patch notes. Until then though, I will continue to document said fixes and let you know about them when I can.

If you have any questions or comments, please feel free to reach out!

Apple replaces 2019-002 Security Updates for 10.13 and 10.12

10.13 – Updated from 17G6029 to 17G6030 10.12 – Updated from 16G1917 to 16G1918

UPDATE 03/30/19 – Apple just posted a knowledge article on why they updated both security updates.

https://support.apple.com/en-us/HT209635

Two shout-outs in one day for @AnthonyReimer (@jazzace)! He installed the latest High Sierra Security Update and found the build number had changed. I started to look into this and found that both Security Updates for both 10.13. and 10.12 have been replaced with new builds. The original build number for the 10.13 High Sierra 2019-002 was 17G6029. As of 2 pm CST, the new build offered is 17G6030. Checking Sierra, the Build number also changed from 16G1917 to 16G1918. Apple (usually) does not update the .app installer with security update fixes when released so the installer builds remain the same. No word on yet on what was changed in both updates.

Bottom line, if you installed the previous update (17G6029) the new build (17G6030) will show as available. It would be advisable to deploy the updated Security Update.

T2 BridgeOS update

New Apple BridgeOS updates are also listed.

Note: After installing the new (17G6030) Security Update the iBridge version was not updated. iBridge should read 16.16.4507.0.0,0

To examine further I opened up BridgeOSUpdateCustomer.pkg and inside was the version number.

CFBundleVersion
16.16.4507.0.0

SUS Inspector

Check out SUS Inspector, it’s a great tool to view macOS updates.

SUS Inspector GitHub

Suspicious Package Inspector

Also check out Suspicious Package.app to see what is inside macOS updates.

Suspicious Package.app Download site.

10.14.4 update fixes AD Mobile Account/FileVault password change sync

Before we get started I’m am going to talk a little bit about how macOS and Active Directory work together. I will also go into some history behind the built-in AD Connector. In the end, I will explain the current problems we are having with Active Directory Mobile Account password syncing and how Apple fixed the issue.

If your company or school uses Active Directory, you most likely use Mobile Accounts. To get Mobile Accounts to work you first have to bind the Mac to Active Directory, once bound the Mac is now trusted. You can now log in with any Active Directory user and access to Global Groups, Kerberos and Directory Contacts.

Sounds great right? It was!

Once you log in, the system caches your AD account to the local directory. If you then disconnect the Mac from the network you can still log and continue to work. When the time comes to change your AD password you could change it on a 2nd Mac, a Windows device or even a Web Portal.

How did the AD password change work?

If you changed your password on the Mac it would first check if any password requirements are set at the domain level. If you passed the requirements the password would be immediately changed in Active Directory. The password would then change at the local offline level of your Mac. If you changed your password outside the Mac (Web Portal etc..) the system would receive the password change the next time you connected the Mac to the network and logged in. You would then be promoted to Update or create a new Login Keychain.

Active Directory & FileVault 2

The AD password change system changed in 10.7 with the addition of FileVault 2. Now when you changed your password an extra step had to be performed. Once the password was changed in AD it would then change the locally cached password and then had to sync that password down to your FV2 account. When you turned on your Mac, you could then use the same password as your AD account to unlock the volume and start booting the system. The AD password sync system worked pretty well from 10.7 all the way up to 10.12 Sierra. Users would sometimes have issues here and there when the Mac dropped off the domain but usually a rebind and would save the day.

10.13, APFS and SecureToken

Apple introduced the next-generation file system called APFS (Apple File System). We first got to test it out in 10.12 Sierra in beta form. APFS was standard for all SSD drive installations on 10.13 High Sierra installs. You could still opt out with commands and spinning hard drives would still use HFS. When 10.14 arrived APFS was standard across all hard drives. The introduction of APFS brought an added undocumented security feature called SecureToken. If you wanted to enable FileVault 2 you had to have SecureToken enabled for said account. You could no longer you use the PRK (Personal Recovery Key) or even a local admin to add extra users to unlock the volume like you could with HFS. You have to grant the 2nd user a SecureToken before they could become an authorized CryptoUser. To get the token in the first place you had to be the first user logging into macOS at the SetupAssistant.

10.13 was the start of syncing issues for Mobile Accounts.

The main problem with this new system was that the SecureToken system was not tested. Mobile account users, in particular, had nothing but problems with this new system. From 10.13.0-10.13.3 AD Mobile Account password syncing to FV2 flat out did not work. During this time frame we had multiple high priority tickets in with Apple Enterprise Support. When 10.13.4 hit Apple finally fixed the issue and password syncing started to somewhat work again. I say somewhat because everyone still reported issues but at least it worked SOME of the time now. 10.13 still had problems when you changed the password off the Mac.

Enough of the history lesson, get to the 10.14 problem!

Once 10.14 hit we were hoping that the problems we had on 10.13 Mobile Accounts would fixed. Unfortunately, we were wrong, way wrong. The problem worse when 10.14.0 released. How could it be worse than 10.13 and how did miss the problem in 10.14 beta? On 10.13 as I mentioned above we had to deal with of Mobile Account syncing of FV2 passwords. The user would change the password outside the system and it would not make it down to FV2. The good thing is we actually have fix for this!

The following instructions will change or Sync the password for the CryptoUser account that belongs to the AD user. This will only work if the user KNOWS the old password since the command will prompt for the current password.

1. diskutil apfs list (Grab the disk label for Volume Macintosh HD usually disk1s1)
2. sudo fdesetup list -extended (grab the UUID of the OS USER) You can also use diskutil apfs listCryptoUsers /
3. diskutil apfs changePassphrase disk1s1 -user UUIDhere (add in the UUID of the OS USER from the pevious command and put it in UUIDHere.

That’s cool, but you still haven’t told us why is the situation worse in 10.14?

The local cached offline password is never changed!

The problem is the issue is undetectable UNTIL the user attempts to authenticate OFF the network. When they try the current password it will NOT work. They will then have to call the helpdesk, who then changes the AD password making the situation even worse. This is the situation for 10.14.3 and below.

When connected to the network = Current AD Password works!
When Disconnected from the network = ONLY previous password works.
FV2 password = Previous Password.

Things get even more annoying is if the user actually uses the old password to authentiate the Screen Saver while offline. The system will accept the password but then immediately prompt the user to unlock the Login Keychain. This is due to the keychain being set to the current AD password. You would be in a never-ending keychain password cycle.

Do you have a fix for the offline sync issue?

The good news is we do, as long as you have a SecureToken enabled Admin user. All you need to do is turn off SecureToken and then turn it back on. Something in this system will then sync the offline cached password. Shout out to @annemacro on MacAdmins Slack for figuring this out!

sudo sysadminctl -secureTokenOff useraccount -password – -adminUser adminuseraccount -adminPassword –
sudo sysadminctl -secureTokenOn useraccount -password – -adminUser adminuseraccount -adminPassword –

Now that 10.14.4 is out the password sync mechanism now working. As long as you update systems to 10.14.4 before users change their AD password they will not have this issue going forward. I have not had the chance to actually test the 10.14.4 update on a system that is already out of sync. The good news is that even if it doesn’t fix the issue when it is already happening you now have the tools to fix it yourself. The next time the user changes their password they will not experience the issue.

Why did this take so long to fix?

The answer to this question is pretty simple. Everyone missed the bug from beta 1 all the way through into 10.14.0. I performed hours and hours of testing in beta. I was so concerned about that the FV2 password did not sync that I did not even think to test the offline password. Even worse, neither did anyone else including Apple. It was not until around 10.14.2 when I had an enterprise ticket in with Apple and finally got a response.

“This bug will not be fixed until the next release of macOS”

When I read the reply to this support ticket I was in complete shock. Are you going to tell me that we are going to flat out have a NON FUNCTIONING MOBILE ACCOUNT SYSTEM FOR THE ENTIRE 10.14 RELEASE? I could not believe it. The Apple Enterprise Support Engineer I was working with also agreed and he was fantastic to work with and helped work through the issue with me. At this point what else would a #MacAdmin do but RANT in MacAdmins Slack!!! The best way to do this is to document and explain the issue to others. You can then rally other MacAdmins to file Enterprise tickets or Radars. This will draw attention to the issue and generate heat inside Apple Enterprise Support. In the end that’s exactly what happened. We were not the only company that Used Mobile accounts. Those same companies let Apple know that we needed a fix ASAP. Apple realized this was important and fixed this issue for us in 10.14.4. (Thank you Apple!)

Where does that leave Mobile Accounts?

Before 10.13 Mobile Accounts worked very well. We had thousands of Macs connected to AD utilizing Mobile accounts and did not have any issues. Once 10.13 hit things started to go downhill. The problem is, it seems like Apple is not spending enough time on Mobile Accounts. The MacAdmins community has started to realize this and starting at the end of 2017 and into 2018. This began what I call “The great Mobile Account exodus to Local Accounts”. NoMAD and Enterprise Connect make using local accounts while still having the ability to use AD resources easy. Mobile Accounts still serves it’s purpose but it seems the writing is on the wall.

Thanks

If you stuck around to read the entire article I really do appreciate it. If you are at WWDC 2019 or JNUC 2019 I will buy you a beer or non-alcoholic beverage. Just mention coupon code #ISURVIVEDMOBILEACCOUNS.

I hope to write many more articles like this in the future. Over the past 15 years MacAdmins have helped me get to where I am today. I hope I can give back to the community and help the next generation of MacAdmins rise through the ranks! Drop me a note at com gmail mrmacintoshblog

macOS updates released 03/25/19 – 10.14.4 Mojave (18E226) & (2019-002)

Today on 3/25/19 at 5:30 CST Apple released the following updates for 10.14, 10.13 and 10.12.

10.14 Mojave

10.14.4 Mojave Combo Update (for 10.14.0-10.14.3)

10.14.4 Mojave Delta Update (for 10.14.3)

Information on new features and fixes included in the 10.14.4 update

https://support.apple.com/en-us/HT209149

Security information for macOS 10.14.4, 10.13 2019-002 & 10.12 2019-002

https://support.apple.com/en-us/HT209600

10.13 High Sierra

10.13.6 High Sierra Security Update 2019-002

10.12 Sierra

10.12.6 Security Update 2019-002

Safari 12.1

10.13 – Safari12.1HighSierraAuto-12.1 (softwareupdate only)

10.12 – Safari12.1SierraAuto-12.1 (softwareupdate only)

Swift 5 Runtime Support for Command Line Tools

Starting with Xcode 10.2, Swift 5 command line programs you build require the Swift 5 runtime support libraries built into macOS. These libraries are included in the OS starting with macOS Mojave 10.14.4. When running on earlier versions of macOS, this package must be installed to provide the necessary Swift 5 libraries. This package is not necessary for apps with graphical user interfaces.

Swift 5 Runtime Support for Command Line Tools