Macbook asking to bypass security token for every user

lehmanp00
Contributor III

Hi all,

I have a Macbook Pro (10.13.4) that is prompting every user to Continue or Bypass entering a Security Token code when they 1st login. This is with AD or local users. The only user it didn't ask for was the initial Admin user account we create after a command-R wipe and re-build.

JSS says that 1 account is Filevault enabled. Filevault was never enabled on this Mac and isn't now. I have wiped and re-installed a few times now. Any ideas?

Thanks!

1 ACCEPTED SOLUTION
31 REPLIES 31

boberito
Valued Contributor

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.

lehmanp00
Contributor III

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

mm2270
Legendary Contributor III

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?

boberito
Valued Contributor

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

blackholemac
Valued Contributor III

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/

mm2270
Legendary Contributor III

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.

dpertschi
Valued Contributor

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

blackholemac
Valued Contributor III

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.

mconners
Valued Contributor

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?

blackholemac
Valued Contributor III

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

dpertschi
Valued Contributor

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

mconners
Valued Contributor

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?

allanp81
Valued Contributor

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.

dpertschi
Valued Contributor

@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

mconners
Valued Contributor

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.

boberito
Valued Contributor

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

mconners
Valued Contributor

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

mconners
Valued Contributor

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.

McAwesome
Valued Contributor

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.

boberito
Valued Contributor

McAwesome
Valued Contributor

@boberito That doesn't work on 10.13.5.

kstrick
Contributor III

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)

Eigger
Contributor III

bump

cubandave
Contributor

@kstrick confirmed the profile works in 10.13.5 final.

mconners
Valued Contributor

I can also confirmed it works in 10.13.5. Initially this didn't work, so I recreated the plist and added it back to the config profile and now it works.

kstrick
Contributor III

Thanks @mconners and @cubandave .
It sucks because i pointed out how stupid this was in the 10.13.4 beta to Apple Enterprise Support, and they told me that 10.13.5 fixed it, but 10.13.4 Final wasn't even released yet... pisses me off. I'm afraid we may not have any 'real' fix for 'SecureToken' and Mobile accounts until 10.14, which sucks since we have all hammered them on it since early 10.13

Eigger
Contributor III

I'm not sure what just happened, I was testing the config profile by @dpertschi but somehow I mis scoped it, but before I realized that, I noticed that the newly dep provisioned machine with 10.13.5 didnt ask for the Secure Token, I tried to use multiple accounts, AD, and Local, and non of them showed the Secure Token thing. I double checked if the profile is installed, and its not there, and just to be double sure, I wiped the machine, removed all scope on my config profile, reprovisioned it, and, it still didnt ask for the Secure Token for all kinds of user I logged in. Does anybody experienced this? Although it didnt asks for the secure token, all the users I logged in still have Secure Token disabled when I ran sysadminctl -secureTokenStatus username.

cubandave
Contributor

@Eigger one admin must have a secure token before that message comes up when creating AD mobile accounts. Run diskutil apfs listcryptousers / what do you get?

Eigger
Contributor III

@cubandave I get "No cryptographic users for disk1s1." Until now, I logged in other users and they all didn't show SecureToken thing. Wierd.

cubandave
Contributor

@Eigger

In that case you can enable secureToken with the existing user so long as they are admin
sysadminctl -secureTokenOn < administrator user name > -password < administrator password > -adminUser <administrator user name> -adminPassword <administrator password>

You do not need to using the password in plain text. you can pass - instead

More information is available with sysadminctl -help