Unable to enable SecureToken

[jon_mann]

Hi All,

I'm running into an issue where for a subset of devices, I am unable to enable the SecureToken for a standard mobile user. I have a local admin account on these machines with a valid secure token. When attempting to grant a SecureToken from the local admin to the standard mobile user, I receive authentication errors on the commands. I've tried both formatting methods below.

bash-3.2$ sudo sysadminctl -adminUser local.admin -adminPassword PASSWORD -secureTokenOn mobile.user -password PASSWORD
2018-03-20 17:25:08.036 sysadminctl[8666:724459] ### Error:-14090 File:/BuildRoot/Library/Caches/com.apple.xbs/Sources/Admin/Admin-674/DSAuthenticator.m Line:94
2018-03-20 17:25:08.037 sysadminctl[8666:724459] ----------------------------
2018-03-20 17:25:08.037 sysadminctl[8666:724459] No clear text password or interactive option was specified (adduser, change/reset password will not allow user to use FDE) !
2018-03-20 17:25:08.037 sysadminctl[8666:724459] ----------------------------
2018-03-20 17:25:08.037 sysadminctl[8666:724459] Operation is not permitted without secure token unlock.

bash-3.2$ sudo sysadminctl interactive -secureTokenOn mobile,user
2018-03-20 17:51:32.467 sysadminctl[10440:783432] setSecureTokenAuthorizationEnabled error Error Domain=com.apple.OpenDirectory Code=5000 "Credentials could not be verified, username or password is invalid." UserInfo={NSLocalizedDescription=Credentials could not be verified, username or password is invalid., NSLocalizedFailureReason=Credentials could not be verified, username or password is invalid.}

I have confirmed that I am passing correct passwords and not making any mistakes. My initial suspicion was that this was an issue with escaping special characters or spaces however the issues persist when using passwords that don't contain either.

One thing that is unique about the configuration of the machines is the local admin account was recreated after it was initially created via the setup assistant (we used the jamf create user payload in order to recreate this). This was previously a method we used to allow our local admin account access to unlock the FileVaulted disk as the payload included the option to enable this recreated account for FileVault. Despite of this I have verified that this user is still considered user 501.

If anyone has any insight I'd be super grateful. AppleCare's solution was to wipe & restore which based on the scale and location of these devices, will prove very difficult.

Thanks,
Jon

[Wakko]

Jon,

Sounds like you just jumped into the same boat a lot of us are in or are about to join in as well. Since you mentioned a securetoken, it's clear that you're trying to use this workflow in macOS High Sierra. From my testing and understanding that workflow that used to work in Sierra "ain't gonna work no mas". This has everything to do with the securetoken.

A securetoken is only generated when an account that has gone through the setup assistance. That account is the only account that has a securetoken. When you are using the built-in "jamf create user payload' that is being process by root or the management account. These accounts were not created via the setup assistance. So they can not create/generate a securetoken. The second part of this is that a securetoken account, has the ability to create another user/account that has a securetoken as well.

1st machine
I took a machine that was running macOS Sierra. Had FV setup, enabled and recovery key was on the JPS. It also had the "localadmin" account that was created as part of our enrollmentcomplete policy. Our "localadmin" account does not decrypt, only the user account does. I upgraded the machine and that decrypting account had the sercuretoken. So if you have a machine, running macOS Sierra and it has FV enabled. When that machine is upgraded, that account will have s securetoken.

2nd machine
I then took another machine which was not FV'd, but ran through the same process as above. When it was upgraded the machine did not have any securetoken for any of the accounts. So the machine needs to have FV enabled to generate a securetoken.

3rd secanrio
I took a machine that had a fresh base instlal of macOS High Sierra. The first account when through setup assistant. Once enrolled it kicked-off our test enrollment policy. Which creates an additional account for FV decryption. It failed no matter what we tried. The error was something to the effect that "the accout does not have entitlement to escalte" the account.

So now I have some testing to do. On the first machine, I'm going to see if I could run a script as the securetoken user. Use it to try and create another account that is able to decrypt the disk. On the second machine, I'm going to enable FV on the account that went through the setup assistance and wait. Once it's done I hope that this account will have a securetoken. If it does then we don't have to worry about upgrading a machine that doesn't have FV enabled. Since we can enable it after the fact and still get a securetoken. The third machine was any additional test to help us with our theory.

