FileVault Authenticated Reboots No Longer Work As Expected

[kc9wwh]

With Apple's release of macOS Sierra 10.12.4, the latest macOS Installer v12.4.06 does not enable the FileVault authenticated reboot when the installer is called via the startosinstall binary.

Radar has been opened with Apple and I'll post updates here as they become available. rdar://31410389

If you are an Apple Enterprise customer and are affected by this, please open a AppleCare ticket and reference Apple Radar 31410389 and Jamf PI-003804. This will help to ensure this issue is resolved in a timely manner.

The only known workaround at this time is to perform a macOS 10.12.3 Install and then do a combo update to 10.12.4. Not really ideal, but can be done.

[mpermann]

I also submitted a bug report to Apple over the issue. I figure the more the merrier.

[mpermann]

I also noticed that the latest macOS Sierra 10.12.4 installer also leaves around a file called /Library/LaunchDaemons/com.apple.installer.cleanupinstaller.plist. This happens whether I use the workflow you've developed or just installing from the Mac App Store. I don't remember seeing that file when using the 10.12.3 installer. Seems like Apple is being a little sloppy with this installer. I think I'll update my bug report with Apple to include this issue.

[shawnhonsberger]

@kc9wwh if this workflow is in place, would this phrase hold true after being installed - since the cleanup process deletes the files? Packages installed by Casper has Install macOS Sierra.pkg

[kc9wwh]

@mpermann I noticed that file as well and haven't seen it till now.

@shawnhonsberger that would still remain TRUE as package receipts don't reference the actual file installed, instead package receipts are stored in /Library/Application Support/JAMF/Receipts/.

[shawnhonsberger]

Thank you @kc9wwh.

[rqomsiya]

I can verify that users are now seeing the FV2 auth screen with 10.12.4. I once reported that the installation bypassed this, but I verified that this IS an issue.

[rqomsiya]

Any updates on this? Has anyone tested the workflow in 10.12.5 beta?

[kc9wwh]

@rqomsiya The 10.12.5 beta doesn't provide the installer, instead they do a software update (reduces folks sharing the beta) so unfortunately there isn't a way to test it that I am aware of.

[jardhug]

I just tried 10.12.5 and it still doesn't work

[kc9wwh]

Update: It has not been determined how or when the issue will be resolved. The original report on this issue, Bug ID 31463377, is still under investigation. We will notify you when it is closed.

[cpwasthere]

So someone I was talking to on the macadmins slack found a fix for authenticated restart and it has worked for me.

Basically, the currently logged in user needs to the own the macosinstaller.app and you can achieve that by quitting it the first time it's launched with this script and relaunching it. When that happens, the user owns it and it will do an authenticated restart. Here is the extra code:

Open the app as the current user to enable Authenticated reboot

macOSinstallerAppPath="/Users/Shared/Install macOS Sierra.app" CurrentloggedInUser=$(/usr/bin/python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "\n");')

There was an issue with startosinstall command that "Install macOS..app" needs to be opened once by logged in user to get it working properly

effectiveUserID=$(/usr/bin/id -u "$CurrentloggedInUser") /bin/launchctl asuser "$effectiveUserID" sudo -u "$CurrentloggedInUser" /usr/bin/osascript <<EOT tell application "${macOSinstallerAppPath}" to activate EOT

Wait for 5 seconds to settle down then quit the app

/bin/sleep 5 /bin/launchctl asuser "$effectiveUserID" sudo -u "$CurrentloggedInUser" /usr/bin/osascript <<EOT tell application "${macOSinstallerAppPath}" to quit EOT

This can go right before the #begin upgrade comment line near the end of the script.

[rqomsiya]

@cpwasthere Can you post the full script in RAW or a maybe a github link to it? I added these lines, but doesn't seem to be working for me.

Thanks, R

[kc9wwh]

@cpwasthere I'm interested if that actually works. I've talked to a couple people that have did the quick launch and quit of the app and then execute the startosinstall command, but it seemed to be for other reasons and those I talked to said FV Authenticated reboots still didn't work. But interested none the less!

I did come across this post the other day, but haven't had the chance to test it myself, although the logic is sound and should work. https://www.jamf.com/jamf-nation/discussions/22731/in-place-macos-sierra-upgrade-script#responseChild148130

[cpwasthere]

I posted it on my github just for readability sake. The formatting in this post is awful. Hopefully it's a bit more clear.

https://github.com/cpwasthere/MacOS-Authenticated-Reboot

[aawalkerjj]

