macOS Big Sur zero touch with FileVault (Securetoken for local admin)

matthias_bretz
New Contributor III

Hi, I need some help on this.
We would like to finally make the step to a truly zero touch workflow.
We hav a PreStage which successfully creates a local admin and a local (standrad-) user as shown below.
cb5b9507ee3945b3a8b1621b1cadac36

Now with macOS Big Sur the standard user gets a secure token and is therefore granted to initiate the FileVault encryption. Great. But the local admin doesn't get a secure token and therefore is not allowed to unlock FileVault.

From my research the localAdmin would automatically get a secure token as I would log in through the login window but in truly zero touch this may never happen and if the user returns the Mac we wouldn't be able to unlock it.

Has someone a solution on how to grant the localAdmin a secure token by script?

11 REPLIES 11

sirsir
Contributor

I believe this is a bug and JAMF/Apple are working on a fix. The only way around it is to manually create the local account during PreStage for now. Not zero-touch, but it does work.

easyedc
Valued Contributor II

FWIW, at one point I'd been told by Apple this was working as intended. Product Engineering didn't seem to see the problem.

Tribruin
Valued Contributor II

I was going to say the same thing as @easyedc . It seems that Apple considers this as working as intended. I would suggest you file feedback with Apple.

Another alternative, there are scripts floating around that prompts the user for their username and password and then grants a Secure Token to the local admin account via the command line. You could look at implementing that as well.

One final thing to consider. Unless you are somehow randomizing your local admin passwords, there is a security consideration with having the local admin having the ability to unlock the disk. If someone were to compromise the local admin, they would have access to all your Macs. Some companies prefer not to give secure token to the local admins and rely on the FileVault recovery key to unlock the disk if necessary. The key can then be rotated and collected in Jamf.

easyedc
Valued Contributor II

As a follow up, this particular issue is the one issue preventing us from doing complete zero-touch/ship to users directly. We have a corporate requirement to enable encryption and we don't assume that the user will complete it when prompted, or we have seen a few unexpected one-offs where the prompt from Jamf doesn't ever display and you have to manually enable it via system preferences.

sgallowayISB1
New Contributor II

Forgive me if this is not helpful - this is my first post here... ever (in working memory)!

I'm not claiming that I've solved this issue completely, more experienced it repeatedly since High Sierra and found reasonable compromises and palatable workarounds! ;-)
I believe I'm correct in saying that the only user that gets the secureToken is the 'interactive' user, aka the user that gets prompted to create their account during setup assistant and has to 'interact' with the device.

In our particular instance, we're using JamfConnect. The interactive user (device owner) gets the secureToken during the JamfConnect Login experience. We use the LAPSuser feature in JamfConnect to use the individual FV2 recovery key as the password (individual key), providing a bit more security than a generic localadmin password that, if compromised, could impact a whole fleet.
That said, I do believe that there are some non-JamfConnect LAPSuser solutions out there, and this one in particular gets a lot of love...
https://github.com/NU-ITS/LAPSforMac

Hopefully someone will correct me if I'm completely wrong, but I think the LAPSuser avenue is something you may want to explore further..

Cayde-6
Release Candidate Programs Tester

@matthias.bretz So we've pushed out a zero touch build with Big Sur and there is another workflow to gain access to the local admin account without a securetoken

1). Support get the laptop
2). Support initiate a password reset using the FV2 key
3). FV2 decrypts and prompts to reset the user password.
4). Click Cancel and you're at the login screen
5). Login to local admin account

matthias_bretz
New Contributor III

Thanks for your responses. I can't understand why Apple doesn't give the MDM created admin a secure token but I found a way to script around this issue.
Here are the main three lines if someone else wants to go this way.

dseditgroup -o edit -t user -a $LOCALUSER admin
sysadminctl -adminUser $LOCALUSER -adminPassword $LOCALUSERPW -secureTokenOn $LOCALADMIN -password $LOCALADMINPW
dseditgroup -o edit -d $LOCALUSER admin

Note: this isn't a fully working script nor is it exactly what I use. This is just for informational purpose so anyone can work from here.

Tribruin
Valued Contributor II

Not saying that TTG is right or wrong, but i thought the posting of this blog post was pretty timely.

SecureToken or Not

easyedc
Valued Contributor II

I put something together from the blog post here - https://travellingtechguy.eu/script-secure-tokens-mojave/. Give that a look, too.

@stevegalloway Question for you - are your users admin level or standard users? That is (for us) part of the problem.

vcasiero
New Contributor II

are you able to share what you put together?  in our instance, users are admins, so should be able to grant if prompted to via popup

sgallowayISB1
New Contributor II

Good point @easyedc - users are admins, which works to our advantage in this instance, and to our disadvantage in many other instances!
The travellingtechguy post is one of two 'go-to' references for me on SecureToken, along with DerFlounder