10.13.2: Unable to enable additional FV2 users via GUI or fdesetup

See this thread: https://www.jamf.com/jamf-nation/discussions/25692/high-sierra-10-13-encrypted-users-not-showing-at-filevault-login-screen

Is your local admin "hidden" as part of your DEP workflow? We discovered that 10.13.2 breaks the "enable" button for hidden accounts.

Our management account is hidden, does this mean we can't enable FileVault 2 for the management account?

@donmontalvo It depends on your workflow, but you should be able to enable FV for the management account. However, you would need to log in as the management account to do so if your local admin is hidden because the "enable" button is dead if your DEP-created local admin is hidden. Since the management account is a local admin too, it should be able to enable FV for itself. However, I haven't tested this because we don't do that. We disable FV for all users except for the one mobile user. With mobile accounts, they cannot enable FV for themselves, which is why this is a bigger issue for environments with mobile accounts.

(What I wrote above assumes your local admin and management accounts are different accounts.)

Our workflow (as noted in the other thread) is below, but these steps assume the mobile user has already been created:

1. While logged in as local admin, open Terminal and call the JAMF policy for enabling FileVault.
2. While still logged in as local admin, open FileVault System Preferences and enable FV for the mobile user.
3. Log in as mobile user and run another AppleScript app that we created that runs a script to disable FV for the local admin.*

(*This assumes you want to disable this functionality.)

It is Step 2 that is broken as of the 10.13.2 update if your local admin user is hidden via DEP. Clicking the "enable" button does nothing if you are logged in as the local admin and you are attempting to enable FileVault for the mobile user. Logging in as the mobile user and clicking the "enable" button results in a new macOS message saying you don't have the power to do that.

You can enable it using sysadminctl and the 501's credentials, but you can't use it (or any other hidden user with a secureToken) to enable other users in the GUI. You click the "Enable Users..." button and it doesn't do a damn thing. If your 501 user is hidden you will have the same problem. I have of course reported this to AppleCare Enterprise. We will see what they say... In a related note, I am having nothing but problems trying to use sysadminctl to change the 501 user's password in a non-interactive way without breaking its ability to administer FV. This is with a non-DEP out of the box type setup where the local admin (tech) user is created with a generic password.

Ooooh, that does fix the issue.

I'd be slightly happy if only that didn't open up a whole host of new issues.

1. Having to manually run diskutil apfs updatePreboot / after enabling the users before they appear at the FV2 screen

2. AD password changes are still not syncing to FV2 preboot auth automatically. Have to manually run the same diskutil command before FV2 and login passwords are synced.

3. I still need to investigate this further to see if I can replicate it, but I unplugged from ethernet when changing the AD password for the FV2-enabled test account I had on that machine. I then logged in to the user while still off network, using the old cached password (normal). I then plugged in ethernet. I went to take a look at the FileVault prefpane and noticed that this user was back to being listed as not FV2-enabled.

@doggles Hmmm, that's odd. I don't have your Issue 1. I rebooted immediately after enabling the mobile user in System Preferences and the mobile user was visible on the FV unlock screen at boot.

I don't have your Issue 2 either. Where are you changing the password?

I haven't tried to reproduce your Issue 3.

One thing 10.13.2 does fix is the syncing of the FileVault password with the account password when changing the password via System Preferences. I personally can vouch for this because I was dealing with a mismatched password issue until 10.13.2 was released (and I changed my password again.) macOS 10.13 and 10.13.1 both had all kinds of AD password sync issues, but so far (for our environment at least) those issues appear resolved as of the 10.13.2 update. We have only tested this on about 300 Macs so far. We haven't allowed the rest of our 30,000 users to update yet.

I'm changing the password in Active Directory directly. These are mobile accounts. The standard login window immediately authenticates with the new password set in AD, and I am given the standard prompt after logging in to update/create new keychain. Select update, provide the former password to sync keychain. All good. I'm connected to the network and can talk to the dc.

I log out, reboot. At FV2 screen, I enter the new AD password. Fails. I enter the old password. It authenticates and brings me to the login window (since the passwords are out of sync it does not directly log in to the user).

I reboot again, it persists. Until I manually run the diskutil command, the FV2 password is not syncing with the login password on these machines.

For what it's worth, we tell all of our Mac users to make sure only to use System Preferences because we've had various issues for years when changing it directly in AD. These issues pre-date High Sierra for us. In our experience, while it should sync when changing it in AD, a lot of times we have to re-bind to get everything to sync if a password was changed in AD. But, that's just us.

And, just to reiterate, we were having new password sync issues introduced by High Sierra but they seem to have been addressed by the 10.13.2 update.

We have password expiration policies :(

We have expiration policies and complexity policies enforced by AD too. The challenge on macOS is that it's not very consistent with warning you that your password is about to expire. I see these warnings at the login screen, but who logs out these days? There are scripts out there that you can use in conjunction with a jamf policy that displays a daily popup, but I haven't tested them.

Yeah, I mean, there's urgency in leveraging more third-party tools to patch up Apple's broken processes, since we'll be getting High Sierra hardware before we know it. But there's also the fact that this was working before and Apple has not done anything to help us understand or prepare for this, and have shipped a fundamentally broken product. The good thing is, we're at least still running fine on 10.12.6. But the problem is, hardware refreshes will force our hands soon.

If I had the authority or power to say "we're no longer binding Macs to the domain" I'd have done it when NoMAD first came on the scene. Unfortunately, our org won't approve that. And, frankly, binding them has worked just fine for us, until 10.13 and the secure token came along.