@kc9wwh I can confirm the solution cited on (https://www.jamf.com/jamf-nation/discussions/22731/in-place-macos-sierra-upgrade-script#responseChild148130) certainly works.

You can use the majority of the script you created as preinstall script and the postinstall script to install MacOS.

[alex030]

Hi,

just want to share what I have found. I want to be as close as possible to the standard install process. Solution like mentioned above to launch the Install App once and quit it after some seconds feels not like a nice solution... For those that still have the problem with FV2 enabled machines and the auth restart via startosinstall. I figured out, that on the first launch of the High Sierra Installer app, Apple launches a LaunchAgent with a mach service "com.apple.install.osinstallersetupd". So why not launch this agent for our own in our workflow. I submitted the LaunchAgent to launchd and then started the installation via startosinstall. Auth restart process works as expected. Cool!

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.apple.install.osinstallersetupd</string>
    <key>LimitLoadToSessionType</key>
    <string>Aqua</string>
    <key>MachServices</key>
    <dict>
        <key>com.apple.install.osinstallersetupd</key>
        <true/>
    </dict>
    <key>TimeOut</key>
    <integer>Aqua</integer>
    <key>OnDemand</key>
    <true/>
    <key>ProgramArguments</key>
    <array>
        <string>/Applications/Install macOS High Sierra.app/Contents/Frameworks/OSInstallerSetup.framework/Resources/osinstallersetupd</string>
    </array>
</dict>
</plist>

Try it yourself ...

[stickman112]

@alex030 Where did you add this into the workflow? Did you add it to the script or install it separately? Very interested in trying this.

[jmartinFT]

@alex030 I would also like to know where you're working this in.

[kc9wwh]

@alex030 sorry I missed your initial post. Please submit a pull request and I’d be happy to add this to the workflow.

[patgmac]

I recently got an update on my enterprise ticket stating that they believe this is a result of running startosinstall as root or sudo, and they wanted me to try running as a user, which I have not tried yet (hoping sudo -u will work). Anyone have time to try?

[scheblein]

sudo -u gave me a auth prompt to install a privileged helper tool, but it did do the authenticated restart.

[kc9wwh]

I can't believe it took them this long to respond to that... ugh

Thanks for the update though! I'll test next week and get it published or feel free to submit a Pull Request if you beat me to it!

[alex030]

I have not added it to the script. I have an in house app handling the upgrade process for us. Within this app I create the LaunchAgent, start it and then start the osinstall binary.

[kc9wwh]

@patgmac I tested it this morning using sudo -u startosinstall.... and although it works, it prompts the user to install the helper tool, so not ideal.

Gonna try adding the LaunchAgent from @alex030 into the script and test.

[kc9wwh]

@alex030 Can you confirm that for the LaunchAgent, the key TimeOut should be set to a type of integer vs a string?

[patgmac]

@kc9wwh This "FileVault Authenticated Reboots No Longer Work" affects regular Jamf policies as well, right? Is this something maybe Jamf can fix on their end so this works again?

[kc9wwh]

@patgmac I'm not aware of this affecting Jamf Pro policies as we initiate the authenticated reboot in a different method. Feel free to email me a case # or PI# if you have one, but I'm not seeing anything like that right now.

[kc9wwh]

@alex030 Can you provide more details?

I created the LaunchAgent within the script and loaded it with launchctl, but at reboot it does not do a authenticate reboot.

/usr/libexec/PlistBuddy -c "Add :Label string com.apple.install.osinstallersetupd" -c "Add :LimitLoadToSessionType string Aqua" -c "Add :MachServices:com.apple.install.osinstallersetupd bool true" -c "Add :TimeOut string Aqua" -c "Add :OnDemand bool true" -c "Add :ProgramArguments array" -c "Add :ProgramArguments: string $OSInstaller/Contents/Frameworks/OSInstallerSetup.framework/Resources/osinstallersetupd" /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist
/usr/sbin/chown root:wheel /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist
/bin/chmod 644 /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist
/bin/launchctl load /Library/LaunchAgents/com.apple.install.osinstallersetupd.plist

I am doing a in-place upgrade from 10.12.5 to 10.13.2. I did try running the installer manually as a typical consumer user would and watched the LaunchAgent folders and never saw that plist get created, so can you please confirm the path and name? Also my last question about the TimeOut key.

Thanks!

[alex030]

Timeout key is integer. Apple does not create a file. They submit the job on demand. Verify it via launchctl list or launchctl print

[alex030]

Want to share another approach I got from a team member: you can also handle it the Jamf way. Configure the osinstall binary disable automatic reboot. You can use the setting /usr/bin/defaults write /Library/Preferences/.GlobalPreferences IAQuitInsteadOfReboot -bool YES for that, which will tell osinstall binary to not reboot after initiating the installation. Perfect.

# This preference is referred to in a framework inside the
# Install macOS.app:
# Contents/Frameworks/OSInstallerSetup.framework/Versions/A/Frameworks/OSInstallerSetupInternal.framework/Versions/A/OSInstallerSetupInternal

Then the reboot process can be handled by the migration script. Call a custom trigger policy with "Perform authenticated restart on computer with FileVault2 enabled" configuration.

[kc9wwh]

Update: Was successfully able to inject the LaunchAgent today and use the existing script/workflow to deploy an OS update with FV authenticated reboot. Thanks much @alex030!

[kc9wwh]

Testing on 10.12.6 to 10.13.2 and 10.13.3 completed. Working on testing upgrades from 10.10.5 and 10.11.6 to 10.13.3.

[kc9wwh]

Tested on 10.11.6 to 10.13.3 successfully. Just need to test 10.10.5 and will post.

[rqomsiya]

Testing 10.10.5 in a few minutes. I'll report back..

[kc9wwh]

@alex030 I'm not entirely sure how you are reverse engineering the LaunchAgent from the launchctl print output of the process. Could you provide more info on that?

I've also attached the sample outputs from Mac OS X 10.10 which I can only assume need a tweak to the LaunchAgent, currently when injecting the LaunchAgent you provided the client just hangs in startosinstall. The first two are ones called using the LaunchAgent you provided and the last one is when launching the installer as the user from the GUI.

10.10_spawnedByScript_startosinstallRunning.txt 10.10_spawnedByScript.txt 10.10_spawnedByInstaller.txt

Would appreciate any help you can provide as I'd like to have this script support 10.10 as well.

[kc9wwh]

Ok, of course as soon as I post that I got it to work by changing the program it calls to osinstallersetupplaind. Need to do some additional testing, but looking good!

...still would love to know how you reverse engineered that plist ;)

[rqomsiya]

Everything has been running super well on my 10.10.5 clients! Authenticated restarts are working with out issue.