Blog

10.14.4 Update breaks “Update Keychain Password” + Workaround

MrMacintosh.com - 10.14.4 Update breaks Update Keychain Password
10.14.4 Update breaks Update Keychain Password

UPDATE: 11/17/19

This issue was fixed in 10.15.0, only to break again in 10.15.1! I’m covering the issue again here.

mrmacintosh.com/10-15-1-update-breaks-update-keychain-password-again-workaround/

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.

Update/create keychain message
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)

Update Keychain Password dialog
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.

can't change login keychain password.

What if we clicked “Add Keychain” and tried to add the renamed keychain then try to change the password?

try to change renamed 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.

unlock renamed

After unlocking I attempted to change the password again.

2nd password change attempt

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.

security set-keychain-password

Perfect, just what we are looking for. Lets try it out.

sudo security -v set-keychain-password /path_to_user_keychain

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”.

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”

unlock

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.

I have submitted a bug report to Apple at bugreport.apple.com. I also created an open radar at openradar.appspot.com

https://openradar.appspot.com/radar?id=4962927241068544

Credits

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.

10.14.4 update keychain password

Apple releases long-awaited SecureToken documentation

SecureToken Documentation

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 documentation
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)

sudo fdesetup add -user adminuser -usertoadd mrmacintosh

sudo fdesetup list

adminuser,C26BADFD-6763-093E-8U73-3K13EN938AL3

mrmacintosh,93K18AE6-H187-497C-928F-3K13EN163AL3

sysadminctl -secureTokenStatus mrmacintosh

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.

https://help.apple.com/deployment/macos/#/apd8faa99948

If you are outside the US you can use this link

https://help.apple.com/deployment/macos/?lang=en#/apd8faa99948

Shout out to Rich Trouton ‏@rtrouton for the late night heads up on this.

Also to Neil Martin @neilmartin83 for noticing that the link does not work outside the US!

SecureToken Documentation

Apple releases fifth beta of macOS Mojave 10.14.5 (18F131a) Beta 5

Mr. Macintosh - 10.14.5 (18F131a) Beta 5
macOS beta Feedback Assistant application
10.14.5 (18F131a) Beta 5

Today Apple released macOS Mojave 10.14.5 (18F131a) Beta 5 to Developers and Public Beta Testers.

NOTE: Be sure to check out the note on Known Issues with Notarization in 10.14.5 (18F131a) Beta 5 at the very bottom.

As a MacAdmin it’s important that you take time to test Apple’s Beta Releases. The public beta release notes are very thin on changes for 10.14.5 (18F131a) Beta 5 except for one change at the very end. This may or may not be the last beta before 10.14.5 goes public. 10.14.4 went to Beta 6.

Make sure you’re testing Notarization!

As mentioned in the my previous post on Beta 4, 10.14.5 (18F131a) Beta 5 has all of the Notarization security features enabled. You need to dig in and start testing the new system. The Beta 4 release notes call out that Kernel extensions signed after April 7th, 2019 must be notarized in order to load. Be sure if you have an important 3rd party app that installs a kernel extension that you reach out to the vendor and make sure they are aware of these changes.

10.14.5 (18F131a) Beta 5 Release Notes

Overview

The macOS 10.14.4 SDK provides support for developing apps for Macs running macOS Mojave 10.14.5. The SDK comes bundled with Xcode 10.2.1 available from the Mac App Store. For information on the compatibility requirements for Xcode 10.2.1, see Xcode 10.2.1 Release Notes.

General

  • Copy-protected video content plays back correctly on iMac Pro. (Same as Beta4)

Accessibility

  • Accessibility Events switch was removed, because related aspects of the W3C AOM effort are no longer applicable. (Same as Beta4)

Date and Time

  • Support for the Reiwa (令和) era of the Japanese calendar, which begins on May 1, 2019, is now available. The first year of Japanese-calendar era is represented as “元年” (“Gannen”) instead of “1年”, except in the shorter numeric-style formats which typically also use the narrow era name; for example: “R1/05/01”. (Same as Beta4)

