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:
AppleCare Enterprise Support as issue #100466781281
Thanks for any insight,
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.
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.
@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.
@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.
@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/>
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
@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?
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?
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"
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)
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.
@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
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.
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.