Pre-stage enrollment issue with 10.13.4. Popping up "SecureToken" window message after logging into AD for the first time.

MikeT
New Contributor III

We have been testing Pre-Stage enrollment on our system and with 10.13.4 just dropping we are now getting a window that pops up after the Jamf user initially logs into AD. It appears to have something to do with us binding to Active Directory and SecureToken.

The message displayed after first login to AD is:

"Enter a SecureToken administrator's name and password to allow this mobile account to log in at startup time."

We can bypass but not sure what future issues that could cause. We have not seen this window before 10.13.4 at all. Is there any fix for this or something new I need to be doing to bypass this extra step?

It appears someone has already opened a ticket with Apple:

https://openradar.appspot.com/38485212

AppleCare Enterprise Support as issue #100466781281

Thanks for any insight,

--Mike

33 REPLIES 33

blackholemac
Valued Contributor III

Same here and can verify that this did not occur with 10.13.3.

Hitting Bypass the first time will make the prompt go away from that user, but it still offers the prompt each time someone new logs in. An account SecureToken is what will be needed in the future with FileVault. The first login created at the Setup Assistant should have SecureToken.

Here is Rich Trouton's post to understand it: https://derflounder.wordpress.com/2018/01/20/secure-token-and-filevault-on-apple-file-system/

Honestly, I don't wish to enable FileVault in labs, I'm still eager to see an answer how to disable the prompts to deal with SecureToken, but at least the link explains what it is.

McAwesome
Contributor III

We're seeing this with machines bound to AD that create mobile accounts on login. We use this approach because it's proven a lot easier to clean up old accounts using it. Are your machines making network or mobile accounts on login?

m_donovan
Contributor III

I just had my first run in with this popup. A newly upgraded (10.13.4) DEP enrolled computer lost wireless. The only way to get the wireless profile functioning again was to run it back through DEP enrollment (other MDM reinstall methods failed). I had to create a local admin during the setup assistant and re-add the management account in the JSS record for some reason. After removing the temporary local admin account and attempting to log in with and AD account I got the popup about secure token.

gregdeichler
New Contributor II

Same behaviour here. 10.13.3 did not give us this prompt. We don't create a local admin account, and we don't want to. That has been completely fine up until now.

I am also getting tired of High Sierra. Every 10.13 point release so far has had some sort off issue to overcome.

alexjdale
Valued Contributor III

The writing is on the wall, it's time to abandon mobile accounts. It's not going to get any easier. Enterprise Connect is the future for a lot of us, whether we like it or not.

MikeT
New Contributor III

@McAwesome, I have the pre-enrollment setup to create a mobile account without prompting the user in the Directory setup.

McAwesome
Contributor III

@MikeT I talked with our Apple reps yesterday. This is part of a slow moving transition to how they handle FileVault accounts. They're trying to find a better way, but there's not going to be a quick patch. They're aiming for a better instance in the 10.13.5 beta, and they are actively seeking feedback on it. Like to the point where the Apple rep contacted me about it and not the other way around.

@alexjdale Enterprise Connect is explicitly not for the environments we use Mobile Accounts in. It's crap for multi-user machines or checkout machines, both of which we have set up with Mobile Accounts. In fact, we've been explicitly told by Apple not to use Enterprise Connect on these kinds of machines.

MikeT
New Contributor III

@McAwesome Thanx for the info. This is happening on accounts that have never had FileVault enabled. Could it possibly be occurring due to a policy I have enabled to redirect FileVault Recovery keys that is enabled on all macOS devices that is prompting it? ( aka FileVault Recovery Key Redirection).

af4a7a00c2644b5bac5d0d628c767ae0
Only 1% of staff utilize it now so I suppose I could disable to see if that makes this message go away. We block on student machines but the redirection is enabled for all.

Pacers31Colts18
New Contributor

@MikeT That policy shouldn't work on 10.13.4 devices. I have it not scoped to my 10.13.4 devices for the new policy in Filevault. Still is happening.

McAwesome
Contributor III

@MikeT From what I gather, it's a bug where it's popping up regardless of whether FileVault is enabled. All mobile accounts on 10.13.4 are going to see this on first sign in.

It looks like they're trying to fix it with 10.13.5. Here's something from the AppleSeed beta notes:

New MDM Payload SecureTokenAuthBypass This payload is designated by specifying com.apple.MCX as the PayloadType. If the cachedaccounts.askForSecureTokenAuthBypass key is set to true, this payload prevents authentication UI from being displayed when a mobile account is created. Suppressing the UI may prevent mobile accounts from being able to unlock a FileVault volume. It is available in macOS 10.13.5 and later and must be installed as a device profile. Example usage follows
<key>cachedaccounts.askForSecureTokenAuthBypass</key>
<!-- Suppresses the authentication UI which may appear when creating a mobile
account -->
<true/>

mtward
New Contributor III

If this is useful to anyone:

One way around this for now is to create a MobileAccount ahead of time if you know who the user(s) will be. The account(s) will have a secureToken

Create a new Mobile Account w/ SecureToken:

sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n $User

donmontalvo
Esteemed Contributor II

<cough><cough>...SecureTokenAuthBypass...</cough></cough>...check AppleSeed.apple.com forum...<cough><cough>...for the 10.13.N Beta...</cough></cough>...

--
https://donmontalvo.com

MikeT
New Contributor III

@donmontalvo Just read the .5 RN, cool.

AmigoDeluxe
New Contributor III

@mtward I tried your approach and it works fine except that the user's password won't get accepted in the FileVault authentication boot screen when the user restarts his Mac. His password will work everywhere else but not on the FileVault authentication boot screen. Any idea why?

Thanks
K

boberito
Valued Contributor

I'm just piling on. We're seeing the issue too. Set up machine through DEP/Prestage Enrollment and that first time logging in with the local admin created or an AD mobile managed account we get the Secure Token dialog. Hopefully fixed soon...

devlinford
New Contributor III

@AmigoDeluxe ,

Just tested this process from @mtward , and we're experiencing the same issues. The user is FileVault 2 enabled, they show up on the lock screen as a user who CAN login, but no known password works here...

Thanks,

szultzie
Contributor II

Yep ran into same issue. Here comes my rant...

Wonder what the person that said monolofic images are more work and "imaging is dead" and DEP is the new way of "provisioning" computers, thinks about how we have to do things now?

10.13.x has just been one problem after another, and I wish i, could stay with 10.12.x for lets say 4 more years, but new hardware doesn't allow for downgrading of the OS like it used to 5-6 years ago.

in 10.13.3 kernel extension blocking was introduce, then we got an MDM profile to fix them only if we used DEP, ok fine great works pretty good i guess. Now in 10.13.4 the same DEP workflow gets us the next issue in which 10.13.5 will i guess get rid of the prompt but not the issue itself?

Why cant a DEP and MDM computer that has a approved MDM profile not be able to allow for a SecurToken to be given to an account using MDM, or is that coming in 10.13.6? Apple seriously stop introducing "security enhancements" with out giving us admins a tool to make them useable.

So i did do some testing, and using my DEP enrollment workflow, basically use Internet Recovery to erase the drive and pull new OS directly form apple 10.13.4 during my test. I altered my PreTSage Enrollment profile form Jamf to make sure the Wizard makes me create a local admin account (so now i have my jamf management account , and then another local admin account) next i join to the AD domain using a policy from Jamf, reboot log in as an AD user and try to use the admin account created by the wizard to grant the SecureToken, and it says I don't have the rights i need.

Am I missing something? Shouldn't my account now have a secureToken and sice I am an admin should be able to grant other mobile accounts this secure token?

-Peter

KyleEricson
Valued Contributor

I tried to create a mobile account with the secure token but doesn't seem to work on 10.13.4
Any ideas why see my script below:

#!/bin/bash

if [ "$IS_LAPTOP" != "" ]; then
    #username=$(/usr/bin/osascript -e 'Tell application "System Events" to display dialog "Please enter the domain username or select Cancel." default answer "johdoe"' -e 'text returned of result' 2>/dev/null)
username=$(/usr/sbin/scutil --get ComputerName | cut -d- -f1)

#Create AD mobile account
/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n $username -D

#Make Admin
/usr/sbin/dseditgroup -o edit -a "$username" -t user admin

#Disable parental controls
sudo dscl . -mcxdelete /Users/$username
sudo rm -rf /Library/Managed Preferences/$username


