Regaining admin credentials when admin has left the company

The admin for the metabase account at my company left a few months ago and his email is no longer active. How can we regain admin credentials?

Can you access the metabase database? If so try changing that user’s email in the core_user table

I'm having a similar problem

My company was bought by another company. So we've changed the email addresses last week, doing a migration with Google Accounts.

Since then, my admin user profile is blocked.
I've accessed metabase with the new email address and then turned it into a supersuser

But the admin page doesn't appear for this new user, even with the is_superuser as true

@rodolphoya Most likely you are signing in with a different user then.
If a user has is_superuser=true defined, then they are Admins.
It's difficult to understand what you mean with "migration with Google Accounts" and "my admin user profile is blocked".

Hey flamber

long short story

I had a google account old@old.com
The IT guys have created a new@new.com

I cant access metabase with the old@old.com, because i've changed the SSO domain, directly on the metabase application database and turned new@new.com as a superuser

@rodolphoya Yes, you need to change all the users email addresses in Metabase. This is a limitation with the information Metabase initial got from Google, so it's not possible to just switch domain on Google, since all the users are then seen a new users.

hmm, I've tested with one person here. it seems to not work. maybe because the passwords will be different if I just change the email address

i'm kind of strucked here. At least if I could get the admin privileges i would be greated

@rodolphoya
If you use Google Sign-in, then the password in core_user means nothing. Sounds like you are trying to login by inputting email+password, but that will not work.

But since you cannot have setup Metabase without creating one Admin user before enabling the Google Sign-in, then just request lost password for that account.
https://www.metabase.com/docs/latest/faq/using-metabase/how-do-i-reset-my-password.html

Are you even sure that your Metabase is connected to the application database you are editing?

Yeah, pretty sure.

I'm seeing updates in the core-user as the people here try to login in with their new email accounts

@rodolphoya Okay, something must have gone really wrong with your application database.
I don't know what you have changed.
If you just change the core_user.email from user@old.test to user@new.test, then they should be able to login with Google Sign-in and they would not know anything was changed.

the email sender is not working anymore :sleepy:

@rodolphoya Then follow the details described:
https://www.metabase.com/docs/latest/faq/using-metabase/how-do-i-reset-my-password.html#using-the-web-app-as-an-administrator

I'm seeing that the changes in the core-user table were not persisting.
I send the update commands, but then nothing happen.

This is strange, because the setting table, i'm able to change

@rodolphoya

  1. Which version of Metabase
  2. Which application database type
  3. You continue to write core-user, but the table is called core_user - computers are a stickler for things being completely correct.
  4. I don't understand what you mean by "persisting" and "update commands". Shutdown Metabase, make the changes you want, startup Metabase again.

You are manually editing the application database of Metabase. It's a great way of causing problems, so make sure you have backups.

  1. I'm using the last version (updated today)
  2. AWS RDS
  3. core_user
  4. I'll try it by shutting down, changing and then turning it up again. But I've took a ss to explain it. No matter how many times I update the table, the changes do not applies to the core_user. I've did the same for the setting and it worked

@rodolphoya So you are using Elastic Beanstalk with Metabase 0.40.3.1
If you cannot make changes to the database stick, then there must be some problem with your RDS. Perhaps it's being locked by Metabase, but then you normally should see errors.
In any case, avoid aliases - it just complicates things. You are only updating a single table.