Mojave 10.14.6 - DEP deployment results in no secure token for the user

[jtrant]

Hello,

Has anyone noticed a change in macOS Mojave recently whereby the user account created at the setup assistant does not get a secure token, but the Jamf management account does?

From my initial testing, it seems that if you go through the DEP enrollment process right away, the user account will get a secure token but the management account does not (expected behavior in our case - in our workflow the tech FileVault enables the management account in Security & Privacy, granting it a secure token).

If the tech enrolls the machine but lets it sit at the "Create a computer account" screen for anything more than a minute or two, the management account ends up with a secure token instead of the user account, and only the management account can sign in once FileVault has been enabled via Jamf policy.

Show the users that can unlock the drive:

diskutil apfs listcryptousers

Match the GeneratedUID to a local account:

dscl . list /Users GeneratedUID

This is definitely a new issue for us and I don't believe I've had it reported prior to 10.14.6 which is what Macs are now shipping to us with. It also only affects T2 Macs since they are encrypted out of the box.

Thanks,
Justin.

[bmarks]

Are you kicking off FileVault enablement with an "at enrollment" policy that is implementing a Disk Encryption Configuration? If so, what do you have selected in the pulldown menu under "Enabled FileVault 2 User?" The "at enrollment" policies run while you're still in the Setup Assistant, which may also explain why waiting results in different behavior. If the policy runs and the only user on the machine at that time is the management account, then the management account may go into deferred mode with the secure token. Can you provide more detail regarding your current workflow?

[jtrant]

Hi @bmarks ,

Thanks for your reply. There are no FileVault policies triggered by enrolment. Our workflow is that the tech creates the user account at the setup assistant, opens Self Service and runs a deployment policy we have scoped to our IT team. This contains a FileVault configuration which applies at first logout. At this point, the tech enters the password created at the setup assistant to enable FileVault.

The only common element here seems to be leaving the machine at the setup assistant for more than a couple of minutes with the "Create a user account" screen open. This results in the management account having a secure token and the user account not getting one.

Thanks,
Justin.

[bmarks]

That's basically our workflow, but we don't have the issue that you are experiencing (and I'd know because we provision 300-500 Macs per week) so I am not sure what else I can add. Since you're creating the user via Setup Assistant, I assume they aren't mobile users. And, it doesn't sound like your provisioners are logging in as the management account first to do anything. Apple told us their vision is that the first account to log into the Mac always gets a secure token and that is the reason we changed our workflow a while ago to create the user at Setup Assistant and thus be the first user to log into the Mac.

One thing you might try, which is something we're doing as we prepare to release Catalina to our environment, is to move to profile-based FileVault management. If the local user is the first to log in, it will go into deferred mode the moment the profile is pushed to the Mac, so you just want to make sure it is scoped correctly (or added to the newer Configuration Profile section of your PreStage settings.) Then, a quick logout/login and FV is activated. I believe that this is going to be the preferred method anyway with Catalina according to Apple though that doesn't really help you with Mojave at the moment. It might be worth testing though with your Mojave workflow to see if the profile causes different behavior in regards to the secure token, but that's a guess because if there isn't anything you've left out as far as your current workflow, I'm not sure what the root cause would be.