user_password=$(/usr/bin/osascript -e 'Tell application "System Events" to display dialog "Please enter the domain user password or select Cancel." default answer "Trueace1"' -e 'text returned of result' 2>/dev/null)


sysadminctl -adminUser "Administrator" -adminPassword "myadminpassword" -secureTokenOn "$username" -password "$user_password"

szultzie
Contributor II

So according to Apple and some other posts (which i cant find to reference) i was under the impression that a secure token is given to an account created using the Apple First Run Wizard. At first I was creating an account in the Pre-Stage workflow, so i changed that not to create the admin account, and now when i run thru my DEP worklow i am asked part of the wizard to create my account. This account does not get a secureToken. When i don't use Pre-stage workflow on another test machine, and run thru the wizard and create the account, i get a secure Token, what gives? Is it something Jamf is doing wrong with the Pre-Stage payloads?

I am on Jamf Pro 10.3 and also joining the computer to the domain after using a splashbuddy workflow (in case that could be a potential issue, will be testing with out a bind and splash buddy tomorrow, in case that's the problem).

Can anybody confirm my findings? No secureToken when using DEP and a PreStage profile (and not creating an account using Jamf, but letting the Wizard create it)

Thanks
Peter

boberito
Valued Contributor

szultzie
Contributor II

So just a follow up, turns out I hit this PI.

(PI-005185) macOS DEP management account creation variations

"Management account home directory is created in /Users/ and UID is set to 501 (first account created)

If you enable the Account Settings payload none of the accounts created get a secureToken which should be granted to the first account created and is needed for filevault functionality."

So hopefully it gets fixed in the next version of Jamf Pro.

-Peter

jamesgreennew
New Contributor II

Yes we are seeing it here as well. Same scenario logging in for first time with 10.13.4 Macs and new AD accounts. But I wont rant since it was already done well above. 🙂 Another day... another bug in High Sierra.

emilh
New Contributor III

Has anyone had the time to check if this issue has been adressed in 10.13.5?

McAwesome
Contributor III

@emilh Sort of. It still exists, but there's now support for a configuration profile that suppresses it. I believe the domain for that is com.apple.MCS and the payload needs to be "cachedaccounts.askForSecureTokenAuthBypass=true"

Still trying to figure out the data privacy page though.

Johnny_Kim
Contributor II

I created a configuration profile with the payload. It does suppress the SecureToken prompt (DEP) but when checking the status, neither the local admin account that was created during Pre-stage enrollment or the AD account that I logged in got a secureToken.

afarnsworth
Contributor

@Johnny.Kim I had a similar issue but after logging in with an AD account without securetoken and enabling FileVault it will automatically assign SecureToken and encrypt the machine. Only other issue is that if you need to give the local admin account SecureToken the mobile account must be an admin account in order to do so. Standard accounts can not give other accounts securetoken

szultzie
Contributor II

So i wanted to start testing 10.13.5 but for some reason I cant used DEP to enroll in Jamf using a Pre-Stage profile. It just hangs on trying to enroll. I contacted Jamf Support to see what the issue is.

@afarnsworth What OS verions and Jamf version? Also what is your "imaging" process?

The past year has been a great roller coaster ride with Apple and Jamf. It seems every time Apple changes something Jamf has to fix it, but in turn breaking something else, and we seem to be stuck in this circle.

-Peter

KCH080208
New Contributor II

@McAwesome How do i import that into Jamf to create a profile to test?

cisdadmin
New Contributor

I am seriously on my way to Windows machines in the near future. I am tired of fighting issues. I've worked in a Windows environment for close to 20 years so, yes, "I know what I am getting into". Macs are expensive, have to buy new adapters each time we upgrade (kind of like the iPhones, iPads, etc.) JAMF is expensive, etc. We are a school district and I am positive I can save us money going to Windows.

kfalato
New Contributor

@McAwesome Or anyone else that could help, how do I create the plist for the configuration profile?

brwnbn
New Contributor III

I'm still getting this pop-up, anyone ever find a good way to suppress it?

cbrewer
Valued Contributor II

@brwnbn

Computer level config profile.
Preference domain: com.apple.MCX
Plist contents: {cachedaccounts.askForSecureTokenAuthBypass=true}

brwnbn
New Contributor III

@cbrewer Thank you!