I was going to run those test today. However, the weather is working against me today (located in the North East). My theory is that if we can run a script as the user that has a securetoken. Then maybe just maybe it can create another account that has the entitlement for FV.

Hopefully this helps and you don't spend any additional time going down that rabbit hole. Maybe this will speak a creative solution by the community. I've attached a sample file to show you how to check if the account has the securetoken entitlement.

[jon_mann]

Hi Echevarria,

Thanks for the response. Your results for machine 1 & machine 2 are interesting as Apple has an open bug that actually recommends turning off FileVault prior to upgrading to High Sierra for expected results. I can't seem to find the open radar, every AppleCare rep I spoke to mentioned this as an open issue. I believe the symptoms were opposite (if you had FileVault on you'd lose all secure tokens and vice versa)

What differs in my scenario is that the local.admin user was created via setup assistant (although recreated by the jamf payload) but it does display as having a valid secure token, it just seems unusable. Which machine is referenced in that image you supplied? On machine 3 does that newly created account seem to have a secure token?

[Wakko]

Jon,

Sorry for the delay, I have more news to report. I'm able that machine three did not have a secure token until I enabled FV. Once I enabled FV on that account and it kicked-off. I was able to see and verify the securetoken. I was then able to create another account via SysPrefs and that account got a securetoken. I was able to decrypt the disk with this account and password.

Machine one was also able to create a new account via SysPrefs. I was able to very that this account as well got a securetoken and in fact let me decrypt and log into the machine.

I don't know what else to say, cause I'm getting results that shouldn't be happening? Hey, it's Friday anything goes I guess. Let me know if you have any additional questions. I to will follow up if I have anything else to report

[donmontalvo]

Here is what we know after preparing to get our users upgraded to High Sierra:

1. JSS should have a valid FileVault 2 key, else expect preauth reboot issues.
2. FileVault 2 encryption should be completed before the first enabled user tries to enable another user, or deferred enablement might have issues.
3. If the password for the first enabled user is rotated/changed before that user logs out to complete deferred enablement, don't expect FileVault 2 to allow that account to be enabled, since the password at logout doesn't match the password at deferred enablement.
4. If the first deferred enabled user reboots/shutsdown instead of logging out, there may be issues enabling that account.
5. Run this command once per user per computer AFTER the first account has been successfully enabled for FileVault 2, to ensure newly FileVault 2 enabled LDAP users show up in the FileVault 2 preboot screen (EFI list refresh command: /usr/sbin/diskutil apfs updatePreboot /).
6. Apple knows High Sierra combined with FileVault 2 is half baked, but at least they're fixing it.

¯_(ツ)_/¯

@jon.mann wrote:

Your results for machine 1 & machine 2 are interesting as Apple has an open bug that actually recommends turning off FileVault prior to upgrading to High Sierra for expected results.

Would be great if you can produce an Apple ticket number for reference. We've got several tickets opened revolving around FileVault 2 key reissue, and Apple hasn't suggested decrypting as a fix. If they are taking that position, we'd like to reference the ticket number, if you're ever able to find it. :)

[jon_mann]

@donmontalvo Sorry for the delay. The AppleCare rep I spoke with refused to disclose further information. May just be an internal only bug? I tried pressing him again but he stayed sealed up on it.

[dstranathan]

Isn't there a way to provision a local admin account (i.e.; the Jamf service account) with a SecureToken at imaging/deployment time?

[jon_mann]

@dstranathan The only ways I'm aware of require placing a local admin's password in plain text inside the script which I would advise against.

[dgreening]

EncryptedStrings is your friend!

[el2493]