Security

Kernel extensions signed after April 7th, 2019 must be notarized in order to load on macOS 10.14.5.

Known Issues (Beta 5)

  • The system fails to register tickets stapled to installer packages not scanned by Gatekeeper, which causes newly installed kernel extensions to fail to load if Internet access isn’t available. This can occur if a user launches installation from a local folder or an enterprise uses automated tools to deploy an installer. This issue doesn’t affect stapled disk images, apps, or kext bundles.
  • Workaround: In a new folder, create a shell script named preinstall to register the stapled ticket during install:
#!/bin/sh
if [[ `/usr/bin/sw_vers -productVersion` == 10.14.5 ]]; then
    /usr/sbin/spctl -a -vvv -t install "$PACKAGE_PATH"; fi

Then, when creating the flat package installer using either the pkgbuild or productbuildtool, pass the --scripts <path to folder containing preinstall> option to embed the preinstall script into the finalized installer.

Previous 10.14.5 Beta Releases

  • 4th macOS Mojave 10.14.5 beta 4 (18F127a) – Release Notes
  • 3rd macOS Mojave 10.14.5 beta 3 (18F118d)
  • 2nd macOS Mojave 10.14.5 beta 2 (18F108f)
  • 1st macOS Mojave 10.14.5 Beta 1 (18F96h)

How to get macOS beta releases

How to download macOS Mojave Beta

10.14.5 (18F131a) Beta 5

Introducing a macOS System Status & Version Info page for MacAdmins

macOS System Status

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.

Status Page Location

Apple releases fourth beta of macOS Mojave 10.14.5 (18F127a) Beta 4

Mr. Macintosh - macOS Mojave 10.14.5 (18F127a) Beta 4
macOS beta Feedback Assistant application
macOS Mojave 10.14.5 (18F127a) Beta 4

Apple has released macOS Mojave 10.14.5 (18F127a) Beta 4 to Developers and public beta testers. As a MacAdmin it’s important that you take time to test Apple’s Beta Releases. We all missed that Local Account password changes at the login window using the PRK was flat out broke! This could have been fixed if it was caught before the public release of 10.14.4. We now have to wait 1-2 months before 10.14.5 is released.

Make sure you are testing Notarization

10.14.5 has all of the Notarization security features enabled. You need to dig in and start testing the new system. The Beta 4 release notes call out that Kernel extensions signed after April 7th, 2019 must be notarized in order to load. Be sure if you have an important 3rd party app that installs a kernel extension that you reach out to the vendor and make sure they are aware of these changes.

10.14.5 (18F127a) Beta 4 Release Notes

Overview

The macOS 10.14.4 SDK provides support for developing apps for Macs running macOS Mojave 10.14.5. The SDK comes bundled with Xcode 10.2.1 available from the Mac App Store. For information on the compatibility requirements for Xcode 10.2.1, see Xcode 10.2.1 Release Notes.

General

  • Copy-protected video content plays back correctly on iMac Pro.

Accessibility

  • Accessibility Events switch was removed, because related aspects of the W3C AOM effort are no longer applicable.

Date and Time

  • Support for the Reiwa (令和) era of the Japanese calendar, which begins on May 1, 2019, is now available. The first year of Japanese-calendar era is represented as “元年” (“Gannen”) instead of “1年”, except in the shorter numeric-style formats which typically also use the narrow era name; for example: “R1/05/01”.

Security

Kernel extensions signed after April 7th, 2019 must be notarized in order to load on macOS 10.14.5.

Previous 10.14.5 Beta Releases

  • macOS Mojave 10.14.5 beta 3 (18F118d)
  • macOS Mojave 10.14.5 beta 2 (18F108f)
  • macOS Mojave 10.14.5 Beta 1 (18F96h)

How to get macOS beta releases

How to download macOS Mojave Beta

Updated List of macOS 10.14.5 – 10.15 Notarization Links & Info

MrMacintosh.com - MacOS 10.14.5 & 10.15 Notarization

Updated: 09/04/19 – 54 Links

