I've been over the forums and found some resources relating to this issue, but nothing definitive as of yet. So, here goes!
My current enrollment workflow (working through the slow process of changing, but this is what I have to work with):
I'm trying to make that last step automatic as part of the enrollment script. Here's what I have so far:
Now, fdesetup showdeferralinfo shows that enablement is pending for the AD account. sysadminctl -secureTokenStatus $ADUser shows that there is indeed a secure token for that user. However, when $ADUser logs in, they are prompted to enable FileVault (good), but FileVault is never actually enabled (not so good). Logging out and back in results in the same prompt and no encryption. The deferred enablement seems to try to kick in every login, but never succeeds.
I'm a bit puzzled here, and would appreciate any suggestions! Happy to share more info on any of the above if required.
I have a same approach where our Local Admin account provides the security token to Domain users for encryption but lately i am seeing below errors which makes no sense as it works fine on others and fails on some. All our Macs are on 10.13.5
Script result: 2018-06-15 17:49:45.421 osascript[10534:63297] HIToolbox: received notification of WindowServer event port death.
2018-06-15 17:49:45.421 osascript[10534:63297] port matched the WindowServer port created in BindCGSToRunLoop
2018-06-15 17:54:09.975 sysadminctl[11059:69031] ### Error:-14071 File:/BuildRoot/Library/Caches/com.apple.xbs/Sources/Admin_sysadminctl/Admin-679/addremoveuser/main.m Line:366
2018-06-15 17:54:09.976 sysadminctl[11059:69031] Operation is not permitted without secure token unlock.
Thank you for help in advance.
@KarmaLama I'm having the same issue where users are getting this message for an unknown reason, specifically:
2018-08-06 11:56:51.470 sysadminctl[31995:273664] ### Error:-14090 File:/BuildRoot/Library/Caches/com.apple.xbs/Sources/Admin_sysadminctl/Admin-679/addremoveuser/main.m Line:366
While I was working on an EA to track if the logged-in user is Secure Token Enabled, the sysadminctl command to check status was not consistent. On an encrypted drive, reporting status on the user who encrypted the drive returned DISABLED one minute and then ENABLED the next.
Their entire system is flawed and was poorly planned out.
So everything I'm seeing in testing and reading in these threads indicates either Apple has really messed this up, or JAMF does not have proper support for T2 systems. We can not manage startup security on ANY system with a T2 chip, because they all claim there is no Administrator account. There are two, so something is broken. It appears what is broken is SecureToken is not enabled on the admin accounts created by JAMF on DEP systems. As a result, we're locked out of doing anything other than internet recovery to wipe and reload a system as you can't boot external devices (or even the internal recovery for some reason), and dual boot doesn't work because you can never authorize the Windows partition as bootable. Anyone know if this comes down to JAMF not creating accounts properly to be compatible on the new hardware, or Apple not allowing them to because you can ONLY ever get SecureToken on the account created directly by SetupAssistant and no automated bypass of it? Not sure which company we need to hound about fixing this. We've also found single use mode no longer exists on T2 and that's square on Apple...