FileVault 2 Deferred Enablement - El Capitan

[UESCDurandal]

Have any of you guys had issues with FileVault 2's deferred enablement feature since upgrading to El Capitan?

Here's the scenario I'm running into so far: Mac had FileVault 2 successfully deployed and encrypted via Casper using deferred enablement while running 10.10.x. Mac is then upgraded to 10.11.0. Filevault 2 is disabled via System Preferences and is allowed to fully decrypt. Running "fdesetup status" shows the following.

FileVault is Off. FileVault master keychain appears to be installed. Deferred enablement appears to be active for user 'username'.

And "fdesetup showdeferralinfo" shows this.

{ AskAtUserLoginMaxBypassValue = 0; CertPath = stdin; Certificate = <CERTIFICATEINFOGOESHERE>; Defer = 1; DontAskAtUserLogout = 1; OutputPath = "/Library/Application Support/JAMF/run/file_vault_2_recovery_key.xml"; Usernames = ( "username" ); }

Which these results should imply that when this username logs back in it should prompt them to enable FileVault 2, which it does not...

I've ran "fdesetup disable" and have confirmed that the status and showdeferralinfo commands show that FileVault is off and no deferral is set. I've then run the same FileVault 2 policy that we currently use with Yosemite and the deferred user continues to log in without a prompt after multiple reboots.

So far I've replicated this behavior on two Macs. I will be testing initial deferred FileVault 2 deployment to a freshly imaged 10.11 machine once I have an image prepared.

Has anyone else seen something like this with El Cap yet?

[alexjdale]

Same here, I posted this a couple minutes earlier: https://jamfnation.jamfsoftware.com/discussion.html?id=17283

I saw this issue with a new image this morning, so it was not caused by an upgrade. It may be an OS defect.

[alexjdale]

It appears that deferred "at login" mode works for local accounts, but does not trigger at login for Active Directory accounts. This must be an OS defect.

[mm2270]

An OS defect around Active Directory accounts?? Inconceivable! Can't be, when has Apple ever done that!?

</sarcasm>

[alexjdale]

Bumping this in case anyone has gotten it to work with AD/mobile accounts, I am surprised this isn't being talked about much. It's very nearly a showstopper issue for us if we can't force FV to be enabled.

[UESCDurandal]

This certainly seems like an OS X bug. I wouldn't be surprised if this doesn't work correctly until 10.11.1 is released.

Has anyone tried this with the latest developer/beta builds of 10.11.1? I'm in no hurry to test it out myself.

[alexjdale]

I have, and it is still not working on the latest beta.

I just submitted a bug with Apple as well as opened a case with JAMF.

[gachowski]

Sorry I missed this .....

Yes it's an Apple bug... it stopped working on the 2nd to last El Capitan beta... I filled with Apple day one of GMC beta...not fixed in X.11.1 either...(yet)

C

Jamf has a defect # too : )

[kirkmshaffer]

We're kind of seeing this here with El Cap. The user gets the prompts as they're exiting: logging out, shutting down, shutting down to restart. But they are not getting the forced enrollment at login like they do in Yosemite.

The Disk Encryption Configuration shows up in the inventory, but the institutional key is not present, the individual key is unknown, and the state is unencrypted (as expected).

Tested to most recent developer preview.

[gachowski]

@Shaffer

Yep deferred next log in doesn't work and deferred next log out only half works : )

If you have a Apple support please open a ticket so we can drive the number of effected machines up, so it get fixed faster : )

C

[alexjdale]

Edit: how do I delete a post?

[kirkmshaffer]

Just opened a ticket with Apple, so I'm on the bandwagon :)

[gachowski]

Thanks @Shaffer !!!

C

[Kaltsas]

I also have opened a support ticket with Apple.

[kirkmshaffer]

Sorry about the vague response but... Anyone else have a developer account? Anyone else feeling better about this after yesterday?

[alexjdale]

I am feeling better about this now, yes.

[gachowski]

: ) me too.. still have a few thing to keep testing : )

[ghsimon]

re: Schaffer Anyone else feeling better about this after yesterday?

