@rcorbin we have it doing file vault at next restart and thats working with out a problem.

I re-tested 10.13.4 Beta 6 and 7, I get the create Secure Token box and I enable FileVault at logout with no issues.

@jalcorn So you create an admin account and a local account during the DEP enrolment. Then you enable FileVault on the next restart ? The drive is in APFS ? Both accounts end up with a secure token ?

@rcorbin at enrollment the admin/shared account is created that is enabled for file vault. File Vault gets turned on after restart when the user logs in.

@jalcorn

Which OS are you testing on? The issue @rcorbin describes is that on 10.13.3 only the first account created will show up on the boot screen (after unit has FV enabled). Any accounts added via policies or System Preference does not show up on the boot screen even they are added to the list of FileVault users in System Preference.

Since DEP creates a standard account and JAMF will create a management account, our testing indicated one of the 2 accounts will not show up on the list of FileVault user due to security tokens.

10.13.3 also breaks the built-in Guest account, the MDM doesn't seem to enable that option even it is checked. We have to manually enable in System Preferences.

At this point, we are not going to move forward to APFS as it breaks our zero-touch workflow that did not exist with 10.12; we can add script and such to issue a security token but it creates addition touch points where we are not confident in deploying.

@killer23d I haven't tried it on 10.13.3 Running a clean install to test. So can't wait to see this.

@jalcorn Are you creating the admin account via setup assistant ? I think you are doing this a bit in reverse of the way we do it. We take a machine out of the box (Currently they are 10.13.3) and when setup assistant comes up the user is logging in and creating their account and password. The admin account gets created in the background at that point via the pre-stage. With our testing both of those user accounts don't always get a secure token. Our solution at this point seems to be to reformat the machines to HFS+ . We are running Jamf Pro 10.2.2.
@killer23d

Might want to pop your head in the 10.4 Beta forum...and while you're at it, over at the Apple Beta forum. :)

@rcorbin Have you had any update on your secure token issue? We are using (as best as I can tell) the exact same setup as you. Enrolling w/ 10.13.3 and DEP, and neither the first logged in account or the admim get secure tokens. I'm going to try to format the drive with HFS+ and see if that resolves it.

@mrbill With HFS+ you are really using the old FileVault system that doesn't even have secure tokens. So it does work just fine. It's just kind of sad to have to reformat the devices. Hopefully this all starts to work correctly in the future with 10.13.5 or a future update. We have just updated to Jamf 10.3.1. We will see if that makes any difference, but I think it's an OS level thing.

I have managed to script around all my issues with this except 1.

I have a local Admin Account (inventively named Administrator) who's password differs depending on site.

When the password gets changed from the default build password, the Secure Token/FV2 password does not get changed along with it.

I have abandoned the JAMF password changing, and tried scripting it using Sysadminctl, it sort of works, but the machine needs to be rebooted, FV2 unlocked with the old Administrator password and then the passthrough login allowed to fail and the new password entered so it logs in. THEN it will sync the password change to FV2. this is useless as the account is not used often.

Anyone have any idea's on how to change a local password and have it update the secure token password immediately, without having to go to the machine and log it in.

Tried leaving it for days to see if it updates eventually, but no.

Just to be sure: I see that 10.13.5 out of the box does not succeed to get a secure token für a new AD user at login.
Anyone having more success ? Thanx!

Our workaround (using 10.13.5) is starting encryption as the account created by DEP enrolment. Then when an AD user logs in for the first time and gets the secureToken prompt IT Support enter the DEP admin account.

We then have an encrypted device with two pre-boot users, once the AD user confirms pre-boot is working we remove the DEP account from pre-boot auth users.

Complete pain with no automation.

@Retrac Thanx for sharing!

Hi All,

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.

@kendalljjohnson I am struggling to get the right process to enable FileVault in client machine, i want that it should enable automatic and user should not be able to see the file vault recovery key, please help

@rastogisagar This is the Jamf recommended process that we use.

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

How you get into single-user mode is different now on T2 based Macs.

https://support.apple.com/en-us/HT201573