By now you have most likely heard about Apple’s new Notarization system. If you haven’t you can read Apple’s Developer Documentation explaining the change starting in 10.14.5. Below I will keep an updated list of macOS 10.14.5 – 10.15 notarization links.

As a MacAdmin it’s hard to keep up, I will help.

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!

Be sure to drop me a line if you would like to see a link added to the list.

Notarization Table of Contents

  1. Important Notarization Dates
  2. Apple Developer
  3. MacAdmin Blogs
  4. 3rd Party Vendors
  5. GitHub Links
  6. Slack #Notarization Channel
  7. Misc. Links

1. Important Notarization Dates

  • 10.14.5 = April 7, 2019 – ONLY Kexts have to be Notarized after this date. All pkg, dmg, installer’s will install just fine if they are not Notarized.
  • 10.15 Beta 1 = Jun 1st 2019 – All pkg, dmg, installer and Kext’s need to be Notarized after this date to install.

2. Apple Developer Links

  • Signing Mac Software with Developer ID
  • 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.
  • App Sandbox Entitlements
  • Manage access to system resources and user data in macOS apps to contain damage if an app becomes compromised.
  • Safely open apps on your Mac
  • macOS includes a technology called Gatekeeper, that’s designed to ensure that only trusted software runs on your Mac.
  • New Notarization Requirements – Developer Email
  • 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.
  • What is Transporter?
  • 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.

3. MacAdmin Blogs

Howard Oakley – eclecticlight.co – @howardnoakley

Tom Bridge – tombridge.com – @tbridge77

Jeff Johnson – lapcatsoftware.com – @lapcatsoftware

Michael Tsai – mjtsai.com – @mjtsai 

Tim Perfitt – twocanoes.com – @tperfitt

Charles Edge – krypted.com – @cedge318

Rich Trouton – derflounder.wordpress.com – @rtrouton

Gus Mueller – shapeof.com – @ccgus

Latenightsw.com – Shane Stanley

Successfulsoftware.net

Hackernews

4. 3rd Party Vendors

5. GitHub Links

5. Slack #Notarization Channel

Mojave 10.14.4+ will now sync your AD password to FileVault if forgotten

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.

sysadminctl -secureTokenOff userwhoforgotpass -password – -adminUser localadmin -adminPassword –

Now turn SecureToken back on.

sysadminctl -secureTokenOn userwhoforgotpass -password – -adminUser localadmin -adminPassword –

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.

Enter the 10.14.4 update.

I can’t file this under my previous article 3 undocumented macOS Mojave 10.14.4 Enterprise fixes. This fix was actually documented in the Enterprise Content article for 10.14.4. The problem is the wording is a little confusing, but does kind of make sense.

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.

  1. macOS Mojave 10.14.4 or newer.
  2. Active connection to Active Directory.
  3. Access to the PRK (Personal Recovery Key)
  4. 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.
  5. FileVault Automatic Login enabled

Step 1. Boot Mac with the Personal Recovery Key.

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.

  1. Call the Help Desk and have them reset the password and then issue you a temporary password.
  2. 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

macOS Mojave 10.14.4 update fixes AD Mobile Account/FileVault password change sync issue.

10.14.4 Update breaks local account password reset when using FileVault Recovery Key

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.

New build version of macOS Mojave 10.14.4 (18E227) released

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

Links

I am using SUS Inspector, you can find this great application here.

Be sure to join the #mojave channel at MacAdmins.slack.com

macOS Mojave 10.14.4 (18E227) Is available from the Mac App Store now or from installinstallmacos.py

I also used Suspicious Package.app it’s available here.

10.14.4 Update breaks local account password reset when using FileVault Recovery Key

Mr. Macintosh - 10.14.4 Update breaks local account password reset when using FileVault Recovery Key.
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

10.14.5 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.

Mr. Macintosh - Enterprise Content section from the what's new in 10.14.4 update document.
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.

  1. Boot system – Select user
  2. Click the ? Button so I can enter the recovery key.
  3. The system will now boot to the login window
  4. You will see the username filled in with your username with the password reset window.
  5. Type in a brand new password and then hit “Reset Password”
  6. The window thinks for a second then shakes you off.
  7. The password is not changed.
