Posted on 03-31-2018 08:54 AM
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
Posted on 03-31-2018 11:20 AM
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.
Posted on 03-31-2018 11:56 AM
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?
Posted on 04-02-2018 09:17 AM
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.
Posted on 04-02-2018 01:18 PM
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.
Posted on 04-02-2018 01:59 PM
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.
Posted on 04-03-2018 06:22 AM
@McAwesome, I have the pre-enrollment setup to create a mobile account without prompting the user in the Directory setup.
Posted on 04-03-2018 06:58 AM
@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.
Posted on 04-03-2018 08:49 AM
@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).
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.
Posted on 04-03-2018 09:09 AM
@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.
Posted on 04-03-2018 03:17 PM
@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/>
Posted on 04-03-2018 03:31 PM
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
Posted on 04-03-2018 11:13 PM
<cough><cough>...SecureTokenAuthBypass...</cough></cough>...check AppleSeed.apple.com forum...<cough><cough>...for the 10.13.N Beta...</cough></cough>...
Posted on 04-04-2018 04:47 AM
@donmontalvo Just read the .5 RN, cool.
Posted on 04-13-2018 06:05 AM
@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
Posted on 04-13-2018 11:27 AM
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...
Posted on 04-17-2018 08:56 AM
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,
Posted on 04-30-2018 12:00 PM
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
Posted on 05-07-2018 09:24 AM
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"
Posted on 05-09-2018 03:45 PM
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
Posted on 05-09-2018 06:13 PM
@szultzie you aren't the only one... exactly what I'm seeing https://www.jamf.com/jamf-nation/discussions/28041/beating-a-deadhorse-securetokens-management-accou...
Posted on 05-15-2018 12:44 PM
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
Posted on 05-15-2018 02:07 PM
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.
Posted on 06-04-2018 02:13 AM
Has anyone had the time to check if this issue has been adressed in 10.13.5?
Posted on 06-04-2018 05:45 AM
@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.
Posted on 06-04-2018 11:20 AM
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.
Posted on 06-06-2018 12:42 PM
@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
Posted on 06-07-2018 08:09 AM
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
Posted on 06-07-2018 02:05 PM
@McAwesome How do i import that into Jamf to create a profile to test?
Posted on 06-13-2018 08:49 AM
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.
Posted on 09-26-2018 01:46 PM
@McAwesome Or anyone else that could help, how do I create the plist for the configuration profile?
Posted on 08-16-2019 11:44 AM
I'm still getting this pop-up, anyone ever find a good way to suppress it?
Posted on 08-16-2019 01:20 PM
Computer level config profile.
Preference domain: com.apple.MCX
Plist contents: {cachedaccounts.askForSecureTokenAuthBypass=true}
Posted on 08-21-2019 05:53 AM
@cbrewer Thank you!