Note: have a look at my new post regarding additional admin accounts and SecureToken: https://travellingtechguy.blog/additional-admin-with-securetoken-or-not/
Just a quick post before heading into the weekend, and leaving Secure Tokens far behind me for a couple of days. I just want to share this attempt to make a script to manage Secure Tokens prior to enabling FileVault.
The idea is to make sure that you have an Administrator Account with a Secure Token in case you want to be able to manipulate the tokens/FileVault later. This is especially important in case you are limiting the end user to creating a non-admin/standard account or using managed mobile accounts at automated enrolment.
As said in my previous post, you want to avoid enforcing FileVault on a non-admin if you need multiple accounts with Secure Tokens. Once the only token holder is not an admin, it’s game over. Unless I’m really missing something. In that case, please share!
I made the script with the idea to run it before enabling FileVault. But you could run it afterwards…. if the end user is an Admin token holder.
To automate Secure Token manipulation, we need the credentials of both the granting as the receiving user account. I’m passing the Admin credentials via the $4 and $5 variable in Jamf Pro, but have a look at this gitHub link in case you want to add more security.
I also kept a few ‘echo’ statements in the script for troubleshooting.
Hereby the link to the script. Let me know what you think! Useful? Comment or remarks? Please let me know!
grtz,
TTG
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Senior Enterprise Support Engineer | Jamf
I tried something to avoid asking the end user for his/her password.
This by using sysadminctl to grant a token to itself post enrolment. This works if there are no token holders. Just like the command I used in the script to grant a token to both the ‘IT Admin’ and the end user.
However, because the ‘IT Admin’ becomes the token holder, the end user standard account without a token can’t enable FileVault. I ended up having the error on the profile again. You will have to grant the end user a token… ending up asking for the password again.
This means that there is not workaround. If you want to manipulated tokens, you have to ask the end user for his/her password, whatever approach you take.
This makes me believe that my script applied post enrolment, before enabling FileVault is the only way to go.
In case you do end up with a non-admin token holder (and no admin token holder available) you can actually promote the end user to admin, manipulate the tokens and demote again. Dirty but it works and it’s the only workaround.
Please tell me if you find something I am missing!
Can you help, I have manny endusers who are not admin but have token and admin does not. Can you point out where I can promote/demote automatically in the script?
Hi Daniel, I added a piece of code on line 138 which promotes the Standard Account, grants a token to the ‘IT Admin’ account, and demotes the user again.
Please test before using in production, and let me know if it works for you. I just tested it and all seems fine.
Thank you will be testing!!
Hi TTG,
Testing out your script. When I run it as an end user it prompts me for a password to enable FileVault, am I suppose to enter the end user’s password there? If so, I keep getting a return message that the password is incorrect. Can you advise on what I could be doing wrong.
Hi! Well, the script is actually made to be used remotely in Jamf Pro. It actually does not enable FileVault, but as I mentioned in the comments at the bottom, you could. The idea of the script is to fix Secure Tokens. This for the different scenarios as outlined in the script where you might have a Mac with no Secure Token holders, or only some user accounts.
As discussed in my previous posts there have been issues with macOS Mojave 10.14.1 where you might end up with a Mac with no Secure Token holder and no way to fix it due to a bug. This has been fixed in 10.14.2 and my script is an example of how you could manage the different scenarios.
The fact is, you need to be an admin to manage Secure Tokens, and to grant another user account a token you need the password of that account. Hence the idea is that you use a known admin account (with or without token), and ask the end user for its password if you want to give that end user a token.
You could do that manually on the device by using the sysadminctl command, but the idea is to do this remotely. Because the script is intended to be used via Jamf Pro I used variables in the script.
# additional Admin credentials
addAdminUser=$4
#add encryption
addAdminUserPassword=$5
Those can be passed via a Jamf Pro policy. The user account of the end user will be fetched in the script and the user password will be prompted.
If however you want to run the script locally, you will have to change it. Either hard code the admin account and password, or script a prompt for it.
The question is however, why would you script this if locally you could just use the sysadminctl command with appropriate flags following the situation you want to fix.
As said, the script is just to cover all possible scenarios remotely.
Any idea how I could integrate this into DEP-Notify to grant our admin account a token before removing local user admin rights and enabling FV, which happens at the end of the DEP-Notify workflow?
Hi Nick. No, Notify does not allow for user interaction which you need to manipulate tokens. You need the password of both the token holder as the account you want to grant a token to.
A few questions however. Why do you really need a token for you admin user? When would you need to reboot the FileVault enabled Mac outside of the end user’s control? Only when offboarding in my opinion, for which you should have the recovery key. But I don’t really see a need to have the admin account FV enabled.
Why not just restrict the user creation in DEP to standard user? Enforce FileVault with a policy or profile post enrollment.
I know, only the very first user logging in generates a token, if it’s a local admin, but the question is, do you really need it.
IMO you don’t, just make sure to escrow/redirect the recovery key correctly.
I have used this script on some mac´s and working fine. However, on one mac it just keep popping up everytime user is restarting and prompting for password for user that must be applied to filevault
How can I get rid of this as the script must have triggered something on the machine since it always appear when restarting
Hi Peder, how have you deployed the script? Because I can’t see anything in the script that would trigger a behaviour like that.
Hey TTG!
Testing out your script, running it pretty much as is– passing admin credentials via Jamf Pro. Everything works as expected! However, regardless of the way I prompt the user for their password (after inputting it), I’m constantly returning an error for “sysadminctl[4986:189092] Operation is not permitted without secure token unlock.”
Is there a step I’m missing in your original script to work around this? Googling didn’t yield very promising results on how to resolve this error.
Hi Natalie!
The admin account has a secure token right?
Can you have a look at the script and use the command of the situation you are in manually?
I mean, if the admin has a secure token and the end user does not, have a look at that section of the script and try the sysadmin command i use in that section manually in terminal.
Thanks for your reply!
I’ve actually included the three scenarios from your original script, (end user has token, admin does not; admin has token, end user does not; neither has token) to cover those, and this error I’m seeing occurs on running these manually to test.
Ok but whats your exact situation on the Mac ? Who has token and who needs one?
To manipulate tokens, you need an admin with a token… or promote a standard to admin first.
Does you admin have a token?
Run “diskutil apfs listcryptousers /“ to verify the list of account UID’s who have secure token.
Crosscheck this UID with your admin account UID which you think has a token.
The error points to the fact, at least it seems, that your admin account does not have a token, hence can not unlock it and can’t manipulate or grant tokens
I understand that, the script’s intent here is to have the local user grant our admin account a token, not the other way around. This error occurs regardless of the way I try it, as you provided 3 different scenarios to use. This error happens if trying to grant the admin account a token while the user has one (verified with the check), it also happens if the admin is trying to grant the user one (also verified). In both cases, the account granting the token is the one which has it.
I just tried on macOS 10.14.5 by manually running the command:
sysadminctl -adminUser ttg -adminPassword – -secureTokenOn testuser -password –
the “-” after -adminPassword is to prompt for it, same for the “-” after -password
Works fine. But you could test by writing the password in clear instead of the “-” too.
If you are getting a Secure Token unlock error, even when trying the command manually, it can only be password related for the admin account granting the token to the other user.
In your situation, the end user granting a token to your admin, must also be admin. But the script fixes this by promoting and demoting if necessary.
If it does not work manually in terminal, it’s not the script, but the password or the token of the granting user…
Thanks for the reply! The passwords are correct, as it also doesn’t work on my own machine. This is now the error trying your above command manually:
2019-05-23 15:37:49.959 sysadminctl[22067:1220121] ### Error:-14090 File:/BuildRoot/Library/Caches/com.apple.xbs/Sources/Admin_sysadminctl/Admin-716/addremoveuser/main.m Line:373
2019-05-23 15:37:49.959 sysadminctl[22067:1220121] Operation is not permitted without secure token unlock.
Which macOS version is this?
I tried this scrip on a machine running Big Sur and it didn’t work ! is there an update for it or something that might work on Big Sur ?
Hi! Good point, I need to check that for Big Sur indeed. Any error or reason why it did not work? Will have a look at it.
That said, the situation where you’d need a full script like that on Big Sur are limited.
Apologies, I tried the script this morning after checking the admin IT account credentials and it worked! 🙂
Ah! Even better! Thanks for letting me know!