Accounts created through the Users & Groups system preference and users created in the Setup Assistant get a Secure Token created. Every other one does not. Apple REALLY wants us to know that now. You and everyone on 10.13.4 has that issue.

Yeah, that is a new "feature" in 10.13.4. Check out some of these other conversations on the subject.

https://www.jamf.com/jamf-nation/discussions/27669/pre-stage-enrollment-issue-with-10-13-4-popping-up-securetoken-window-message-after-logging-into-ad-for-the-first-time

https://www.jamf.com/jamf-nation/discussions/27653/summary-of-macos-10-13-4-information-and-links

That is going to be a huge, annoying, PITA for all of our Mac labs...although it is not the end-of-the-world.

Yes, it is a huge annoying PITA, one created by Apple to solve some imaginary problem, that really just makes all of our lives and jobs harder. Thanks (for nothing) Apple!

Has anyone ever gotten an official "statement" from Apple on why they chose to do this? Was there some issue with accounts not created via Setup Assistant or the GUI before that we just didn't know about, or is this, as I suspect, just another way to drive force people to a DEP model, which Apple has deemed the only worthy method of setting up Macs these days?

DEP doesn't solve it. We do DEP but skip all the user creation stuff. Still having the Secure Token issue.

Partially a “me too” post.

Error message came in 10.13.4...DEP doesn’t help.

Fix will have to come from Apple’s side.

While this doesn’t fix the problem, it gives background on Apple’s rationale for good or bad:

https://derflounder.wordpress.com/2018/01/20/secure-token-and-filevault-on-apple-file-system/

I'm not sure any of that provides a "rationale" for Apple's decision, just more details on how it all works. So, yeah, they are trying to protect FileVault user enablement, I guess, but the part that's aggravating is, if an account is created from AD via command line for example, the account has already been verified against a presumably secure directory, meaning it's not likely an unauthorized user, so why not automatically grant that account a Secure Token? I can almost agree to not granting a local account created with dscl or sysadminctl a Secure Token since that could be done via a bad script or malware, etc. But you really can't easily create AD accounts without the account actually existing in AD to begin with (and the correct password later to log in with it).
Plus, Apple has had mechanisms in place for years to prevent accounts from being added to FV2 unless authorized by an existing enabled FV2 account. What problem does this new thing solve exactly? Maybe I'm just missing something obvious, but I'm not sure I get what this was done for.

in a future OS release (cough) we might be able to manage that dialog box (cough, cough)

Let the record show I’m not happy about this issue but other than petition Apple, there is very little one can do about this issue at the moment. @dpertschi suggested what I hope for.

I have been testing a possible workaround that was provided to us by Apple support, it doesn't work. The idea was to introduce a new profile that would bypass this on a 10.13.5 BETA OS Mac.

We don't use FileVault but we use AD mobile accounts. I don't understand how this is a good thing without the proper tools to disable it across the enterprise if needed.

Over the years I have been so burned by the decisions Apple has implemented...come on Apple!

Anyone have a workaround that is solid and works?

Right now it’s annoying but my users have been properly warned to click “Bypass”...here’s hoping the fix you talked about matures prior to shipment...we aren’t using FileVault either in public labs and I agree this is a nuisance, but not an end-all showstopper

@mconners FWIW, in my testing with the .5 beta, using a profile to deliver the payload of

cachedaccounts.askForSecureTokenAuthBypass=true

does suppress display of the ST auth dialog when AD user logs in. It is total BS though for this to appear on desktops (which is where I'll be scoping this profile).

Thank you @dpertschi this is much appreciated. I attempted to create a configuration profile with a custom payload for this but my results all failed. Do you have a config profile that you are using and it works?

I'm NOT seeing this in our environment with AD accounts. I'm creating an image for 10.13.4 using AutoDMG and then deploying (HFS+ formatted) using Jamf Imaging.

@mconners yes, I uploaded this plist and used preference domain com.apple.MCX

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">



<plist version="1.0">

    <dict>

        <key>cachedaccounts.askForSecureTokenAuthBypass</key>

        <true/>

    </dict>

</plist>

@allanp81 this is a new key in 10.13.5

Thank you @dpertschi I really appreciate your feedback here. I will test this again and see what results we get. I also got off the phone a minute ago with Apple and this is the same workaround they are offering. If this isn't working for me, I must have some syntax off a bit, but it is so simple, I can't imagine that's the problem.

@mconners this will only work in 10.13.5 which is only available in beta right now. This will NOT work in 10.13.4 which is the current public release.

Thanks for the clarification @boberito. I sometimes forget the obvious when working on many problems at the same time. I appreciate the information.

I can confirm with 10.13.5 Beta 3, just issued today, this workaround is still active and ready to go. Thanks for the info @boberito, it was helpful in our testing.

That plist file also worked for me on 10.13.5 Beta 3. Now I just have to find a way to suppress that stupid "We respect your privacy" popup on every login. Once we get that figured out we'll be good to upgrade our labs.

@McAwesome Suppressing the Data & Privacy pop-up window on macOS High Sierra Rich Trouton has you covered.

@boberito That doesn't work on 10.13.5.

10.13.5 just dropped, any confirmation that the solution shown in @dpertschi's post works in 10.13.5 final?
(It matches what Apple Enterprise Support told me for the beta)

bump

@kstrick confirmed the profile works in 10.13.5 final.