Skip to main content

Looking for some guidance with Jamf Pro - PreStage Enrollment and FileVault.

The issue:

  • In PreStage, we pre-create and hide a local admin account.

  • During setup, the workflow prompts for end-user account creation.

  • FileVault is enabled immediately after the user account is created and the user logs in for the first time.

  • As a result, only the end user is added to FileVault , the local admin account is left out of the FileVault enabled users list.

I haven’t found a way to ensure the local admin is automatically included in FV2 during enrollment.

Should this be configured differently in PreStage, or would scripting the local admin addition after FileVault is enabled be the right approach?

Looking for some guidance with Jamf Pro - PreStage Enrollment and FileVault.

The issue:

  • In PreStage, we pre-create and hide a local admin account.

  • During setup, the workflow prompts for end-user account creation.

  • FileVault is enabled immediately after the user account is created and the user logs in for the first time.

  • As a result, only the end user is added to FileVault , the local admin account is left out of the FileVault enabled users list.

I haven’t found a way to ensure the local admin is automatically included in FV2 during enrollment.

Should this be configured differently in PreStage, or would scripting the local admin addition after FileVault is enabled be the right approach?

Can I ask the reason why this is needed?  Are you escrowing the FV key into jamf?  If so, then that’s all you need.  A break-glass account should have steps to be used (e.g.: unlocking the drive via key so it can boot).


Yeah, it’s more of an extra layer of security. We do have the PRKs escrowed in Jamf, but if one record gets deleted by mistake, that key is gone. I’ll take your reply as the solution, but I’m still not 100% sure we want to rely solely on the recovery keys.

and Yes it works fine if we login to the local admin at least once. I guess the goal was to rely on the hidden local admin account created by PreStage and ship to the user directly without ever logging in as the admin.


Yeah, it’s more of an extra layer of security. We do have the PRKs escrowed in Jamf, but if one record gets deleted by mistake, that key is gone. I’ll take your reply as the solution, but I’m still not 100% sure we want to rely solely on the recovery keys.

I mean that’s what we did.  We also scraped the data being sent back to jamf and extracted the FV key and set our “local admin” account to use the FV key as the password.  This was the LAPS solution we had before jamf had theirs.


We  had to address this as we migrate to LAPS. We created a swiftdialog screen that pops up after Jamf Connect that forces then user to enable encryption. We use a script that enables filvault and the local admin gets the securetoken, and the admin password is rotated


I opened a ticket with jamf about this a couple months ago

PI138582 should be resolved in 11.21, per the internal notes on it. 11.21 should be out early October from what I've been told.


The resolved issue about the FileVault skip option in PreStage enrollment is not related to local administrator accounts created during PreStage receiving secure tokens.

 

**[PI138582] Fixed: When a local administrator account is configured in a Jamf Pro PreStage enrollment, the FileVault skip option is unavailable in Setup Assistant settings, preventing administrators from bypassing FileVault encryption during device enrollment.

https://learn.jamf.com/en-US/bundle/jamf-pro-release-notes-11.21.0/page/Resolved_Issues.html

 


I’m interested in this as well. We have the same issue with our admin account being created during enrollment/provisioning, and not receiving the token. This is the account our techs use in the field for troubleshooting, etc. If memory serves, if the account does not have a token, it cannot log into the computer when it first boots up, and that one has bitten us before in the past. We have to trust that the people setting these up initially are remembering to go back and enable the user. If it can be done automagically somehow, that’d be great.


I’m interested in this as well. We have the same issue with our admin account being created during enrollment/provisioning, and not receiving the token. This is the account our techs use in the field for troubleshooting, etc. If memory serves, if the account does not have a token, it cannot log into the computer when it first boots up, and that one has bitten us before in the past. We have to trust that the people setting these up initially are remembering to go back and enable the user. If it can be done automagically somehow, that’d be great.

Yeah, we hit the same issue with the admin account not getting a token during setup. It’s tricky if the initial tech forgets to enable it.

Right now, here’s what we do if someone gets locked out:

  • On Apple silicon Macs, have the user press Shift + Option + Return at the login screen.

  • Share the recovery key with them.

  • Help them reset their password.

  • Rotate the PRK afterwards.