Enabling filevault using Jamf connect

[tdenton]

Afternoon All 

Is anyone using Jamf connect to enable filevault we are in the final stages of rolling out Jamf connect campus wide. 

It seems to be working find for new builds however we are seeing different behaviour for exisiting devices. Some devices are enabling filevault fine some arent even after an inventory update.

All devices have same 3 config profiles for Jamf connect
Jamf Connect License
Jamf Connect Menu Bar
Jamf Connect Login 1-2-1 V.1 (Has updated key to EnableFDE set to true)

and Escrow recovery key config profile to bring the key back to Jamf ( there are some filevault settings managed here as well)

It mainly Intel 27" Imacs from 2020 which dont seem to be encrypted seeing the same issues on M1 as well. However other Intel and M1 Imacs have encrypted in the pilot group.

I cant find any information for Jamf connect for weather it tries again at somepoint.
Im also not sure if my escrow profile is causing some sort of clash as we have that set to enable filevault as well as escrow key.

I assume Jamf connect can enable filevault on its own without the need for additional filevault profiles however I havent been able to confirm this with any documentation. It also confusing that the same config works on some machines and not others

Any advice appricated 

Thanks

[AJPinto]

More or less the reason why Jamf Connect can "enable" FileVault is for organizations without an MDM. If you have an MDM, you need to be using a Configuration Profile to enable FileVault. Jamf Connect uses the fdesetup binary to enable FileVault, which is largely deprecated. 

I'm not sure on the frequency at which Jamf Connect runs fdesetup, but I would expect to be only once. There are also a ton of things that can cause fdesetup to fail, and running the command in this way will not tell you why its failing to encrypt the disk.

TLDR; Use a Configuration Profile to turn on FileVault not Jamf Connect.

[stevewood]

On the existing systems, have you verified that the existing users on those existing devices have SeecureTokens, or can receive SecureTokens? If the users are unable to be granted SecureTokens, either because there is no SecureToken user already on the system or they are not crypto users (diskutil apfs listCryptoUsers /), then you will be unable to enable FileVault on those systems. 

I would start with checking a few systems to see if SecureToken is the culprit, and to @AJPinto point, there are a few other reasons why FV may not be enabled.

[AJPinto]

Honestly, with this being a lab/class environment it's probably secure tokens. FileVault is not very friendly to shared user environments, something Apple really need to work on.

I use the script below as an EA to see who has Secure Tokens on device. I cant remember the source, but figured I'd share incase its helpful to OP.

#!/bin/zsh

# Extension attribute to report all user accounts who have a secure token
# If a user is found to have a secure token, the results will be displayed as:
#   Admins: user1, user2 (or "None" if none found)
#   Non-Admins: user1, user2 (or "None" if none found)
#
# If no user is found to have a secure token, the result will be:
#   "No Secure Token Users"
# If an unsupported file system is found, the result will be:
#   Unsupported File System: (File System Type)

# Variable to determine File System Personality
fsType="$(/usr/sbin/diskutil info / | /usr/bin/awk 'sub(/File System Personality: /,""){print $0}')"

if [[ "$fsType" != *APFS* ]]; then
    echo "<result>Unsupported File System: $fsType</result>"
    exit 0
fi

secureTokenAdmins=()
secureTokenUsers=()

# Loop through UUIDs of secure token holders
for uuid in ${$(/usr/sbin/diskutil apfs listUsers / | /usr/bin/awk '/\+\-\-/ {print $2}')}; do
    username="$(/usr/bin/dscl . -search /Users GeneratedUID ${uuid} | /usr/bin/awk 'NR==1{print $1}')"
    
    if /usr/sbin/dseditgroup -o checkmember -m "$username" admin &>/dev/null; then
        secureTokenAdmins+=($username)
    else
        secureTokenUsers+=($username)
    fi
done

if [[ -z ${secureTokenAdmins[@]} ]]; then
    stList="$(echo "Admins: None")"
else
    stList="$(echo "Admins: ${secureTokenAdmins[1]}")"
    
    for user in ${secureTokenAdmins[@]:1}; do
        stList+=", $user"
    done
fi

if [[ -z ${secureTokenAdmins[@]} ]] && [[ -z ${secureTokenUsers[@]} ]]; then
    stList="$(echo "No Secure Token Users")"
elif [[ -z ${secureTokenUsers[@]} ]]; then
    stList+="\n$(echo "Non-Admins: None")"
else
    stList+="\n$(echo "Non-Admins: ${secureTokenUsers[1]}")"
    
    for user in ${secureTokenUsers[@]:1}; do
        stList+=", $user"
    done
fi

echo "<result>$stList</result>"

[tdenton]

thanks @AJPinto just to confirm this is staff devices we dont encrypted labs due to issues around filevault and shared devices.

As you point out config profiles seem to be best option to manage filevault so will continue to use that. Its a nice feature that jamf connect can do it  but doesnt seem that reliable from the testing I have done so far.

[AJPinto]

When we onboarded Jamf Connect a few years ago, the Jamf contractor stressed very hard to not use the FileVault functions. It's really only for organizations without a MDM. In other lanes we were also told to not enable FileVault in the prestage (ie installing the configuration profile there).

FileVault is very much a glass cannon, enable it exactly how apple wants it enabled or you will have problems. Manual methods like fdesetup need to be used manually. 

[tdenton]

Thanks @stevewood I can confirm devices and users who are effect do have secure token.

Enabling filevault via Jamf connect did seem to give a nicer experince has it just happen in the background an user didnt need to do anything. However we already have a filevault config profile which has always been more reliable.
Was trying to make process smoother so the user didnt have do anything for filevault.

I have deployed our current filevault profile so hopefully that will get them encrypted I have removed the EnableFDE from our jamf connect profile. As it doesnt seem that reliable.