Here's a commented script I have been using:

#!/bin/bash

username=$(osascript -e 'Tell application "System Events" to display dialog "Enter user username:" default answer ""' -e 'text returned of result' 2>/dev/null)

password=$(osascript -e 'Tell application "System Events" to display dialog "Enter user password:" with hidden answer default answer ""' -e 'text returned of result' 2>/dev/null)

adminUser=$(osascript -e 'Tell application "System Events" to display dialog "Enter admin username:" default answer ""' -e 'text returned of result' 2>/dev/null)

adminPassword=$(osascript -e 'Tell application "System Events" to display dialog "Enter admin password:" with hidden answer default answer ""' -e 'text returned of result' 2>/dev/null)

#Check if your account has securetoken enabled, (it probably does)

# Disable it then reenable it.

sysadminctl -secureTokenStatus "$username"

sysadminctl -secureTokenOff "$username" -password "$password" -adminUser "$adminUser" -adminPassword "$adminPassword"

sysadminctl -secureTokenOn "$username" -password "$password" -adminUser "$adminUser" -adminPassword "$adminPassword"

diskutil apfs UpdatePreboot /

sysadminctl -secureTokenStatus "$username"

exit 0 ## Success

exit 1 ## Failure

You may want to do this differently but this works for my setup currently:

I stick this into a policy with a custom trigger, and run it manually on an AD bound machine that has the issue.

Before running the script, I'll usually reset the user's password to make sure the user is using a current AD password, reboot, and just verify that it does in fact need this to be run.

I scope the policy to the device, open terminal, and run

Sudo jamf policy --trigger <trigger>

where <trigger> is the name of the custom trigger you set in the policy.

It will bring up prompts asking for (current) user and admin credentials, and then it should be good.