Skip to main content

We have been troubleshooting some High Sierra + FileVault workflow issues with Apple enterprise support, and one of the things they wanted us to change in our existing workflow was to make the mobile user the first user to log into the machine. Apple stressed that a mobile user would only get a secure token at login if the mobile user was first (as opposed to a local admin.) However, this presents a new challenge. How do you make it so that the mobile user is an admin user when they log in the first time?

Now, don't answer yet. I know there is a login script that works and that makes the mobile user an admin user, but this does not work in regards to activating FileVault on the first login, i.e. the script doesn't run soon enough to allow the user to get a secure token on the first login (I know the user doesn't get asked for their password to activate FV until they actually log out.) If the mobile user logs in again, they do get a secure token. But, that's what I am trying to avoid. I don't want the mobile user to have to login/logout/login/logout to activate FV. I want to see if there is a way to make it so that the mobile user is an admin instantly at login so that they get a secure token and can thus enable FV at the first logout.

For background, we are using the FV configuration profile payloads to activate FV. This was also recommended by Apple. In this specific testing, we are not applying a Disk Encryption Configuration via a Jamf policy like we have done for all previous macOS/OS X versions. That workflow wouldn't work anyway since the mobile user wouldn't have a secure token in that scenario either at first login.

One thing I was wondering is if there was a way to leverage the "Allow Administration" field of the binding profile. This asks for groups, I assume only LDAP groups. But, is there a way that I am missing to use this field to make it so that only the initial mobile user is an admin? In our scenario, binding occurs as part of the DEP PreStage Enrollment configuration:

So, we do a provisioning package (SplashBuddy) that I have modified to run individual JSS policies - while the user is prevented from doing anything. At the end of the provisioning, the device is required to reboot - this allows us to make the current user logged in an Admin and enable FV2 for that user.

So, our current DEP workflow is:
1. Turn Device On.
2. Go through SA
3. Get Remote Management (skip account creation)
4. During "Setting up your Mac" - Enrollment Complete policy kicks off.
5. Enrollment Complete Policy - Binds the device to the domain - among other things.
6. Device gets to login screen.
7. User waits 30ish seconds for Enrollment Complete to finish.
8. User Logs in.
9. Splash Kicks off.
10. User is made Admin. FV2 is deferred for their user account.
11. Device is required to reboot.
12. User attempts to log in - gets prompted for FV2
13. Enables.
14. Device goes to Desktop (instead of rebooting again - because Hi-C changed that)
15. Done.

Maybe something like this could help?

@tthurman Ah, the forced reboot would work well. We use SplashBuddy too, but I didn't think of a forced reboot after it finishes. It's not perfect, but it would still be cleaner for the user.

Terms & ConditionsCookie settings