Skip to main content
Question

Creating new users with FileVault 2/SecureToken via Policy


Forum|alt.badge.img+10

I'd like to create a new user via policy that is enabled for FileVault 2/has SecureToken. As noted in the Local Accounts payload, the "Enable user for FileVault 2" no longer works in anything beyond 10.13. After doing some digging, the only solution I have come across to do this is using sysadminctl to grant SecureToken to the account after creation. This is something I'd like to avoid if possible since it requires passing not only the credentials for a SecureToken-enabled admin through a script, but also the credentials for the account to be enabled.

Are there any secure methods to achieve this? 

3 replies

AJPinto
Forum|alt.badge.img+26
  • Legendary Contributor
  • 2717 replies
  • January 13, 2023

It is possible, but you probably wont like how it must be done.

  • Create the Account. 
  • You MUST Have the user name and password to an account with a Secure Token (FileVault key) to pass the FileVault token to the new account. 
  • If you don't have the user and password for an account with FileVault access you must turn FileVault off, add the account and turn FileVault back on which should give it a token when file vault is enabled.

 

The script below should be able to add an account to FileVault. I strongly recommend looking in to salting the passwords so they are not in clear text within the script.

 

 

 

#!/bin/bash ###################### # Script Name: # Author: # Date: # Enhancements: # Comments: # Commented ###################### ###################### # Exit Codes # 0 - Success: General Success # 1 - Failed: Admin account credentials are not correct ###################### echo "Begin script" ###################### # Global variables ###################### ## Account with Filevault access adminUser="$4" ## Password for account with filevault access adminPass="$5" ## User name of account to add to FV userToAdd="$6" ## Password of account to add to FV userPass="$7" ## verify that adminuser and pass variables are both passed to the user if [[ -z "$adminUser" ]] || [[ -z "$adminPass" ]] ; then dialog="either Admin User or Password is missing" echo "$dialog" cmd="Tell app \\"System Events\\" to display dialog \\"$dialog\\"" /usr/bin/osascript -e "$cmd" exit 1 fi ## check the admin password adminCheck=$(/usr/bin/dscl /Local/Default -authonly "$adminUser" "$adminPass") if [[ -z "$adminCheck" ]] ; then echo "Admin password is verified" else echo "Admin Password not working" exit 1 fi ###################### # Provision FileVault Access ###################### ## Get the user to be added to FV userName=$userToAdd ## This "expect" block will populate answers for the sysadminctl variables. sysadminctl -adminUser "$adminUser" -adminPassword "$adminPass" -secureTokenOn "$userName" -password "$userPass" echo "${userName} has been added to the FileVault 2 list." ###################### # Clean up ###################### echo "Script completed" exit 0

 

 

 


Forum|alt.badge.img+10
  • Author
  • Contributor
  • 41 replies
  • January 13, 2023

Yeah, that's what I was afraid of. Unfortunately salting it is really just obfuscating it since the script command can be seen in a process list along with any arguments passed to it. 

Regarding disabling/re-enabling FV2 to grant SecureToken, if FV2 is already off when the user is creating, would enabling it for the first time after grant the user SecureToken?


AJPinto
Forum|alt.badge.img+26
  • Legendary Contributor
  • 2717 replies
  • January 13, 2023
VT-Vincent wrote:

Yeah, that's what I was afraid of. Unfortunately salting it is really just obfuscating it since the script command can be seen in a process list along with any arguments passed to it. 

Regarding disabling/re-enabling FV2 to grant SecureToken, if FV2 is already off when the user is creating, would enabling it for the first time after grant the user SecureToken?


All accounts on a Mac when FV is enabled should get a secure token. I have seen some issues where non-admin accounts don't get said token though.

 

Apple is trying to shore up the security risk that is root. From the other side Apple is forcing us to manage devices their way, which is ironically very on brand for Apple.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings