New 8-Core 2019 MacBook Pro. 13″ & 15″ Touch Bar Models are new.
Apple in a surprise launch ahead of WWDC19, releases new 2019 MacBook Pros with a new revised keyboard design. Apple also expanded the Keyboard Service Program to add the 2018 MacBook Pro & Air.
In a move, most did not see coming a new 2019 MacBook Pros were released today. The big news is how the MacBook Pro is getting an 8-Core CPU for the first time. The real news you want to know about probably involves the keyboard. Was it redesigned? Has the mechanism changed? We know one answer was confirmed by Apple though TheLoop.
Another change in the newest MacBook Pro computers is with the keyboard. While Apple says the vast majority of its customers are happy with the keyboard, they do take customer complaints seriously, and work to fix any issues.
To address the problem, Apple said they changed the material in the keyboard’s butterfly mechanism that should substantially reduce issues that some users have seen.
Apple also told me that any problems with the butterfly keyboard on any of its MacBook Pros would be covered at no cost to the customer. The company has also taken steps to improve the repair process, shortening the time it takes to make repairs to the keyboards.
John Gruber @daringfireball.net dug in further when he spoke with Apple.
First, these new MacBook Pros still have the third-generation butterfly-switch keyboard that debuted with last July’s updated MacBook Pros. But Apple has changed the mechanism under the hood, using a new material for at least one of the components in these switches. The purpose of this change is specifically to increase the reliability of the keyboards. Apple emphasized to me their usual line that the “vast majority” of users have no problem with these keyboards, but they acknowledge that some users do and they take it very seriously.
2017 MacBook Pros with 3rd Gen Keyboard can get new revised replacement.
From the Verge
According to The Verge, some existing MacBook Air and MacBook Pro models that experience keyboard failures will have their keyboards replaced with the new 2019 keyboard that Apple has developed. Unfortunately, only MacBooks with the third-generation butterfly keyboard can get the updated 2019 keyboard, which includes the 2018 MacBook Pro and the 2018 MacBook Air.
Testing the new 2019 MacBook Pro.
I will try to get my hands on one of these new 2019 MacBook Pros as soon as possible. Looks like the earliest they can be had is Thursday May 23rd.
Forked version of macOS Mojave 10.14 ?
You can almost bet 100% that the new 2019 MacBook Pros will have a forked build of 10.14 on it. Checking Apple’s catalog nothing has shown up yet. I will update when I have more info.
If you have any questions, please don’t hesitate to Contact Me.
Security researchers have found a new series of vulnerabilities in Intel chips dating back to 2011.
We now know why Apple released the 10.14.5 Combo update and the 2013-003 security updates early. Keeping with Apple’s normal release schedule, Combo and Security updates should have been released 2-3 weeks from now. The updates were released one day before news of the ZombieLoad New Intel Chip Vulnerability hit. This is great news, especially if you remember Apple’s response to the Meltdown & Spectre vulnerabilities. We had to push Apple to release fixes for 10.12 and 10.11 after the news hit.
NOTE: clarifying the situation.
The Mojave 10.14.5 update does the following
1. Updates Safari to version 12.1.1. “This update prevents exploitation of these vulnerabilities via JavaScript or as a result of navigating to a malicious website in Safari.“
2. Enables the ability for you to enable full mitigation by Disabling Hyper-Threading (instructions listed below)
The 10.12 and 10.13 (2019-003) security update only does the following.
Enables the ability for you to enable full mitigation by Disabling Hyper-Threading (instructions listed below)
Safari 12.1.1 is a separate install for both 10.12 and 10.13. I can’t find any documentation that confirms Apple patched this for 10.13 & 10.12 Safari. This will be the page to watch to see if Apple adds more information later. support.apple.com/en-us/HT210123
All Macs from 2011 & forward are vulnerable to this new attack.
You can read about this from multiple news sites below. We have to worry about both Speculative Execution Vulnerabilities and Microarchitectural Data Sampling (MDS) vulnerabilities.
Do I need disable Hyper-Threading as mentioned in the above documents?
Almost all PC Vendors say YES, but Intel says NO. According to Apple “There are no known exploits affecting customers at the time”. The 10.14.5 combo update only covers updates to Safari (12.1.1) only. We will have to wait to see if this was addressed in the High Sierra and Sierra versions of 12.1.1. If you need full mitigation for the Mac you will need to disable Hyper-Threading.
Disabling Hyper-Threading
Let’s take a look at the instructions Apple gave us.
Step 1
Turn on or restart your Mac and immediately press and hold Command (⌘)-R or one of the other macOS Recovery key combinations on your keyboard.
oh no… If you are a MacAdmin you just realized this solution is not deployable by any means.
Step 2
From the Utilities menu in the menu bar, choose Terminal.
If you have a deployed T2 Mac with only one FV2 enabled standard user you will be out of luck. You can’t open terminal without a SecureToken Admin.
Step 3
Type the following two commands, one at a time, at the Terminal prompt. Press Return after each one.
nvram boot-args="cwae=2"
nvram SMTDisable=%01
Note #1 According to Apple you need to be on 10.14.5 or have 2019-003 installed on a 10.13 or 10.12 Mac for this to work.
Note #2 Apple mentions that disabling Hyper-Threading could “cause a 40 percent reduction in performance with tests that include multithreaded workloads and public benchmarks”.
Let’s boot to recovery and try this out.
After typing in both commands you can check to see if they are set in nvram by typing in
nvram -xp
This will print out all the variables in nvram. You will be looking for 2 entries.
<key>boot-args</key>
<string>cwae=2</string>
<key>SMTDisable</key>
<data>
AQ==
</data>
If you see these the settings should be in play. All you need to do is restart to enable the new settings.
Note: I tried this out on a system that did NOT have the 2019-003 security update on it and the commands did work. The system booted and was acting normal. It is possible that without the security update installed the system does not understand the values. When I checked for the Hyper-Threading Technology field in System Information it did not exist. I DO NOT RECOMMEND YOU DO THIS! I just tested this out so you know what happens.
Confirm the settings worked and Hyper-Threading is disabled.
Click the Apple menu click “About this Mac” then System Information. Under hardware you should see this.
Hyper-Threading Technology: Disabled
How to revert back and enable HT again.
If you would like to revert the mitigation and reenable Hyper-Threading, reset NVRAM and restart your Mac. To reset the NVRAM remember you need to disable Firmware Password Protection.
GeekBench 4 Benchmark test
Figured it would be fun to run one test to see the performance hit when Hyper-Threading is disabled.
Again this is only one testbut sure seems far away from the 40% number.
Apple also notes the following
“If you previously set custom boot-args, you will need to add those boot-args to the nvram command.“
Note: The full mitigation is not enabled while using Boot Camp to run Windows on a Mac.
Disclaimer
As always when it comes to security, please be sure to test test test and follow Apple’s direct linked documentation if you need to enable security settings in a secure production environment.
Contact Me if you have anything to add to this Speculative Execution & ZombieLoad MDS Intel Chip Vulnerability article.
When sending the InstalledApplicationList MDM command to macOS clients, apps that had been installed via VPP would fail to report when an app update was available.
When using the Time Server payload on earlier version of macOS 10.14, the time zone was not getting set properly.
The Accessibility Events switch was removed, because related aspects of the W3C AOM effort are no longer applicable.
10.14.5 Standard Update Notes
Adds AirPlay 2 support for sharing videos, photos, music and more from your Mac directly to your AirPlay 2-enabled smart TV
[C and US English only] Adds the ability to follow a magazine from the Apple News+ catalog browsing view
[J only] Includes support for the Reiwa (令和) era of the Japanese calendar
Improves audio latency on MacBook Pro models introduced in 2018
Fixes an issue that prevented certain very large OmniOutliner and OmniPlan documents from rendering properly
Other New Updates Released
iTunes Device Support Update – 108.3mb – MobileDeviceSU- 041-62886
Gatekeeper Config Data – v166 – 3.5mb – 041-56834
10.13 High Sierra
10.13.6 High Sierra Security Update 2019-003 – New BuildVersion – (17G7024) Size 1.9gb
If you are here for the 10.15.1 issue, you can follow the same 10.14.4 workaround instructions below.
UPDATE: 07/31/19
This will probably be the final update. Sadly the issue is NOT fixed in 10.146. Even worse, this will be the final update and the issue will not be fixed in Mojave. I submitted this issue right after it was found in 10.14.4 and it’s just a bummer that this will never be fixed in Mojave. The only good news I can give you is that this is fixed in macOS Catalina 10.15.
UPDATE: 07/09/19
The AD Mobile Account option to “Update Keychain Password” when resting your password outside the Mac is still broken in macOS Mojave 10.14.5. This issue is still not fixed in current 10.14.6 Beta! Be sure to contact Apple if you haven’t already done so!
10.14.4 Update password fixes/problems
I really like the 10.14.4 update, trust me I do! It arrived with so many fixes that have really helped MacAdmins. The problem is, it also broke a few things. Just when I thought we found all the fixes/problems a new one pops up. If you have been following along, this is now my 4th article on password fixes/problems in the 10.14.4 update. Lets quickly review
10.14.4 Update breaks “Update Keychain Password” process for Ad Mobile Accounts.
This issue affects Active Directory Mobile Account users. If you use Mobile Accounts you have seen this message before.
Which option should I pick? In 10.14.4 it doesn’t matter they both create a new keychain!
You will only see this message if you change your Active Directory Password outside the Mac. An example of this would be if you changed your AD password on a 2nd Mac, Windows PC or Web Portal. Logging in with the new password will sync that new password down to the Macs local cache but can NOT change the keychain password without the OLD password. You can click “Create New Keychain” and brand new login keychain will be created. But what if you have Xcode Developer Certs and Private keys or Wifi certs? In this case you need your old keychain intact.
Clicking “Update Keychain Password” just creates a new login keychain.
If you click “Update Keychain Password” you should see this. (10.14.0-10.14.3)
What you should see in 10.14.0-10.14.3
Instead, after clicking the update button you will not see this message and you are now at the desktop. If you open up keychain access you will see that your login keychain was wiped out.
Workaround – Find renamed keychain, change password and restore.
Good news, I have a workaround for you. The old login Kkeychain luckily still remains in ~/Library/Keychains
We will have to perform a few steps to restore your old login keychain
1. Find renamed keychain – located in ~/Library/Keychains and called login_renamed_1.keychain-db
2. Change password of login_renamed_1.keychain-db from old to new
3. Remove login.keychain-db
4. Rename login_renamed_1.keychain-db to login.keychain-db
5. Restore login.keychain-db to Keychain Access.app
6. Log out and back in.
1. Find renamed keychain
The old keychain is located in ~/Library/Keychains and called login_renamed_1.keychain-db
Your old login keychain and the new one that was just created.
2. Change login_renamed_1.keychain-db password
You used to be able to change the login keychain password through Keychain Access. This is no longer possible.
What if we clicked “Add Keychain” and tried to add the renamed keychain then try to change the password?
This looks promising but after clicking “change password for keychain login_renamed” nothing happens. I then tried to unlock it with the old password.
After unlocking I attempted to change the password again.
Still no go! After clicking change password nothing happened. At this point, I thought I was out of luck.
Enter CLI command security
Never give up a fight without visiting the Command Line Interface! The CLI can be your best friend. Let’s take a look at the security man page and see if anything will help us. Open terminal and type in man security
set-keychain-password Set password for a keychain.
Oh ya, now we are talking! Let’s take a look at the options.
Perfect, just what we are looking for. Lets try it out.
You will be prompted for your old and new password. Now that the old keychain has the same password as your AD account we can move it back into Keychain Access.app.
3. Remove login.keychain-db
Now we can just delete the empty login keychain.
Right click on login and select Delete Keychain “Login” then click “Delete References & Files”. You should now only have Local Items, System and System Roots.
4. Rename login_renamed_1.keychain-db to login.keychain-db
We now need to rename login_renamed_1.keychain-db to login.keychain-db. You can either do this in keychain access or in the finder. Let’s rename in the finder. Click once on login_renamed_1.keychain-db and change it to login.keychain-db.
5. Restore login.keychain-db to Keychain Access.app
Now all we need to do is add our old keychain back to Keychain Access.app. Right click in the keychain section and select “Add Keychain”.
Navigate to ~/Library/Keychains/login.keychain-db and select it. You will now see login in the keychain box! At this time it will be locked. You can test unlocking it now. Right click on login and select “Unlock Keychain login”
You will now be prompted to enter in your current password.
6. Log out and back in to confirm
You have now restored your old keychain. Log out and then back in to confirm. You are now good to go!
As always, we need to submit a bug report to Apple.
I can not stress how important this is. The more reports we put in the higher priority the issue gets. We are also running out time and only have about 3 weeks before 10.14.5 is released.
Thanks to hawkzhang45 from JAMF Nation forum for calling this issue out. Also to m.entholzner for conformation and submitting an Apple Enterprise Ticket. You can read the original thread here.
We have been waiting for SecureToken Documentation since 10.13 Beta 1 and the introduction of APFS. I go into this in my previous article 3 Undocumented macOS Mojave 10.14 Enterprise Fixes. I talk about what SecureToken is and how we need SecureToken Documentation. The sysadminctl binary still doesn’t have a man page. You will see why, once you read on how Apple recommends that you use fdesetup instead of sysadminctl.
sysadminctl’s only documentation.
Documentation Please!
Many MacAdmins have called on Apple to give us some information explaining how the system works. Since 10.13 Beta 1 we have been left to fumble around and figure all this out on our own. The other problem was, that from 10.13.0 to 10.14.4 the system had many bugs and has even changed many times. It was really hard to keep up much less understand what was going on.
Enter macOS Deployment Reference “Use of SecureToken”
Now that we have the document, what does it say? Does it shed any light on the situation? In a word no… but it finally puts everything into words for new MacAdmins. Most of the information posted was already known and hashed out by experienced MacAdmins who have spent hours testing SecureToken. We will be able to share this document when anyone has questions about how SecureToken works.
Any key takeaways from the document?
1. If local user account creation in the macOS Setup Assistant is skipped using MDM and a directory service with mobile accounts is used instead, the directory user won’t be granted SecureToken when logging in to the Mac.
This statement is a little confusing yet could also be true depending on your setup. For example you can use MDM/DEP with the setting “Skip Account Creation” then bind to a directory service with a policy to enable FV2 on login. In this situation the management account/admin user is not granted a SecureToken. The first directory user to login will get a SecureToken by enabling FV2 . This is the perfect scenario, as you don’t need a tech waiting around to enter in the admin username and password for the first user logging in.
Editor’s Note: for the above situation. If you do not have a policy to enable FV2 on login the mobile account will not get a SecureToken. I never tested out this scenario. Big thanks for the clarification from TravellingTechGuy who put together a really nice SecureToken flow chart. You can find that chart here.
2. “Important: In macOS 10.13.5 or later when using a directory service and mobile accounts, users won’t be prompted about SecureToken during first login if there are no SecureToken accounts already available on the Mac. See below for additional information.”
In 10.13.3-10.13.4 directory users were prompted with this message even if the first user was logging in. You had to hit bypass to get that first login SecureToken. Now as this message states, if you logged in as the first user you are not prompted. The document also goes over how you can disable this pop up.
Seeing this note reminds me of an additional change to the SecureToken Pop up message in 10.14.4. When you log in the SecureToken message will not come up if the SecureToken account already on the system is not an admin. The point of this change is that the SecureToken user has to be an admin to enable the new user logging in. If the standard SecureToken user is not an admin don’t even bother to show the message because you would be unable to add the new user to FileVault anyway.
3. ” Managing which users can unlock a FileVault encrypted volume should generally be done using the command-line tool fdesetup. However, you can use the command-line tool sysadminctl specifically to modify SecureToken status for user accounts on the Mac. This should be done with caution and only when necessary.“
It’s interesting how Apple actually recommends using fdesetup instead of sysadminctl. The reason I say that is that we all use sysadminctl to create accounts and mange SecureToken.
The problem with using fdesetup to add an additional user to FileVault is, the account does not show the securetoken as enabled. Instead you should really should use diskutil apfs listCryptoUsers / or sudo fdesetup list -extended to get a proper list of enabled CryptoUsers. I am just pointing out that we are still having non consistent results when checking the FV2 status of a user when using sysadminctl.
You can try this yourself in 10.13.6 (17G6029) & 10.14.4 (18E226)
sysadminctl Secure token is DISABLED for user mrmacintosh
You can still unlock the volume in this condition and will report properly using the above command diskutil apfs listCryptoUsers / or sudo fdesetup list -extended.
Conclusion
In this article I point out a few things that still need some work. With that said, this document is a move by Apple to give us the needed documentation that we have asked for. We are also seeing more information in beta patch notes and Enterprise Content when a combo update is released. I hope this trend continues!
Apple Link to Device And Data Security Use of SecureToken.
I have been thinking for a while now of creating a one-stop-shop for macOS System Status & Version Info. The idea behind this is a page you can visit that has the latest information, from what’s broke in the latest macOS release to what forked build number the new 2019 iMac has. This page will follow the general idea of Apple’s System Status Page but include a lot more information.
I have received some really great feedback on my Updated List of Notarization Links page and how it has helped many MacAdmins. This page will be an extension on that. With the amount of work we are all dealing with, it’s very difficult to keep up. I can’t tell you how many times I have spent hours troubleshooting an issue only to find out that it was a known problem. If this page can save you that lost time it will be worth the effort!
Table of Contents
Mojave Core System Status
This section will cover critical core macOS system functions. If something major is not working, it will be listed here. Most of the system functions listed are very important to MacAdmins. I verify each section myself and also include reports from other sources. NOTE: Be sure to verify in your own lab, I am providing a “best effort”service.
macOS System Updates/Versions
In the 2nd section, I will list the current Mojave Installer and the current Beta. Forked installers will also be listed. (A forked macOS installer is a special app installer that is only used for a new Mac Hardware releases). BridgeOS and built-in security versions (Malware Removal Tool, XProtect, Gatekeeper) are also listed.
Core Application updates/versions
In the final section, I included a list of core macOS Applications. The table contains size of the update, release date and patch notes.
Improvements ?
Should I add other sections? Add older OS’s like High Sierra or Sierra? What about including issues in previous Mojave Point releases? Could the layout be better? Let me know.
When Apple announces a new security feature on macOS it takes time to get a handle on how it will affect your deployment workflow. Most likely you are busy streamlining the last change! You end up searching google for links so you can get up to speed as soon as possible. This time around I will attempt to make this easier on you. I will be collecting the most important Notarization links and will add them to this article. Some of the links I will be posting will be from Apple, MacAdmins, 3rd Party Vendors and Security Researchers. A lot of hard work and research was put into some of the articles below. Let’s get started!
Give users even more confidence in your software by submitting it to Apple to be notarized. The service automatically scans your Developer ID-signed software and performs security checks.
2nd Bulletin – April 10th 2019 – We’re working with developers to create a safer Mac user experience through a process where all software, whether distributed on the App Store or outside of it, is signed or notarized by Apple.
Transporter is Apple’s Java-based command-line tool for large catalog deliveries. You can use Transporter to deliver your pre-generated content, in a Store Package, to the iTunes Store, Apple Books, and App Store.
Updated Notarization Requirements 09/03/19 until January 2020
Sophos.com– Advanced Endpoint Protection with EDR and Artificial Intelligence, Next Gen Firewall with Synchronized Security and Business-Grade Security for Home Users.
If you use Active Directory Mobile Accounts with FileVault, password sync problems will be very familiar to you. I have good news, MacOS Mojave 10.14.4-10.14.6 can now sync AD Mobile Account password changes to FileVault when you don’t know the AD password. Apple added this new feature to macOS 10.14.4 for Mobile Accounts. In previous releases, you needed the old password to sync the password down to FileVault. Local Accounts has had this ability for years. Rich Trouton put together a great article on Resetting and Syncing FV2 Local account passwords. He mentions the methods are only for Local Accounts, NOT Mobile Accounts.
You forgot your AD password on 10.13.0-10.14.3
Users who fall into this situation are in a pinch and options to get the system to sync the new password to FileVault are limited. You could boot the system up using the PRK (Personal Recovery Key) and then have the Help Desk reset the AD password. This would get you into the system but your FV2 password would never sync. You will be forced to continue to unlock the Mac with the PRK (Personal Recovery Key), then login with the new AD password.
The only way to fix this was to have a SecureToken Admin on the system.
Do you have an admin support account that is FileVault/SecureToken enabled? Listed below are two methods to fix out of sync passwords.
1. fdesetup remove / re-add user
sudo fdesetup remove user userwhoforgotpass.
Then re-add the user by running
sudo fdesetup add user localadminuser -usertoadd userwhoforgotpass
What this would do is remove the user from the enabled FileVault user list, then add them back. The sync would happen when you are prompted for the new password when re-enabling the account for FileVault unlock.
2. Sysadminctl -secureTokenOff/On
You can also use sysadminctl. Start by turning off SecureToken and then turn it back on.
The process of turning off SecureToken and then turning it back on will sync the password. Also note that you don’t have to run sysadminctl with sudo.
Problem is, some companies don’t want a FileVault enabled admin account on the system.
NOTE: diskutil apfs updatePreboot / – Does NOT sync the password!
Running diskutil apfs updatePreboot / does NOT sync the password from the OS to FileVault. If this worked in the past, it was only a coincidence. If you changed your AD password outside the Mac, password syncing to FileVault would sometimes take 2-3 restarts. This command is only really needed when you wanted to add a new FileVault user to the system. Running this command would then add the new user to the FileVault pre-boot window. You only had to run this command in 10.13. This was actually a bug and was fixed in 10.14. The new account will now automatically show up at the FV2 pre-boot window after creation.
Reading the third line, it does seem to match our situation. If you forgot your AD password, you would have to continually unlock the Mac with the PRK. You would be forced to do this each time you turned on your Mac or restarted. Notice the wording, it does not say “Fixes”.
How to reset your AD mobile account password and have it sync to FileVault, when you don’t know the previous password.
You need to meet all of the following pre requisites.
macOS Mojave 10.14.4 or newer.
Active connection to Active Directory.
Access to the PRK (Personal Recovery Key)
You have the ability to change your password outside the Mac (2nd Mac, Windows PC, or Web Portal). Or the Help Desk can reset and issue you a temporary password which you can then use to set a new password at the loginwindow.
Since you don’t know the previous password you can’t even get past the FileVault Unlock Screen. You will need access to the PRK. Click the user who needs their password reset. In the password line, you will now see a ? button. Click on it, you can now type in the Personal Recovery Key. Try this neat trick to get the Macs serial number. Click the ? a second time.
Pretty neat trick so users can tell the Help Desk the Macs serial number. (Key Escrow or MDM required).
After booting the system with the Personal Recovery Key the process will stop at the login window. On 10.13.0-10.14.3 systems you are prompted to reset the password at the login window.
Mobile Account Password reset pop-up for 10.13.0-10.14.3 systems after booting with the PRK.
This feature is for Local Accounts Only. To change your AD Mobile Account password from the Mac you must give Active Directory the OLD password. You can only do this with System Preferences > Users & Groups > “Change Password” or dscl. As you can see above the interface does not have a box for Old Password.
10.14.4 will now show a new pop up for Mobile Accounts after booting with the PRK.
This is the new 10.14.4 Mobile Account password reset message, but you still can’t reset the AD password here.
The Mac now realizes that you are trying to reset a Mobile Account Password. You will no longer see the Reset Password pop up. This is because AD requires that you enter in the OLD password. Since you don’t know it, you will not be able to reset your password. This is why macOS will not show you the password reset window anymore for mobile accounts. If you use the PRK from a Local Account you will get password reset window with password fields like you would normally expect.
Step 2. Reset the AD Password.
As noted above you for this to work you can reset your AD password one of two ways.
Call the Help Desk and have them reset the password and then issue you a temporary password.
Reset the password on a 2nd Mac, Windows PC, Web Portal etc.
Either way will work for the password change system to work.
If you called the Help Desk and had them reset your AD Password they can now give you a temporary password. Your account will be flagged “Password must be changed on next login“. Enter in your username and then type in the temporary password. Hit enter and you will now get a new pop up window.
Enter in your new password. Click Reset Password when ready. You will be greeted with the login keychain message. You will receive this message anytime you change the password outside the Mac. Click “Create New Keychain” and the Mac will continue to login.
Step 3. Restart to complete the FileVault sync.
You will need to restart at least one more time to complete the sync process.
On this next restart you will need to enter in the PRK ONE MORE TIME.
NOTE: I am still trying to figure out if having to use the PRK twice is a bug or not. I think it is because you don’t have to do this extra step with local accounts.
After you perform one last PRK boot, enter in the username and new password and you will be at the desktop once again. The process is now complete, you can restart to confirm. Use your new AD password to unlock the volume and the system will now auto boot you to the desktop.
Conclusion
This is my 3rd article on password fixes/improvements/problems in 10.14.4
MacAdmins who use Active Directory Mobile Accounts want a working password change system that functions seamlessly with FileVault. Now that we have a working native AD Plugin, will this stop the mass exodus to Local Accounts? Only time will tell.
Today Apple released a new BuildVersion of macOS Mojave, 10.14.4 (18E227). The previous build version was 10.14.4 (18E226). The last time a new BuildVersion was released like this with no documented changes was macOS High Sierra. The BuildVersion went from (17G65) to (17G66).
18E227 6.52GB
If you look at 18E226 we do have a size difference.
18E226 6.53gb
The size difference between the 2 updates is very small but still different. Opening up both installers in Suspicious Package.app I looked inside InstallESD.dmg. Inside was the Core.pkg. I compared 18E266 to 18E227 and they both have 460,632 files installing 12.63GB to the system.
This is only for the full “Install macOS Mojave.app” installer. This is not an combo update or security update.
You do not have to replace 18E226 with 18E227. If you are preparing for upgrades and already cached 18E226 to your Macs, you dont have to re-cache 18E227. As far as we know this is only a re-write of the original 10.14.4 (18E226) installer. 18E226 is no longer available for download.
BridgeOSUpdate also released
Apple also re-released the BridgeOSUpdateCustomer with the Product ID 041-56509.
BridgeOSUpdate Product ID 041-56509
The previous BridgeOSUpdate 041-49224 was only a few bytes smaller. As of April 18th 2019 the current T2 BridgeOS/iBridge version is 16.16.4507.0.0,0
10.14.4 Update breaks local account password reset when using FileVault Recovery Key.
UPDATE: 05/16/19 – 10.14.5 Update fixes this issue
The macOS 10.14.5 update fixes this issue.
As noted above this issue is now fixed in macOS 10.14.5. You can read on if you are interested in how this all went down.
I have been testing the new password fixes/changes in macOS Mojave 10.14.4. You can see the changes in the “What’s new in the updates for macOS Mojave” support document. What I found was, the 10.14.4 Update breaks local account password reset when using the FileVault Recovery Key.
Enterprise Content section from the what’s new in 10.14.4 update document.
I wrote about how Apple fixed mobile password syncing issues on how 10.14.4 fixes Mobile Account Password syncing issues in 10.14.0-10.14.3. This was a huge win for Active Directory Users. We finally have a functioning password change system in place. I found this problem while testing these new fixes. Instructions for this procedure are listed in this Apple Support Document.
Let’s confirm this on 10.14.3 and 10.14.4
I setup a fresh 10.14.4 (18E226) system, created a local account and then enabled FileVault. I then performed the following test.
Boot system – Select user
Click the ? Button so I can enter the recovery key.
The system will now boot to the login window
You will see the username filled in with your username with the password reset window.
Type in a brand new password and then hit “Reset Password”
The window thinks for a second then shakes you off.
The password is not changed.
Reset password window after entering in the recovery key.
Performing the same test on 10.14.3 (18D109) worked as designed. After clicking “Reset Password” the system accepts the new password then logs you in.
Workaround: resetpassword in Recovery
Good thing is, the resetpassword application in the recovery partition still works.
Trusty ole resetpassword still works.
1st way to reset your password. Boot to Recovery
Boot your Mac holding Command R to boot the Mac into the Recovery Partition. Once in click Utilities from the Menu Bar then select Terminal. Once in type in resetpassword, then follow the instructions.
Note: If you have a T2 Mac, this option requires that you have a SecureToken Admin on the system to access the Terminal.app.
2nd way to reset your password, the FV2 Screen.
You can trigger the 2nd way at the FV2 login window.
Wait up to a minute at the login screen, until you see a message saying that you can use the power button on your Mac to shut down and start up again in Recovery OS. If you don’t see this message, FileVault isn’t on.
Press and hold the power button until your Mac turns off.
Press the power button again to turn on your Mac.
When the Reset Password window appears, follow the onscreen instructions to create a new password.
If you would like to follow Apple’s instructions on how to reset local account passwords you can visit this Apple Support Article.
“Radar or it didn’t happen”
This was a really great quote from Jason Broccardo @zoocoup. Filing bugs and tickets is a really important task for MacAdmins. Apple rates issues by the number of reports/tickets they get for each issue. If this feature is important to you please do the following.
Then open up an Open Radar on openradar.appspot.com. This will help with tracking and you can let others know about the issue. (This site is not affiliated with Apple Inc.)
