Startup Security Utility - No administrator was found.

I am having a similar issue - here is the description why it happened to me. I called the Apple support and they explained to me, that my issue is probably not solveable so may the following be a warning for you, dear reader, what you should NOT do: Migrate your old MacBook Pro to a new MacBook Pro with T2 chip using Carbon Copy Cloner, instead of Apple's built-in migration assistant.

Here is what I did that lead to the catastrophy:

1. Unpacked my brand new MacBook Pro and booted it once to have a "temporary admin".
2. Used the Startup Security Utility (used the password of this temporary admin) to allow booting from an external HD
3. Upgraded my old MacBook Pro to Mojave and used Carbon Copy Cloner to make a clone of the HD
4. Booted the cloned HD on my New MacBook Pro (which worked like a charm because I allowed this inside Startup Security Utility)
5. Used Carbon Copy Cloner (CCC) to clone the external boot HD to the internal MacBook's HD
6. Removed the external HD
7. Rebooted my new MacBook
8. WORKED LIKE A CHARM: The new MacBook "feels" like the old one, my old admin user is there, all my apps are there, I can configure everything. Everything just works.
9. Well - not everything: When I tried to go back to the Startup Security Utility with the intension to now disable the right to boot from external HDs (to increase security, because I only wanted to allow this for my migration via CCC) the error message "No administrator was found." is coming up.

All my attempts to resolve this, e.g. by deleting PRAM or SMC or creating a new admin, then reboot and then try this one: All failed.

Now, I am sitting here with a brand new MacBook Pro and a seemingly unresolvable gaping security hole.

I cannot really believe that this is really an unresolvable issue, so I will try more Apple support employees by calling the support again and I will try to google even more. If I'll resolve it, I'll post the solution here.

If somebody solved it - would be glad to learn from you.

Thank you, Cyrus1111. I highly appreciated your answer as it was a great pointer for me to the topic "Secure Token", that is the underlying mechanism of all this.

Unfortunatelly, the above-mentioned solution did not work. Here is what I did:

1. I followed the instructions in http://www.theinstructional.com/guides/how-to-re-run-the-os-x-setup-assistant.
   (Basically, this can be done even easier just by entering sudo rm /var/db/.AppleSetupDone on your Terminal, but for being on the safe side, I executed all the steps described in TheInstructional.)
2. I rebooted and the Setup Assistant started.
3. Using the Setup Assistant, I created a brand new admin user.
4. After that, I opened a terminal window and used the tool sysadminctl to check, if my newly created admin is now actually having/owning the "Secure Token":

I entered: sysadminctl interactive -secureTokenStatus NameOfMyAdminUser

I got this result: sysadminctl[1371:100060] Secure token is DISABLED for user NameOfMyAdminUser

That means, that I am currently stuck in a situation, where each newly created admin user, no matter if I am creating him using the Setup Assistant or other means, is not receiving a Secure Token.

The effect of this is:

• No chance to use the Startup Security Utility
• No chance to use FileVault
• and maybe much more side effects

My next step was to contact the support of bombich.com, the Maker of Carbon Copy Cloner.

Mike Bombich, the founder and CEO was so kind to deeply dig into this case. He came up with this solution proposal. Thank you, Mike, for this! I did not try it yet, as this is a bit of a more lengthy operation - but I plan to try it, soon. It sounds extremely logical and might explain everything.

In the meantime I thought, it makes sense to share this with the community, as it might prove helpful to more people.

Mike B. (Bombich Software)

Oct 5, 10:27 AM EDT

Hi Mirko,

**** - this is indeed a problem and maybe you should warn everybody out there:
"Never use CCC's clone to migrate from a non T2 computer to a T2 computer - you will be screwed"...

For the record, I do basically say that:

Use Setup Assistant or Migration Assistant to migrate data from a CCC backup to a new Mac

But you're not screwed, this is just a delay. In this particular case, you can actually restore your Mojave backup to this newer Mac (because Mojave has all of the software components that are required by the newer hardware).

I now recall one other case where someone ran into this, and I remember now why it happened. I haven't reviewed your restore attempt specifically, but I'm guessing that you didn't erase the whole internal disk before restoring from your CCC backup. The existing APFS container retains references to those security tokens, and the tokens are linked to the original admin accounts. If you erase (or just replace) the system, but you don't also erase the whole APFS container, and then you restore a different system with different users into that APFS container, there's a mismatch between the new admin accounts and the old security tokens.

The solution is to boot again from the CCC backup, erase the whole internal disk, then restore the backup again to the new APFS container.

[... email shortened by Mirko ... ]

Thanks,
Mike

Mike Bombich
Bombich Software, Inc.

SUCCESS! 🙂 ✅

In the meantime, I tried the resolution suggested by Mike Bombich as described in my post from 6th of October, 2018 (please scroll to read it). My special thanks go to Mike - without him I would still be stuck. Here is what I did and it worked:

1. Boot from my Carbon Copy Cloner (CCC) clone (in my case from an external USB drive)
2. Erase THE WHOLE internal disk (leave no traces of the old APFS container as described in the post from Oct 6)
3. Create a new APFS disk (steps #2 and #3 are done with the built in Apple Disk Utility)
4. Clone from the external USB drive to the internal disk using Carbon Copy Cloner (CCC).
5. Reboot from the internal HD
6. After this, I opened up a Terminal and checked the token status of my admin user using sysadminctl interactive -secureTokenStatus NameOfMyAdminUser
7. It showed, that my admin user did not yet have a token, so I used this here to actually "give" a token to the user: sysadminctl interactive -secureTokenOn <user name> -password <user password> (with the correct credentials for <user name> and <user password>).
8. Done - SUCCESS.

I tested this here:

• Enter the Startup Security Utility: works ✅
• Change Preferences within the Startup Security Utility, e.g. disable booting from an external HD: works ✅
• I did set a Firmware password: works ✅
• I activated File Vault: works ✅

But I did run into a challenge with Microsoft Outlook's search feature: After the above-mentioned procedure, it did not work any more.

Here is a solution, how I was able to get it up and running again:

First of all, what did not work:

1. At very first, I tried to reindex my Spotlight as I assumed the new APFS container (see above) was "guilty" and that Spotlight for some internal security reason went into kind of a "safe mode", so I did this here: https://www.idownloadblog.com/2018/02/08/how-to-rebuild-spotlight-index-mac/
2. After allowing to reindex the about ~1 TB of data (about 3hrs later): Rebooted, Restarted Outlook: No success.
3. Then I tried this here: https://support.microsoft.com/en-us/help/2741535/outlook-for-mac-search-returns- no-results-and-task-items-are-not-displ
4. When I started the OutlookSearchRepair tool, an interessting error message poped up that mentioned, that some plugin necessary to index spotlight was not installed/not there/not active (even after starting Outlook). This sounded strange to me, as everything worked like a charm *before* I executed the above-mentioned repair activities (including setting the token): Maybe Spotlight "recognized" that something is new and deactivated it?
5. So the OutlookSearchRepair tool asked me, if it shall fix it: needs a reboot.
6. I said "yes", rebooted and started the OutlookSearchRepair tool again: It now offered to REINDEX OUTLOOK. I did that.
7. No success - after more than 1 hour of reindexing.
8. Then I tried to reindex Spotlight again, i.e. REPEAT STEP #1. My rationale: When the first time I did the indexing, this plugin was not installed, maybe now, that the OutlookSearchRepair tool installed it, it would work. So I redindex the whole Spotlight again, not only Outlook - and another 3hrs later: VOILA - SUCCESS - ALSO THIS ONE WORKED OUT: My Outlook now also works again like charm.

Thanks Mirko, still have a doubt (maybe because I'm a little bit dislessic). When you state:

3. Create a new APFS disk (steps #2 and #3 are done with the built in Apple Disk Utility)

you mean step #2 and #3 of the following:

1. Boot from my Carbon Copy Cloner (CCC) clone (in my case from an external USB drive)
2. Erase THE WHOLE internal disk (leave no traces of the old APFS container as described in the post from Oct 6)
3. Create a new APFS disk (steps #2 and #3 are done with the built in Apple Disk Utility)
4. Clone from the external USB drive to the internal disk using Carbon Copy Cloner (CCC).
5. Reboot from the internal HD
6. After this, I opened up a Terminal and checked the token status of my admin user using sysadminctl interactive -secureTokenStatus NameOfMyAdminUser
7. It showed, that my admin user did not yet have a token, so I used this here to actually "give" a token to the user: sysadminctl interactive -secureTokenOn <user name> -password <user password> (with the correct credentials for <user name> and <user password>).
8. Done - SUCCESS.

isn't it?

Tnx again Simon

1. Boot from my Carbon Copy Cloner (CCC) clone (in my case from an external USB drive)
2. Erase THE WHOLE internal disk (leave no traces of the old APFS container as described in the post from Oct 6)
3. Create a new APFS disk (steps #2 and #3 are done with the built in Apple Disk Utility)
4. Clone from the external USB drive to the internal disk using Carbon Copy Cloner (CCC).
5. Reboot from the internal HD
6. After this, I opened up a Terminal and checked the token status of my admin user using sysadminctl interactive -secureTokenStatus NameOfMyAdminUser
7. It showed, that my admin user did not yet have a token, so I used this here to actually "give" a token to the user: sysadminctl interactive -secureTokenOn <user name> -password <user password> (with the correct credentials for <user name> and <user password>).
8. Done - SUCCESS.

Got my MBPro repaired but the procedure doesn't work for me... (MBPro 13" 2018)

Hi Mirko_. This is the answer I got from Mike Bombich (the first way is known: just trying to enable secure token user via terminal).

Mike B.(Bombich Software)

Nov 9, 2:04 PM EST

Hi Simon,

You tried the first of three solutions to that problem. If you're in this position again, please try the other two suggestions. Specifically:

Option#2:

If the procedure above does not work for you...
We found one other mechanism that seems to convince the system to generate the secure token. If you start the process to enable FileVault, but cancel it at the last moment, the system should create the secure token:

1. Open the Security & Privacy Preference Pane in the System Preferences application
2. Click on the FileVault tab
3. Click the padlock icon in the lower-left corner to allow changes
4. Click on the "Turn on FileVault..." button
5. Choose the option to "Create a recovery key and do not use my iCloud account"
6. I know you're getting nervous at this point that you're about to enable FileVault, but that's not going to happen yet as long as you choose the option to create a Recovery key. Click Continue.
7. Click the Cancel button, then quit the System Preferences application

Option#3:Only the macOS Setup Assistant has the ability to create the first secure access token, so follow these steps while booted from the volume you're trying to repair:

1. Mojave+ only: Grant Full Disk Access to the Terminal application
2. Open the Terminal application and run the following commands, substituting your own volume name as applicable:

sudo rm "/var/db/.AppleSetupDone" sudo rm "/var/db/dslocal/nodes/Default/secureaccesstoken.plist"

1. Restart the system 4.Setup Assistant will ask you to create a new user. Create the new user account with default settings. A simple name like "tokenuser" will do, don't login with an Apple ID.
2. Immediately log out of the new user account, and log in using one of your own admin user accounts.
3. Open the Terminal application and run the following commands, substituting your own user names as applicable:

sysadminctl -secureTokenOn youraccount -password - -adminUser tokenuser -adminPassword - sysadminctl interactive -deleteUser tokenuser

Mike

Cheers.

Simon

Thank you to both Cyrus1111 and Mirko_; I was not aware of Secure Token before reading your posts. I, too, was unable to open Startup Secure Utility because of the "no administrator" message from it. I discovered that a user account's Secure Token can be enabled, without the need to erase and re-install as suggested by Mike Bombich (Mirko_'s post.) The command: sysadminctl interactive -secureTokenOn <user name> -password <user password> enabled the Secure Token for me, and I was again able to access Startup Secure Utility.

I hope this works for you.

Thank you dmbrownaa.

I tried that, but unfortunatelly, it does not work for me.

After entering sysadminctl interactive -secureTokenOn <user name> -password <user password> (with the correct credentials for <user name> and <user password>), the output is

sysadminctl[961:44152] setSecureTokenAuthorizationEna

bled 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.}

The user i used to execute this command is an Admin user. I read somewhere, that this command only works, if your admin user already has the token, so that he can "pass" this token to the other user who can "inherit" it.

I also tried creating new admin users, then reboot and then try if those newly created users are able to pass the token to my main user. No success so far.

I guess I will continue to research and if all fails, I will try Mike's suggestion.

Very interesting. Unfortunately I wasn't able to solve the proble. Maybe because I can't format the internel HD to APFS (I get an error). I must format in HFS+ and turn it into APFS from High Sierra but it's not the same thing.

Tnx

Very very very nice. I had the suspect that this was the procedure but have been unable to try it out because if failures in formattin internal hd (mbp 2018) in Apfs. Actually is @ Apple for repair. Hope the above procedure also works for me. 🎉🎉🎉

Hi Mirko. My MBPro is back repaired.

The following steps:

Erase THE WHOLE internal disk (leave no traces of the old APFS container as described in the post from Oct 6) -> ???

Create a new APFS disk (steps #2 and #3 are done with the built in Apple Disk Utility)

are here in this post or in another post as I can’t fin them. I’m aware of what to do but I would be happy to have confirmations.

Thanks Simon

Hi Simon,

here is a link that explains these steps (thanks to Mike Bombich):

https://bombich.com/kb/ccc5/preparing-your-backup-disk-backup-os-x#erase_apfs_co ntainer

Please scroll up in this post to my October 6 post for more details.

Good luck!

Best regards

Mirko

Hi Simon, you're absolutely right - this is it.

For performing step #2 and #3, you would use Apple's built in Disk Utility

Here is a guide, of how to make sure, that you leave no trace of the old APFS container, because if you would, then step #7 would not work: Preparing your backup disk for a backup of macOS | Carbon Copy Cloner | Bombich Software

Best regards, Mirko

Thanks Mirko (italian name, isn't it?).

Just a personal thought: I would perform a "zerodisk" from terminal before creating APFS from disk utility if it was precedently formatted in APFS. Just to be "more" sure although I do not love zeroing SSDs neither the continuous action of TRIMming. I believe an SSD should be erased as rather as possible.

Tnx Again

Simon