Mr. Macintosh - Reset password window after entering in the recovery key.
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.

Mr. Macintosh - Trusty ole resetpassword 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.

  1. 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.
  2. Press and hold the power button until your Mac turns off.
  3. Press the power button again to turn on your Mac.
  4. 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.

File this issue as a bug to bugreport.apple.com

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.)

File an Apple Care Enterprise ticket if you have an account. https://www.apple.com/support/enterprise/

You can also dupe the radar that I submitted. https://openradar.appspot.com/50005199

Upcoming Mojave 10.14.5 update enables enforcement of some Notarization & Gatekeeper controls.

Today Apple released an updated developer document informing us of upcoming notarization changes.

MacOS 10.14.5 (18F108f) Beta 2 was released this afternoon you can begin testing notarization changes now!

Update 04/09/19 – The cut off date has been found for new or updated Kernel Extensions 03/11/19

Last year Apple took the covers off 10.14 Mojave at WWDC 2018. Apple then released information on the following new security features User Content (TCC), Enhanced Runtime & Notarized Apps. You can watch the entire WWDC presentation “Your Apps and the Future of macOS Security”.

Later that year Apple released a document reminding us of the upcoming changes. This time they gave us a time frame “Spring 2019 release”

A little history on Apple releasing mid-cycle security changes.

Last year Apple released the following security changes midway through High Sierra’s deployment.

User Approved MDM (UAMDM)

Apple released this document explaining the User Approved MDM system and User Approved Kernel Extension Loading (UAKEL).

If you wanted to install profiles that managed Kernel extensions a UAMDM was required.

User Approved Kernel Extension Loading

Apple then announced changes around User Approved Kernel Extension Loading (UAKEL). “Starting with macOS 10.13.4, enrolling in MDM no longer disables User Approved Kernel Extension Loading, and extensions previously allowed to load for that reason now require approval”.

Starting in 10.13.4 all new kernel extensions installed needed to be approved or white listed.

10.14.5 Notarization requirements.

This bit of information was just made public late this afternoon. Looking at the requirement paragraph we can make some guesses.

Looking over this paragraph the important part seems to be “all new or updated”.

10.14.5 – New or updated Kernel Extensions

I think this means that once you have 10.14.5 any NEW or UPDATED Kernel extension will NOT LOAD unless it is fully notarized.

Example #1 – I build a brand new application today that has a built-in Kernel Extension. I did not notarize the kernel extension. If I tried to install this app on a 10.14.5 system the Kernel Extension would NOT INSTALL.

Example #2 – If I attempt to install Symantec Endpoint Protection.app that has a Kernel extension built in on a 10.14.5 system. The app WILL INSTALL because this application was built before the change.

10.14.5 – All software from Developers new to distributing with a Developer ID.

Reading this again I think it’s the same as Kernel extensions. If you build apps with a brand new Developer ID notarization is required for your app to install.

Example #1 – I build a brand new Application with my new Developer ID that I signed up for today. When I go to install this app on a 10.14.5 system Gatekeeper will BLOCK this application from installing.

Example #2 – I built an application last year with my Developer ID. I attempt to install this application today and Gatekeeper WILL ALLOW the install.

Update 04/09/19 – The date for new/updated kernel extensions is 03/11/19

What does mid-cycle security changes mean for MacAdmins?

I posted above about mid-cycle security update releases because this is the new norm for Mac Administration. Apple is no longer releasing features and security enhancements in the gold master and calling it a day. They are continuing to secure macOS and if that means releasing a security change mid-cycle so be it! Again this is a good thing, anything Apple can do to secure macOS what we want. The rub is MacAdmins have to continually be on top of these changes or they will come back to bite us.

Learn with us! Join the #notarization channel on MacAdmins.slack.com

Notarization is still new to most of us and will start to affect you soon. It’s better to learn how this new system works so you can be ahead of the game!

Join us on macadmins.slack.com

Mastodon