I'm going to be trying the following, in case anyone else wants a suggestion for a scripted way to enable secure token it for the Jamf service account. Note that this relies on https://github.com/jamfit/Encrypted-Script-Parameters so that you aren't entering the username or password for the service account or local admin account in the script. Our provisioning method also involves a tech logging in and creating a standard admin account (exampleadmin for the purposes of the script), then enrolling through the JSS site (so we don't use DEP).

#!/bin/bash -v

loggedInUser=$(stat -f%Su /dev/console)

## Use GenerateEncryptedString() function from Encrypted Script Parameters 
## (https://github.com/jamfit/Encrypted-Script-Parameters) to encrypt the 
## username and password of Jamf service account and password of standard
## admin account that should be currently logged in.  Copy-Paste the 
## "Encrypted String" outputs in the matching parameters in JSS, and copy-paste
## the "Salt" and "Passphrase" outputs into the corresponding variables of this script.

jaUserEncrypted=$4
jaUserSalt=
jaUserPassPhrase=
jaUserPWEncrypted=$5
jaUserPWSalt=
jaUserPWPassPhrase=
localAdminPWEncrypted=$6
localAdminPWSalt=
localAdminPWPassphrase

## DecryptString() function taken from Encrypted Script Parameters.  Will be  
## used in conjunction with the variables defined above to decrypt the values.

function DecryptString() {
    # Usage: ~$ DecryptString "Encrypted String" "Salt" "Passphrase"
    echo "${1}" | /usr/bin/openssl enc -aes256 -d -a -A -S "${2}" -k "${3}"
}

## Use DecryptString() function with the previously-defined variables 
## to define decrypted variables 

jaUser=$(DecryptString $jaUserEncrypted '$jaUserSalt' '$jaUserPassPhrase')
jaUserPW=$(DecryptString $jaUserPWEncrypted '$jaUserPWSalt' '$jaUserPWPassPhrase')
localAdminPW=$(DecryptString $localAdminPWEncrypted '$localAdminPWSalt' '$localAdminPWPassPhrase')

## Make sure the intended local admin user is logged in, if not throw an error

if [[ $loggedInUser = "exampleadmin" ]]; then
    echo "exampleadmin logged in"
    sysadminctl -adminUser $loggedInUser -adminPassword $localAdminPW -secureTokenOn $jaUser -password $jaUserPW
else
    echo "$loggedInUser logged in"
        exit 1
fi

exit 0

I'll be setting this to run on enrollment, so in theory it should check to make sure the standard local admin account is logged in (which should have a token), then add a token to the Jamf service account using the name and password of the local admin account and the name and password of the Jamf admin account.

I haven't fulled tested this yet, so no guarantees (just a suggestion if anyone else is looking for one)

[UESCDurandal]

We've found that using AD bound Mobile Accounts adds additional complications when it comes to provisioning Secure Tokens properly. Here's our workflow.

1. The Mac enrolls via DEP and creates an additional local administrator via the Prestage Enrollment settings. A technician logs into this user.
2. A login policy runs that executes a shell script which presents an AppleScript prompt asking for the username of the employee that this Mac will be assigned to. This username is then used to derive the proper computer name and a confirmation prompt is presented to the technician. Then the script proceeds to change the computer name, join AD, set the username as the computer owner within Jamf, and then run the following command to pre-stage the Mobile Account and set it so that Apple's Secure Token prompt does not appear at login.

/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n $userName -D

3. Simultaneously to that policy another login policy runs that initiates deferred filevault enablement for the local admin at next logout. When the technician logs out they are prompted to supply the password to begin FV encryption.
4. At this point the Mac would be deployed to the enduser, powered on at the normal login screen. The user connects to Ethernet and logs into their AD Mobile Account for the first time.
5. A login policy is run that executes a shell script to determine whether this user has a SecureToken. Since this user doesn't have one yet an AppleScript prompt appears asking the user for their password. The script then takes the user's creds alongside the local admin creds that are supplied as script parameter values and runs this command

"/usr/sbin/sysadminctl" 
      -adminUser "$Admin" 
      -adminPassword "$AdminPass" 
      -secureTokenOn "$loggedInUser" 
      -password "$loggedInUserPass"
## Update APFS Preboot environment
diskutil apfs updatePreboot /

This successfully applies a Secure Token to the AD Mobile User and updates APFS so that it's aware of the new user. And that's it!

[yadin]

I'm not clear if it's Apple or JAMF at fault, but this catch 22 needs to be fixed. Not being able to have fully functional machines with DEP is a real issue. If the first admin account is made via MDM enrollment at first boot, it best be a FULL REAL admin account including secure token. As is, you need securetoken to enable securetoken, and with out it you can't manage boot security. We're either hobbled or deploy Macs manually and throw away JAMF, neither is attractive.

[TTG]

You’re overcomplicating it. The only account who needs to be able to boot the Mac is the end user.

When would you need to boot the Mac as an IT Admin without the end user knowing you have his/her Mac. When would you have physical access to the machine without the user’s consent?

Only in case you need to off board an employee, and you need to recover company data but then you have the recovery key if you escrowed/redirected it correctly or if you have an institutional key.

I really don’t see why people make such a problem on the fact that only the very first account logging in (if admin) gets a Secure Token. It’s like that bu Apple design and it does make sense to me.

[Nix4Life]

on the T2 Devices, I like to have it for troubleshooting

[Heavy_D]

@frederick.abeloos So I would be interested in knowing what your option is for Mobile AD accounts. I have a local Admin account that now appears to get the the token but the first sign in is done by a mobile AD account that does not get the token.

This is very frustrating as I now do not se off another way of giving this user a token without physically touching the machine now, and before Catalina it was never an issue.

[TTG]

Hi @JarvisUno I still have to solid testing with Catalina and Mobile Accounts.

With everything we have seen over the last year regarding secure tokens, I don’t make any statements based on any documentation unless I have tested things over and over again :-(

So far for Catalina I only tested local accounts: secure tokens catalina

Next is testing mobile accounts and the bootstrap functionality of Catalina.

Things have been busy last few weeks, but this is indeed a burning item on my todo list.

[peaudunk]

@JarvisUno @frederick.abeloos Not able to test bootstrap functionality yet, but as long as the first Mobile Account is an admin I've been able to script granting it a token (after prompting for user password), encrypt, then use that mobile admin to revoke the token of the first user.

[TTG]

Yep I would validate that, as this has been the way to do it for local accounts if you
Logged In with an admin IT (management) account prior to the end user logging in or vice versa.

Question is, how did that local admin account get a token? How and when did you bind to AD etc and when and how was filevault enabled.

This would help me taking your situation into account when testing mobile accounts

[Heavy_D]

Original scenario on Mojave 10.14.+:
- Prestage Enrollment created the Administrator Account
- After completion of Enrollment the MOBILE AD account logs in.
- All JAMF scripts and policies fire off this includes Installation of packages, Scripts that Join the machine to the Domain, rename the computer from a CSV, and changes the MOBILE user to Admin all after the first restart of the machine.
- Included in the configurations and policies was an Individual Recovery Key, and at the time was set to Management Account to Enable FV2. In Security & Privacy FileVault tab HAD "Require FileVault 2" checked ON "Enable Escrow Personal Recovery Key" and "automatically encrypt and decrypt key" and the key was redirected to the JAMF Pro Server. Action: Apply Disk Encryption Configuration Require FV2: At next Logout
The computer would restart request for user to enable FV2 and the users password and it would show the generated key.
Note: That was working with 0 issues on Mojave all the way through 10.14.6

Fast forward to the Catalina Wine Mixer 10.15.1 release:
- Prestage Enrollment created the Administrator Account
- After completion of Enrollment the MOBILE AD account logs in.
All JAMF scripts and policies fire off this includes Installation of packages, Scripts that Join the machine to the Domain, rename the computer from a CSV, and changes the MOBILE user to Admin all after the first restart of the machine. - Included in the configurations and policies was an Individual Recovery Key, and at the time was changed to Current or Next User to Enable FV2. In Security & Privacy FileVault tab HAD "Require FileVault 2" checked OFF "Enable Escrow Personal Recovery Key" and "automatically encrypt and decrypt key" and the key was redirected to the JAMF Pro Server. Action: Apply Disk Encryption Configuration Require FV2: At next Login
The computer restarts and then requires user to enable FV2 at the following login this time not showing the generated key.
Note: This was working on 10.15.1 up until the latest Security Patch 10.15.2 Apple released and now no longer works.

Current Scenario: Administrator account gets the token, first user logging in MOBILE AD account does not get the token and FV2 now never enables.
Note: This is without changing a thing from the previously stated workflow set fourth on 10.15.1

[TTG]

Ok I can see the issue with the workflow and the changes in catalina indeed.

But Bootstrap token functionality in Catalina is supposed to fix that.

I’ll urgently need to test but: https://support.apple.com/guide/deployment-reference-macos/when-a-user-sets-up-a-mac-on-their-own-apd0815d5748/1/web/1

[Heavy_D]

@frederick.abeloos Thank you for that article, I read it but I am having a rough time understanding what I need to do to fix my situation. Is this something that's already available in Catalina but not in JAMF 10.17.1?

I also updated what happens on my end so you can have a better understanding of what takes place here.

I really want to get this fixed, so any assistance would be greatly appreciated.

Thanks Again.

[peaudunk]

@JarvisUno Yes, this is a case where Jamf is not yet fully feature compatible with Catalina.

[lbm5]

Anyone tested Bootstrap token with Mobile accounts and Jamf Pro 10.18?
Not having much luck here with macOS 10.15.2 and Jamf Pro 10.18.