Jamf Policy - Create Local Admin Account

Redmond
New Contributor

Hi,

I have recently generated and pushed a new Local Admin account which successfully deploys however I am unable to immediately sign in with this account until I manually enable filevault access.The account is being pushed to an already setup device and in the Policy I have enabled Allow user to administer computer and Enabled user for FileVault 2 however this does not appear to apply the FileVault access I need and no error appears in logs to indicate why.

Can anyone advise on what I may of missed or should try next?

 
3 REPLIES 3

Tribruin
Valued Contributor II

Users need to a have a Secure Token to be able to unlock a FileVault enabled computer. There are only a few ways a user can get a Secure Token:

  • The first user to login into the computer gets a Secure Token by default
  • Any users with a Secure Token can grant a Secure Token to a another user via sysadminctl
  • Any user that logs in to computer from the Login window (not the FileVault window) is granted a Secure Token IF the computer has a bootstrap token escrowed in Jamf (or another MDM)

So, if you want to grant your Administrator an ST, you need to come up with a workflow to ask the user from their password and use a script to give the Administrator a token.

That all being said, it is generally considered a poor practice nowadays to have a single Administrator account with a known password have a Secure Token. Essentially you are giving anyone with that password the ability to log in to ANY computer in your organization. While that sounds appealing, it is also a security risk. Please check out his article for better solutions:

https://travellingtechguy.blog/additional-admin-with-securetoken-or-not/

You can also review other posts on this blog for more information about Secure Tokens and FileVault. 

AJPinto
Honored Contributor III

 

When you check the box in the JAMF Local Account policy to Enable user for FileVault, JAMF presents a warning that this does not work for anything greater than 10.13. The warning looks to be gibberish now (at least on my JAMF instance), it used to be proper English.  Apple changed direction with FileVault and best practices change.

AJPinto_1-1703189063938.png

In any event, I used the script below to give FileVault tokens out until late last year. The work flow was we knew the local account credentials for the account with a FileVault Token, and where trying to grant the logged in user a FileVault Token using that local account. Your workflow seems backwards to this, but the script may still be useful to you.

#!/bin/bash

######################
# Script Name: 
# Author: 
# Date: 
######################

######################
# Exit Codes
# 0 - Sucess: General Sucess
# 1 - Failed: Admin account credentials are not correct
# 2 - Failed: Mac not domain bound, or otherwise cannot talk to the domain controller
# 3 - Failed: User account to be cached not found in Active Directory
# 4 - Sucess: FileVault Not enabled
###################### 

echo "Begin script"

######################
# Gather and verify admin account
######################

#*------------------------ STRING DECRYPTION ------------------------*#

function DecryptString() {
    echo "${1}" | /usr/bin/openssl enc -aes256 -d -a -A -S "${2}" -k "${3}"
}

Pass="String here"
Salt="String here"
DecryptString=$(DecryptString "$5" "$Salt" "$Pass") 
        

adminUser="$4"
adminPass="$DecryptString"
#adminPass="PassHereForTesting"

osvers=$(sw_vers -productVersion | awk -F. '{print $2}')
check4AD=`/usr/bin/dscl localhost -list . | grep "Active Directory"`

## 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


######################
# Popups asking for user to ender userID and Password
######################

echo "Prompting for userToAdd credentials."

## Prompt for Username
userToAdd=$(/usr/bin/osascript<<END
tell application "System Events"
activate
set the answer to text returned of (display dialog "Enter your userID:" default answer "" buttons {"Continue"} default button 1)
end tell
END
)

## Prompt for Password
userPass=$(/usr/bin/osascript<<END
tell application "System Events"
activate
set the answer to text returned of (display dialog "Enter your Password:" default answer "" with hidden answer buttons {"Continue"} default button 1)
end tell
END
)

loopCount=0
while [ "$loopCount" -lt 3 ]; do
    # Refresh Directory Services
    if [[ ${osvers} -ge 7 ]]; then
        /usr/bin/killall opendirectoryd
    else
        /usr/bin/killall DirectoryService
    fi
    sleep 15

    ## try to auth the user in advance. this seems to increase the success of the ID command.
    /usr/bin/dscl /Search -authonly "$userToAdd" "$userPass"

    adCheck=`id $userToAdd`
    echo "AD Check is: $adCheck"
    if [[ -z "$adCheck" ]] ; then
        ((loopCount++))
    else
        echo "AD Check successful"
        break
    fi
done 


######################
# Remove FV Access if existing
###################### 

sleep 2
sudo fdesetup remove -user $userToAdd

## 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."


######################
# Runs JAMF Recon to assign Mac to $userToAdd
###################### 

jamf recon -endUsername $userToAdd

######################
# Clean up
###################### 

echo "Script completed"

 

D-
New Contributor

Something to consider, as Tribruin mentioned, would be to not have a local admin with the same password on each endpoint. What we have done for my org is move to a script based elevation and locked that behind user based login in self service. So only those in IT will see the elevation option in self service.

The script elevates the logged in user for 15 minutes then will remove admin. We have had this in place for almost a year now with no major issues arising from no local admin on our devices.