Secure Token and FileVault on Apple File System
As part of Apple File System’s FileVault encryption on mac OS High Sierra, Apple introduced Secure Token. This is a new and undocumented account attribute, which is now required to be added to a user account before that account can be enabled for FileVault on an encrypted Apple File System (APFS) volume. To help make sure that at least one account has a Secure Token attribute associated with it, a Secure Token attribute is automatically added to the first account to log into the OS loginwindow on a particular Mac.
Once an account has a Secure Token associated with it, it can then create other accounts which will in turn automatically be granted their own Secure Token.
For the consumer user, this usually takes the following form:
- Secure Token is automatically enabled for the user account created by Apple’s Setup Assistant.
- The Setup Assistant-created user account with Secure Token then creates other users via the Users & Groups preference pane in System Preferences. Those accounts get their own Secure Token automatically.
However, Active Directory mobile accounts and user accounts created using command line tools do not automatically get Secure Token attributes associated with these accounts. Without the Secure Token attribute, those accounts are not able to be enabled for FileVault.
Update 1-20-2018: @mikeymikey has pointed out an exception to the rule:
Instead, the sysadminctl utility must be used to grant Secure Token to these accounts as a post-account creation action. In that case, the sysadminctl utility must be run by a user account with the following pre-requisites:
- Administrative rights
- Secure Token
For more details, please see below the jump.
There are a couple of ways to check from the command line if a particular account has the Secure Token attribute associated with it:
sysadminctl -secureTokenStatus username_goes_here
Note: The sysadminctl utility has multiple ways to provide the needed admin authorization to run. Please see this post for details.
dscl . -read /Users/username_goes_here AuthenticationAuthority
You can also check in Directory Utility to see if a Secure Token entry appears under the account’s Authentication Authority attribute.
Once it’s been verified if an account needs Secure Token, sysadminctl‘s SecureToken functions can be used to add it.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Usage: sysadminctl [[interactive] || [-adminUser <admin user name> -adminPassword <admin user password>]] | |
-deleteUser <user name> [-secure || -keepHome] | |
-newPassword <new password> -oldPassword <old password> [-passwordHint <password hint>] | |
-resetPasswordFor <local user name> -newPassword <new password> [-passwordHint <password hint>] | |
-addUser <user name> [-fullName <full name>] [-UID <user ID>] [-shell <path to shell>] [-password <user password>] [-hint <user hint>] [-home <full path to home>] [-admin] [-picture <full path to user image>] | |
-secureTokenStatus <user name> | |
-secureTokenOn <user name> -password <password> | |
-secureTokenOff <user name> -password <password> | |
-guestAccount <on || off || status> | |
-afpGuestAccess <on || off || status> | |
-smbGuestAccess <on || off || status> | |
-automaticTime <on || off || status> | |
-filesystem status | |
Pass '-' instead of password in commands above to request prompt. |
The command shown below should add Secure Token to a specified account
sysadminctl -secureTokenOn username_which_needs_secure_token_goes_here -password password_goes_here
If you want to be prompted for the account’s password, use the command shown below:
sysadminctl -secureTokenOn username_which_needs_secure_token_goes_here -password -
To see how the process of adding Secure Token to an account which doesn’t have it works, please see the video below. It will go through the following process:
- Using sysadminctl to check an account for its Secure Token status
- Using sysadminctl to check the logged-in account for its Secure Token status
- Using sysadminctl to grant Secure Token to the first account, using the logged-in account’s credentials and Secure Token.
- Using sysadminctl to check the first account to verify that Secure Token has been added.
To see how user accounts created in System Preferences’ Users & Groups preference pane automatically get Secure Token when created by an account with Secure Token, please see the video below. It will go through the following process:
1. Creating a new user account in the Users & Groups preference pane
2. Verifying via sysadminctl that the new user account has Secure Token
Ran the migration assistant from one machine to another and I ended up with a password protected disk and no users had secure tokens. The migration assistant threw errors (I forget which). I decrypted and encrypted the disk again and I was able to enable all users for filevault but curiously none appear to have the securetoken still.
Thanks for the well written article. I’ve been running into this with every new system I setup. I noticed that with the systems I migrated to High Sierra That were already FileVault enabled I didn’t have any issues with user not being able to unlock FV disk. I’m guessing because the account was already on the system that a token was passed? I’ll have to use commands in this article to test.
We create mobile accounts with scripts. Here is the behavior I am observing:
FileVault is enabled with one valid admin account
create additional mobile accounts via script inside the existing admin account.
use sysadminctl to turn on Secure Token for one of these scripted accounts
enable the user for FileVault in the FileVault section of the Security and Privacy preference pane.
restart. The mobile account user does NOT show up on the FV unlock screen.
Create a new local account with Users and Groups GUI and restart
Both the new local account and the mobile account show up at the FV unlock screen.
Workflow for this feels like it’s going to be messy for those of us in JAMF environments where the users are not admins. May have to create a script to temporarily raise the enduser creds to admin to run the sysadminctl command as them to add the token to other users?
^^ My feelings exactly. My organization is stumped right now, because we’re trying to create a workflow that would allow us to use JAMF imaging to lay down a base image before passing the computer onto the user. Unfortunately, this results in the local admin account NOT having a secure token. With no user account on the computer having a secure token, there is no way to create additional users that DO have a secure token — meaning there’s no user account that can enable FileVault. We don’t run into this problem if we create the account via Apple Setup, but that is much more time consuming than just netbooting an entire room full of computers and imaging them all at once.
Ugh, now I guess we need a pop-up dialog prompting the user to authenticate so an elevated script can turn it on and provide the password. This is exactly what we train our users NOT to do in extensive Phishing Training. I guess I will have to put it in Self-Service and present a dialog with the company logo, etc.
This nuked my occasional setup of a laptop where I install what’s needed, remove the account along with /var/db/.AppleSetupDone..
I’ve run into some interesting behavior re: secureToken and the pycreateuserpkg tool. I create a new user with SetupAssistant, and it receives a secureToken as expected. A config profile is pushed from my MDM server that enforces Filevault. I reboot to enable FV for that user. After login, I install my admin_user.pkg created with pycreateuserpkg. I go to System Preferences and enable this second user for FV disk access. If I run -secureTokenStatus I get a positive “enabled” response, but if I reboot I am only presented with my Setup Assistant-created user.
I’ve about had it with this and I’m hoping I can get some help. Somehow when I upgraded my personal machine to High Sierra I lost the secure token for my account. Now no accounts on my machine have a secure token.
I am trying to enable one so I can enable Filevault, but I do not know how to create an account with a secure token when no existing accounts already have one. I have deleted .AppleSetupDone to re-run Setup Assistant, but that also produced an account with no secure token.
Please let me know if you have any ideas!
Thank you all for this post and particularly rtrouton and mikeymikey.
I have found it very interesting because I am in the process of testing FileVault 2 on 10.13.3 for our work place for about 3 weeks now. We are using JSS 9.101.0 at this stage.
All our macs are imaged via DEP and all of our users are logging in using Active Directory Mobile accounts. The local “administrator” account is also being used as a management account and hidden, the local “administrator” account is created via JSS during either enrolment or DEP. We do not create any other account at all.
I am testing on both OSX Extended (Journal) and APFS formats:
-For OSX Extended (Journal) format: the local administrator local hidden account is able to turn on FileVault and enable FileVault for AD Mobile accounts afterward
-For APFS format: the local administrator local hidden account is NOT able to turn on FileVault.
-The command used to check for Secure Status is “sysadminctl interactive -secureTokenStatus $username_type_here” > the output is the “$username_type_here is DISABLED…..”
– SOLUTION: Use JSS to create a local account with administrative right called “filevault”, then run a script to enable secureTokenOn for this account “sysadminctl -adminUser administrator -adminPassword $administratorPassword -secureTokenOn filevault -password filevaultpassword”
where: $administratorPassword = your administrator password
After this script is run, it is found that both the local “administrator” and local “filevault” are ENABLED for secure token. Check by running the command “sysadminctl interactive -secureTokenStatus administrator” and “sysadminctl interactive -secureTokenStatus filevault”
The next stage is to log in with the local “filevault” account and turn on the FileVault and enable the mobile AD account at the same time.
This has just been tested on a brand new MacBook Pro about 3 hrs ago.
I hope this helps………!
We tested enrolling a macOS 10.13.4 computer on a JSS 9.101.4 and found:
1. The initial account (local admin account “adminuser” for example) is deferred enabled.
2. “adminuser” logs out and is prompted for password (which that user has NOT changed).
3. FileVault 2 is enabled for that user.
4. LDAP user logs in and gets “Enter a SecureToken administrator’s name and password to allow this mobile account to log in at startup time.” prompt.
5. “adminuser” enters username and password into the prompt.
6. LDAP user is now enabled for FileVault 2.
Pretty nifty…even if it involves an additional step in our Thin Provisioning process, works fine.
PS, if “adminuser” password is changed before it enters credentials to enable FileVault 2, the process no worky.
I’ve been struggling mightily to get any deployment automation at all that will yield an end result with a SecureToken enabled account . here’s my setup:
Tests are on Touchbar MacBook Pros (various models)
– No DEP
– Using (IMO a non-monolithic process with) DeployStudio 1.7.8 (using an external DS boot drive and a separate DS server, no netbooting)
– Workflow foundation is an APFS 10.13.4 (17E99) AutoDMG created Master (totally barebones)
– AD integrated enterprise environment, where users log in locally using AD creds and mobile accounts (especially on laptops)
– in-house Apple Profile Manager (10.13.4 / Server 5.6.1 (17S2109)
– Laptops (when things are working) get FV2 encrypted with an IRK in a config managed by the Profile Manager.
I’ve tried two different DS processes with this 10.13.4 (17E99) OS – they both yield the same result. Other than the SecureToken issue, everything else in my builds go 100% normally.
I don’t dare try and enable FV2 on these machines until this is sorted out. If anyone has any ideas I am all ears – would really appreciate any help!
Test #1:
Uses the native DeployStudio Account process for creating a hidden local admin user (ostensibly using dscl or some other “legacy” method). I can log in as the hidden local admin, and I can log in as an AD user, which creates a mobile account on login.
When I run sysadminctl -secureTokenStatus [username]
I get the same result.
sysadminctl[2874:27290] Secure token is DISABLED for user [local adminuser]
sysadminctl[2874:27290] Secure token is DISABLED for user [AD user]
Test #2:
Turned off the DeployStudio account creation process and turned off the “Skip Apple Setup” flag.
After the deployment was complete, upon startup, I use the GUI setup wizard to create a new (NON-hidden) local admin. Much to my surprise, this account did NOT get SecureToken enabled. Same thing also true when I logged in with an AD account (and creating the mobile account) – same results as before.
Am I the only one baffled by the Test 2 result? I get why accounts created by DS in Test 1 could fail – but why wouldn’t the ones created by Setup Assistant in Test #2 yield an admin account with an enabled SecureToken?
smiller, it seems I’m in the same boat as you, we image the monlithic way and basically it seems impossible to get any accounts with secure token enabled on them doing it this way.
I actually made a breakthrough on this just a couple of hours ago that i’ll describe in a comment after some sleep. FWIW I would not describe what we are doing as “monolithic” at all – it’s an automated installation process. Unfortunately DeployStudio is not able to create users the new way, and that’s the problem. Will post over the long weekend to try and help other folks out.
Could you tell us more about this breakthrough? SecureToken is a nail in my coffin 🙂
Sorry for the suspense. It appears that, at least with 10.13.4, the issue is that the *first* user that gets created on a freshly deployed system has to be done in a way that enables its SecureToken. Otherwise, there’s no way to get *any* user enabled. Here’s how we determined that – while working with an Apple Enterprise Support rep:
Attempt #1: We’d tried turning off the native user account creation process in DeployStudio, as well as disabling the Setup Assistant suppression, and running our standard build. After deploying and then going through the manual Setup Assistant process, the freshly minted admin user account was still NOT SecureToken enabled. I was very unpleasantly surprised.
I ran some queries following that attempt – and it turned out that one of our software installers (for a security product) was creating a user as part of its installation. So even though I had turned off admin creation in DS, there was still an older creation method being performed for a user *before* the manual process was undertaken. So, in…
Attempt #2: Performed a much simpler Deployment. I continued to leave the DS account creation and setup assistant suppression off, but also stripped the workflow down. I basically left all of the OS configuration items (AD binding, Profile manager enrollment, some environment-specific network scripts, etc.) and removed all of the software installers, so that they would run be run separately (more on that later). After this deployment, upon startup, I was directed to the setup assistant, and manually created the first user at the console. When I queried the system, the user was in fact SecureToken enabled – and that allowed me to use that account to enable others, including AD accounts, using the sysadminctl commands.
Finally, I was able to restart the system using a DS boot disk and kick off the workflow I’d created, which only had the installations that I’d removed from the original workflow, so that it could run the second half of our deployment processes, including the security software user.
It’s not a great workaround – many more steps than we previously used to do to get a machine built. It is definitely time to replace DeployStudio with other tools that are being maintained to use the newer methods for these critical processes.
I hope that helps folks, and if anyone has had a different experience please do share.
Looks like you’ve kinda just re-enforced what we knew already though sadly. At present it looks like there’s no way to get around this using Jamf imaging 😦
Yes I was hoping there was a way for automatically granting it to AD users in particular.
Apple’s method of embedding hardcoded passwords in scripts is just so bad for security.
Allan – I’m glad that the details were clear to you from everything else you’d read. If I’m being honest, there were two things that weren’t really clear to me until I went through this exercise:
1) Just how much the order of operations matter specific to user creation using non-sysadminctl methods. After everything I’d read, I was not really expecting to find that an AD user, creating a mobile account on their 1st login, going through the complete manual Setup Assistant, while physically typing on the machine, wouldn’t be granted a SecureToken.
2) How much the particular 10.13.x base OS image matters specific to SecureToken. I’m going to post below with some (hopefully) helpful hints on this for anyone that’s still using DeployStudio or similar tools that are not yet able to enable SecureToken for users on creation.
Here are a couple of things that I wish I’d had before embarking on the SecureToken/FV2 odyssey over the last couple of weeks:
1) I can confidently confirm that using an AutoDMG created base of 10.13.2 (17C88) on a MacBookPro11,4 and MacBookPro11,5 (pre-touch bar) that one can come out the other end in 10.13.4 (17E202) WITH SecureToken enabled users, at least with the tools we are currently using. It’s all about enabling FileVault at the right moment in the process. Will validate this on TouchBar units next week.
2) Using OS builds 10.13.3 and higher result in SecureToken problems as outlined by everyone here ad nauseam.
3) Here’s a script snippet you can run using ARD as root. It will list “just the facts, ma’am” – most things one would probably like to know vis a vis the state of SecureToken and FileVault2.
—–
#this script lists the hardware model, OS version and build, then audits all local admin or AD users for their SecureToken and FileVault2 Status.
date
sysctl -n hw.model
system_profiler SPSoftwareDataType | grep “System Version”
echo “Checking FileVault2 status…”
fdesetup status -verbose
fdesetup list -verbose
userList=`dscl . list /Users UniqueID | awk ‘$2 > 499 {print $1}’`
echo “Checking SecureToken status for local admins and AD users…”
for a in $userList ; do
sysadminctl -secureTokenStatus “$a”
done
—–
Output looks like this (I had to scrub a bit):
Wed May 30 17:50:20 EDT 2018
MacBookPro11,5
System Version: macOS 10.13.4 (17E199)
fdesetup: device path = /
FileVault is On.
FileVault master keychain appears to be installed.
Encryption in progress: Percent completed = 14
fdesetup: device path = /
lepatron,669A603E-[redacted]
rguy,8BB9D50A-[redacted]
Checking SecureToken status for the following users…
2018-05-30 17:50:21.826 sysadminctl[1650:14794] Secure token is DISABLED for user emergencyadmin
2018-05-30 17:50:21.864 sysadminctl[1651:14799] Secure token is DISABLED for user theguardian
2018-05-30 17:50:21.891 sysadminctl[1652:14803] Secure token is ENABLED for user lepatron
2018-05-30 17:50:21.937 sysadminctl[1653:14809] Secure token is ENABLED for user Guy, Regular
In my example:
– The system, a MacBookPro11,5 was deployed using a fully automated DeployStudio workflow. AD Binding, network config, profile manager enrollment, software installations…all handled in the DS workflow.
– The first step in the workflow is a Restore Master op, using a 10.13.2 (17C88) AutoDMG created master. ** I believe that 10.13.2 may be the last OS you can use and still use this approach. YMMV **
– The accounts “emergencyadmin” and “lepatron” were both created using DeployStudio’s native account creation options, with as much setup assistant suppressed as possible (Siri and the Privacy screens are not suppressable in DS 1.7.8).
– “theguardian” is a local account that got created by one of our security endpoint installers – a standard package step in a DS workflow. The important bit is that this user gets created before real humans get to try and log in.
– ”Regular Guy” is an AD user (domain\rguy) that now has an enabled SecureToken (isn’t that nice!?). That account was created the first time that Mr. Guy logged in to the Mac with AD credentials, and created his mobile account… but AFTER “lepatron” had already enabled their SecureToken.
How did “lepatron” enable SecureToken for “rguy”?
Where in the process?
and
What command was run?
Thanks!
@poolpog – i didnt see this question until just now, so the answer may be moot, but here goes, anyway. The important thing to call out here is this, from the above:
– The first step in the workflow is a Restore Master op, using a 10.13.2 (17C88) AutoDMG created master. ** I believe that 10.13.2 may be the last OS you can use and still use this approach. YMMV **
– This test was performed on pre-touch bar MacBooks – MacBookPro11,4 and MacBookPro11,5. I can’t say for sure if the TouchBar MacBooks were successful using this approach – and I’m inclined to say that they were not.
I have adjusted my DS deployment process (as a stopgap before retiring DS) to skip the Master restore part of the process; this instead relies on a separate OS install that happens prior to DS. I have outlined that in some more detail in a separate comment on this thread. Hope this helps.
Have you run into an issue where the only local admin account does not have a secure token? FileVault is enabled and the user is able to login on the FV login screen. This all came up when JAMF alerted me that the user’s Personal Recovery key was missing. We were unable to issue a new recovery key manually or using a script that worked with other users. Here’s the output when we tried to do it manually:
sudo fdesetup changerecovery -personal -verbose
fdesetup: use personal recovery key
fdesetup: device path = /
Enter the user name:username
Enter the password for user ‘username’:
Error: Unable to change key.
echo $?
99 Internal Error
Running securetokenstatus:
sysadminctl interactive -secureTokenStatus username
Secure token is DISABLED for user User Name
sudo diskutil apfs updatePreboot / did not help to enable secure token.
I read that disabling FV and then re-enabling should help but sudo fdesetup disable produced an error:
FileVault was not disabled (-69550)
Any help on this would be greatly appreciated!
John,
I was running into the issue where the only account on my machine was the management account laid down with the Jamf PreStage Enrollment. This account did NOT have a secureToken (with 10.13.4) but could enable FileVault in the GUI.
Additionally, I was able to get a secureToken by `# sudo sysadminctl mgmtAcct -password – -adminUser mgmtAcct -adminPassword -`
Again, only a single account. Run sudo as the management account, try to enable the management account for a secureToken using the management account as the admin user. It worked for me.
I had to enter the same password 3 times for the different needs, but it worked.
I think this just showed that the management account was in some way in a FileVault deferred status.
Anyway, with 10.13.5, this appears to not be an issue and my management account has a secureToken as soon as enrollment is complete.
Have they broke this in 10.13.6 Rich?
musi-temp:~ appleadmin2$ sysadminctl -secureTokenStatus AppleAdmin2
2018-07-11 12:50:08.306 sysadminctl[763:12717] Secure token is DISABLED for user AppleAdmin2
musi-temp:~ appleadmin2$ sysadminctl interactive -secureTokenOn AppleAdmin2 -password –
Enter password for AppleAdmin2 :
2018-07-11 12:50:32.759 sysadminctl[766:12885] setSecureTokenAuthorizationEnabled error Error Domain=com.apple.OpenDirectory Code=5101 “Authentication server refused operation because the current credentials are not authorized for the requested operation.” UserInfo={NSLocalizedDescription=Authentication server refused operation because the current credentials are not authorized for the requested operation., NSLocalizedFailureReason=Authentication server refused operation because the current credentials are not authorized for the requested operation.}
Hi
I have a 10.13.6 mac with an local admin account created by macOS setup Assistant it has a secureToken, but then i bind the machine to our AD which has the setting enabled for mobile accounts, then login as a AD user and get the prompt Enter a secureToken Administrators name and password to allow this mobile account to use file vault.
You can select bypass but would prefer we dont get this prompt in the first place for non filevaulted machines.
Try this to supress the dialog.. create a config profile, custom settings…
{cachedaccounts.askForSecureTokenAuthBypass=true}
works for me
Been fighting with this also. Our Deploy Studio workflow lays down 10.13.6 image and a local user account but that account does not have a secure token. So far there does not look like there is a way to create an account with a security token or add one to accounts unless you already have an account with a security token. We are looking at chaining our process to require the macOS installer to be run which will run the full OS setup. The account created during the setup will then have a security token. From there you can use that account to run scripts to create new accounts with security tokens and or add tokens to accounts the do not have them. Also seems that if you change an accounts password with the command line (not GUI) the security token for that account goes away and a new one needs to be created
I’m having issues with no account having a secure token after an upgrade, even when I delete the AppleSetupDone file and create a new admin accounting Setup Assistant the new account doesn’t receive a Secure Token. Anyone have any ideas as I”m all out!
Seems apple has not given IT administrators a way to create a secure token when you get into this type of situation. This is an issue for a lot of admins that used deploystuido or some other product to deploy images with out using the setup assistant to create the first Master account (which also creates a secure token) Apple needs to fix this.
Marc have you tried upgrading that computer to 10.14? I know upgrading from 10.12 to 10.13.6 automatically created tokens for the admin accounts. Maybe upgrading to 10.14 will also do this?
Marc – it’s hard to know how to answer your question on this without more detail on what you mean by “after an upgrade” in your description. But one thing appears constant based on my extensive pain/agony and troubleshooting: SecureToken is a chain of trust process. this means that…
Your first-ever created user *must* have a SecureToken, or you’ll never be able to enable any other accounts on the system, full stop.
Caveats: If you are using a deploy process that includes any account creation before a human touches the Mac, you’re probably going to be up the creek. This includes tools like DeployStudio – but it’s also important to remember that installer packages can also create user accounts. One of my issues in an environment I maintain was that one of the security software packages created a hidden admin account, which made it impossible to enable a SecureToken after deployment.
If you are using DeployStudio, and have an extensive deploy process that you haven’t migrated to more modern tools, you can work around this (at least in 10.13.6) by:
1) Starting with a “clean slate” vanilla Mac OS installation
2) Running the Apple setup assistant manually on that Mac so that you can be assured an admin account with a valid SecureToken (make sure validate at the Terminal before moving on – my preferred script reiterated below.)
3) Booting that Mac using external media or NetBoot, running the DeployStudio runtime while booted that way, and using a workflow that does *not* include an OS Master restore.
4) After completing your deployment workflow, boot normally, and re-run the ST/FV validation script. Review your list of users for anyone reporting “Disabled” and decide which ones need to actually be able to successfully log in/get past pre-boot FileVault.
For each ST disabled user that you want to enable for FileVault, you can either…
a) Log in as each user. Upon login, you’ll be prompted to enable the SecureToken with an already-ST enabled login and password,
– or –
b) Log in as your ST *enabled* user, and run this command in Terminal:
sudo sysadminctl -adminUser [admin user] -adminPassword – -secureTokenOn [user you are granting a SecureToken] -password –
5) re-run the validation script
6) Just to be all belt-and-suspenders about the whole thing, turn on Filevault. Reboot, and login as one of users you manually enabled using this process, to make sure you can actually do it. that never hurts. 🙂
here’s the script again (from earlier in the thread) to audit the state of SecureToken and FileVault2 for all the users. I hope this all helps.
#this script lists the hardware model, OS version and build, then audits all local admin or AD users for their SecureToken and FileVault2 Status.
date
sysctl -n hw.model
system_profiler SPSoftwareDataType | grep “System Version”
echo “Checking FileVault2 status…”
fdesetup status -verbose
fdesetup list -verbose
userList=`dscl . list /Users UniqueID | awk ‘$2 > 499 {print $1}’`
echo “Checking SecureToken status for local admins and AD users…”
for a in $userList ; do
sysadminctl -secureTokenStatus “$a”
done
Apple make FileVault things worse since 10.13.6.
Important development / question for everyone: I’ve had a few users suddenly have their SecureTokens mysteriously become Disabled, after being enabled and working normally for months. Does anyone know what could cause a SecureToken to be revoked, e.g, a number of bad password attempts, perhaps? in my case, the users that have exhibited this disturbing development are AD users. If anyone has any insight to how someone goes from Enabled to disabled without admin intervention, I would very greatly appreciate it.
I have a machine where none of the users have a SecureToken. Machine is on 10.13.6 and I am not sure how it got in this state. 10.14.2 seems to offer some hope but I am wondering if I will get away with upgrading this machine while it doesn’t have any SecureTokens?
We have the same issue. Used a script to create the default account now these systems have no account with a security token. whats new in 10.14.2 that has changed this? Has apple added a command to create a security token for systems that have none?
Thought I’d leave this note here for others, I also had the issue where a hidden account created did not have a secure token, I was able to create the secure token, but still couldn’t use the account to unlock a FileVault drive. To enable this feature you need to update the preboot information via diskutil
diskutil apfs updatePreboot /dev/diskXsX
after running that the new secure token account can unlock the FV volume.
Thanks Jon. That’s helpful. Now we need apple to give us a way to create a secure token for a system that never had one. There seems to be no way to automate creating the first account with a secure token unless you are using MDM.
Howdy, folks. Is there anything wrt SecureToken that is improved in macOS 10.14.X? Specifically, is there a way to add ST to a user if no user on the system has ST? Will there ever be?
Thanks
-pog
Yes above mentioned all I accepted .
I was having 1 admin and 1 user account ,all 2 account enabled the secure token.
Issue is by every restart showing only admin login there is no user login account but logout from admin am able see the user account.
I tried recreated the user account and showing now all the account.
Is there without recreate the account have to make it visiting both the account.
Is there any way to do this via for a guest account..? Guest account does not have a password so I cannot find a work around for our labs.
I can’t think of a situation where a lab “user” would need a SecureToken. Doesn’t mean there isn’t an edge case, just that I can’t think of one.
What are the environment requirements that promulgate your inquiry?
This still comes in handy today, and even more so with the advent of the “Volume Owner” requirement for admins performing macOS updates/upgrades. At the time of this reply, SecureToken enabled user is also Volume Owner (yes. there can be more than one Volume Owner.).
Nice to know, for lab admins and their helpers.
FileVault does not have to be enabled, but admins and their helpers still need to be granted a SecureToken, at least in macOS Monterey.