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
Manager Technical Support | 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!
In my environment:
OS: 10.15.7 and 11.2+
I have a local end-user account with a secure token
I have a local IT shareed account without a secure token
I used your script to grant the local IT shared account a secure token.
My question is if another user logs in via Jamf Connect how do I give that user a secure token from the IT shared account’s creds?
So this appears to be working just not the way we were hoping. So our “test account” that were using to run this in our sandbox gets the prompt “Wrong Password”. We have the encrypted string as the password and our admin account name set fine in the parameters but it seems to not like what we’ve entered. We tried the Salt and Passphrase but those didn’t work. Then we tried the users password and boom it worked! However our goal is to not have the user see anything at all and our admin account setup as a FV2 user. Are we understanding how to use the script right? Also of note this is in Big Sur 11.4 were testing this in.
It’s impossible to grant secure token to another account without the user seeing anything, unless indeed you hard code both passwords, the one from the account who has the secure token and the one who needs to receive it.
So the script works as intended. If your
End user has a secure token and you want to script a token grant you will need to prompt for its password.
Well, then that answers it that I’m not crazy thinking some way was possible to do this silently. I loved your article about the yes and no to adding an admin account to FV2. Has your opinion changed much from that article? Sorry if my initial reply to this post also came across weird, assuming it wasn’t working right. Secure tokens have been so much fun to learn about 😉
Our current workflow is that we set up all the computers by hand and ship them to the users, and they are currently admins. As of right now, we’re putting the final touches we hope (fingers crossed) on Zero Touch with Jamf Connect and have a possible workflow change where users may need to be standard users either after initial configuration or be allowed to be admins for a few days then demoted to meet FedRamp standards. We’re currently trying to figure out the best approach to this and how to enable our Local admin account potentially for FV2 access should it be needed.
We might not be building it the way others with more Jamf Connect experience do, as we’re still testing and building out everything currently.
Hi!
I’ve been trying to put this to work through Jamf but, after the script runs, it completes successfully, I get the following on the logs:
Prompting USER for their login password.
36:203: execution error: System Events got an error: Application isn’t running. (-600)
Password OK for USER
2021-07-01 12:00:15.435 sysadminctl[93939:424663] Password is required!
Token granted to end user!
Once this is completed, I used sysadminctl -secureTokenStatus USER and the status is still showing as DISABLED.
Is there anything I’m missing?
The test Mac is running 10.14.6
Ok, it works if done through self service, my guess is that, if we force the policy to run over the terminal it will fail.
I will try again on check in to see if the experience is similar as the self service one so the users can actually put their password on
Hi Raul! It had been a while since I used the script myself and I knew it needs some cleanup. But when I wrote it back then it worked over automated policy in Jamf Pro.
Do you know when the policy executed? Was the user logged in?
Yes, the user was me… I bypassed the FV users and I knew there was no token for me.
At first, it didn’t run whey i used sudo jamf policy, and I think it was because it uses the graphic interface for the user password, when I ran it on Self Service, however, it ran flawlessly and gave me a secure token.
I asked one user to test on her own and she reported that the script ran and it gave her a secure token as well.
Oh yes, triggering it with sudo jamf policy manually may be problematic indeed, but if triggered from the background automatically when the check in happens it should work.
@Daniel Ross: I got that prompt before “wrong password” and found out that if the password has a space in it, I get that error otherwise all works well.
Oh! Maybe I need some parsing tweak then, but a password with a space? ?
I too have the space in the password issue,
any idea how to make this work if the password has a spacebar at the start?
I was hopping to pass it via the expect command, to get around it, but I’m unable to get it to work, but I am no coder.
so by using the example, and using the expect command to them post the password to the response prompt for password…
sysadminctl -secureTokenOn $USER -password thepassword -adminUser adminuser -adminPassword –