3

I have a mongoDB replicaSet that has 3 DBs - PRIMARY/SECONDARY + Arbiter. All 3 were installed the same manner - meaning they have admin database with a default password.

Now - I want to change the default passwords. On primary/secondary it worked well.

mongo admin -u admin -p <password> --authenticationDatabase=admin
db.changeUserPassword("admin",<new password>)

However - in the arbiter it isn't working (even after adding rs.slaveOK() in the PRIMARY)

I'm getting:

2016-12-01T00:18:51.408-0800 E QUERY    [thread1] Error: Updating user failed: not master :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
DB.prototype.updateUser@src/mongo/shell/db.js:1319:15
DB.prototype.changeUserPassword@src/mongo/shell/db.js:1323:9
@(shell):1:1

Any ideas how to change arbiter admin password?

Boaz
  • 375
  • 1
  • 9
  • 16

2 Answers2

4

How do you log into an arbiter?

As at MongoDB 3.4, arbiters in a replica set do not replicate any data (including user/role details). The implication of this is that you can normally log into an arbiter via the localhost exception unless this has been specifically disabled by setting enableLocalhostAuthBypass to false.

There's a relevant feature request you can upvote/watch: SERVER-5479: Arbiter in authenticated replica set should allow and require login/auth for admin-only operations .

What if the arbiter had user data before it was added to the replica set?

In your specific case it appears that your arbiter already had some authentication data before the mongod was configured as a replica set member. This isn't an expected (or supported) deployment, so in order to remove or update the authentication data you need to start the arbiter as a standalone server.

To remove any user information:

  1. Stop the arbiter.

  2. Start the arbiter on a different port without --replSet, --keyfile, or --auth options to ensure other members of the replica set cannot connect to the arbiter while you are making changes in standalone mode.

    For example: mongod --dbpath /path/to/data --port 28000 --fork

  3. Authentication should now be disabled. Use the mongo shell to drop the admin database:

    mongo localhost:28000/admin --eval 'db.dropDatabase()'

  4. Shutdown the arbiter, eg:

    mongo localhost:28000/admin --eval 'db.shutdownServer()'

  5. Start the arbiter with your normal configuration.

You could also change the password (instead of dropping the admin database) but this might be confusing as arbiters aren't expected to have user data. The outcome of authenticating against an arbiter is undefined, and future implementation of SERVER-5479 is unlikely to support pre-existing data on arbiters. Once user/role information is replicated to arbiters, the data will be expected to be consistent.

Community
  • 1
Stennie
  • 1,250
  • 7
  • 12
  • Yeah. Found out that the problem is that the admin user was created before it turned into arbiter. So now I'm "stuck" with this password - since I can't change it – Boaz Dec 04 '16 at 16:31
  • You can remove the password by dropping the `admin` database on the arbiter in standalone mode: restart the arbiter on a different port without `--replSet`, `--keyfile`, or `--auth` options. Then `use admin; db.dropDatabase()`, and restart the arbiter with your normal configuration. You could also change the password (instead of dropping the admin database) but this might be confusing as arbiters aren't expected to have data. – Stennie Dec 04 '16 at 23:17
  • Awesome - can you post the last comment as an asnswer? I want to accept it for the "next generations" to google – Boaz Dec 05 '16 at 07:06
  • @Boaz Will update the answer, but can you confirm that my last comment helped resolve your authentication issue? – Stennie Dec 05 '16 at 09:20
  • Yes! The last comment is the "correct answer" as far as I'm concerned. Remove replset from config, restart, change password, bring it back to replSet – Boaz Dec 05 '16 at 15:40
  • @Boaz Thanks for confirming. Updated the answer :) – Stennie Dec 06 '16 at 05:14
  • 2
    As of SERVER-32205, dropping the admin database is prohibited. So this workaround is unfortunately not working anymore (since v3.6.3). – Kay Aug 07 '19 at 12:48
2

I'm late to the party but as of SERVER-32205, dropping the admin database is prohibited. So the workaround suggested by @Stennie is unfortunately not working anymore (since v3.6.3). However, there is even an easier workaround as long as the majority of the replica set ist still up and running:

  • shutdown the arbiter
  • remove the contents of the db folder: rm -rf [your-data-folder]/db/*
  • start the arbiter

The arbiter will join automatically the replica set. As long as the localhost exception is enabled (by using the enableLocalhostAuthBypass option), you are able to connect to the arbiter (only) from localhost and execute mongodb commands on the arbiter.

Kay
  • 121
  • 2