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.
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?
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.
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.
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...
Hopefully someone will correct me if I'm completely wrong, but I think the LAPSuser avenue is something you may want to explore further..
@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
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.