What occurred on 10/27 that might have made anyone feel better about this problem? I don't see any updates from Apple on that day.

I am still running into this problem and would like to get clued in as to what might help fix it.

[gachowski]

X.11.2 public beta

[ghsimon]

Thanks, I will have to try it...

[tthurman]

Not sure if you guys are aware or not, but I figured I'd let you all know, JAMF has a RADAR open with apple about this issue.

RADAR #22839220

Apple said this in response to my request of the info for that RADAR.

The radar you provided is regarding FileVault 2 deferred enablement does not work on LDAP users, the users did not receive any prompts. 'fdesetup status' will report that FileVault is in "deferred enablement" but logging in will not trigger the FV2 credentials prompt.

Regards,
TJ

[Vitamin-Z]

Just ran into this issue as well. Glad to see I'm not the only one suffering :P

[Kaltsas]

This does appear to be resolved in the latest 10.11.2 beta. It has been triggering successfully in all my tests.

[Vitamin-Z]

Great! I hope that the general release is a week or two away.

[bmarks]

What setting do you have selected in the Disk Encryption section of your policy? There's another thread, but this all does work if you have "at next logout" selected. Just to be clear, this is separate from the policy trigger. In our testing with Apple and JAMF, only "recurring check-in" and "custom" triggers work to trigger our FileVault policy.

This has been working for us the entire time since El Capitan was released (and before, to be honest.) However, it took us an embarrassingly long time to figure out that simply toggling that setting in the Disk Encryption section was the fix.

[bmarks]

Also, we had to add an additional inventory collection policy to occur at next boot so that all of the fields would populate in the JSS. For our purposes, we did this as an additional policy so that it'd only apply to a subset of our Macs and not cause too many Recons. It appears that adding inventory collection to the policy itself when it's configured this way causes inventory collection to get interrupted so the keys, etc. don't get uploaded until the next inventory collection interval. And, depending on your environment, if that next Recon waits too long, they key info actually disappears and can't be uploaded. The other thread isn't sure how long that window is, however.

[gachowski]

Deferred next log in doesn't work, and it's the only way of setting FV2 that I know of that they user can't override/skip.

When the deferred is set to next log in, after the user logs in they get a popup and if the user select continue instead of ok the machine will reboot automatically back to the same window. Also set to next log in the user doesn't get the popup of the recovery key. Making it impossible for the user a disable FV2 or use the mac not encrypted, from what I can tell. Allow us to deploy Macs with very very limited staff interaction, or zero touch.

With it set to next log out, the user can just select continue and the Mac will not be encrypted and if they do select ok the will see the FV2 key.

C

[bmarks]

Yeah, but that's a workflow question in this case more so than a technical one. In our case, our provisioners won't hand a Mac to a user until FV is enabled, so that workflow works for us.

But, my point is that it works at all. "At next login" definitely does not currently work in El Capitan at all. So, if you have a FV requirement now, "at next logout" will work though you may need to adjust your workflow.

[Vitamin-Z]

I did find that thread previously and changed it to 'At next logout'. The prompt does pop up with the password request but I get "There was a problem enabling FileVault on your computer. You should use System Preferences Security & Privacy to view or change FileVault". Don't know why this is happening. Will have to look in the logs.

[Vitamin-Z]

Getting ManagedClient[xxxx]: MCX.doCmdLogout: setupFileVaultFDE enable returned 11 which is an authentication error. Strange...Oh well, at least I'm getting prompted now.

[bmarks]

(Disregard.)

[bmarks]

@Vitamin-Z Hmmm, that error I haven't seen before. A few questions that pop into mind are... Are your users admins? What is the trigger for the policy itself? JSS 9.81 right? Is the policy scoped to all users?

I don't know if some of those questions are relevant or not, but they're the first variables that come to mind.

[Vitamin-Z]

@bmarks Yes, my users are admins. The trigger is 'Recurring Check-in'. We are on 9.81. Currently as a test, my Mac is the only one.

[kirkmshaffer]

10.11.2 is out - downloading now to make sure this build maintains our happiness :)

[CGundersen]

Seems back to normal. AD ... I just can't quit you no matter how many hints Apple gives. :)