I have a mongodb sharded cluster, with mongos machines, mongo nodes in replicate sets and config servers. MongoDB version is 3.02
The guy that set this up left the company a while ago and now I cant do simple things like show dbs or show collections
I have OS root in all these Debian machines, so I want to know how to reset mongo's root password so I can admin the database.
The apps that access this db seem to be working fine, using a user that has low privileges. I know the password for this particular user.
This is a production setup, so I can't afford to keep it down for more than a few seconds, tops minutes.
It depends on the types of users. For example, if you are using SCRAM, the basic steps to reset password would be:
Stop the mongod nodes
Disable authorization in mongod.conf
Restart the Replica set nodes
Connect to the replica set primary node using the mongo shell
Reset the your password by db.changePassword
I think this may work:
Stop your MongoDB instance
Remove the --auth and/or --keyfile options from your MongoDB config to disable authentication
Start the instance without authentication
Edit the users as needed
Restart the instance with authentication enabled
https://dba.stackexchange.com/questions/62976/how-can-i-enter-mongo-as-a-superuser-or-reset-users
This may not be the perfect answer, because I cannot test it. The base problem is of course that, that you cannot put your system into maintenance mode, where you can change admin password... But there is config file parameter security.transitionToAuth what you can add with rolling matter to your config file(s).
A mongod or mongos running with security.transitionToAuth does not enforce user access controls. Users may connect to your deployment without any access control checks and perform read, write, and administrative operations.
There are two options here
If you plan to upgrade to 3.4 this can be done without downtime:
MongoDB 3.4 allows Enforce Keyfile Access Control in a Replica Set without Downtime
You need to start all your members with --transitionToAuth(This will allow both authenticated and non-authenticated traffic for some duration)
Login to mongo shell on primary and create a userAdmin
Logout and login again using userAdmin
Create rootAdmin
Store the password in password manager
Disable transitionToAuth (Allow only authenticated traffic to replica set)
If you need to do this with existing MongoDB without upgrade:
Stop a secondaries in the replica set in a rolling manner. Disable authentication using keyFile options
Stepdown a primary and update its configuration to disable authentication.
Update you're the application to remove username and password from application config
Restart application
Create useradmin and rootAdmin in admin DB
Save passwords in the password manager
Enable authentication in the replica set
Start your application with the old config that includes username and password
Steps
Connect to the machine hosting your MongoDB instance
Open the MongoDB configuration file found in /etc/ folder using: sudo nano mongod.conf
Comment out the following code like so:
# security:
# authorization: enabled
Stop the MongoDB service: sudo service mongod stop
Start the MongoDB service: sudo service mongod start
Connect to the database using Robo3T or equivalent. With a connection to the admin collection, create a new admin superuser:
db.createUser({ user:"admin", pwd:"password", roles:[{role:"root", db:"admin"}] });
Go back and uncomment the lines from step 3. Then repeat steps 4 and 5.
You should now be able to authenticate with the new user you created in step 6 and have full access to the database.
Troubleshooting
If for whatever reason, after trying to restart your mongo service, you cannot connect to it, you can make sure the service properly started with: systemctl --type=service --state=active. If it has started, it will be in the list as mongod.service.
Mongo logs can also be found at /var/log/mongodb/mongodb.log but this is less likely to be helpful in this situation.
Related
I used mongodb on my local without authentication by running mongod as server and connecting it by just mongo as a user.
Now after creating users and running the server as mongod --auth i can connect using user id and pwd assigned by me.
The problem is while connecting back mongo with mongod it again gets connected to the database and whole database is visible again,this should not happen as I have enabled the authentication.
Using mongod as a server should block the users from getting access. Same is the problem for my personal server.
Is there any solution to enable the security permanently that is enable mongod --auth and not just mongod.
If I understand correctly, your concern is that restarting a mongod process without access control enabled allows you to access data without authentication. This is the expected outcome: a user with direct access to restart services or copy MongoDB data files has greater permissions than the mongod process.
Authentication only verifies remote client access to the mongod service: it does not encrypt or protect data files if a user has direct local read access. If you have an environment allowing remote and/or multi-user access, you should take steps to appropropriately limit access to your data files and service management.
If you want to secure data files from direct access, it sounds like you may be looking for Encryption at Rest or Disk Encryption. These security measures prevent direct read access to your data files or filesystem without appropriate credentials, but you still have to limit access appropriately and protect those credentials.
For general measures see the MongoDB Security Checklist.
Is there any ways or methods to start mongodb replication directly when mongod service start? I don't want to enter to shell and ON the replication?
Thanks!
You can create a mongod service which starts automatically when server starts.
First you need to create a configuration file(mongodb.conf) which will include configuration settings such as replicaSet name etc. Then create a service and install it using following command
mongod -f c:\mongod.conf --install
Then start the service using
net start mongodb
Read about configuration file here and
How to install mongo as service here
When you create a valid replica set in mongodb, your data will be asynchronously from the primary member to the secondary members in replica set
Having said that, you're not required to do extra efforts manually to get data replication done
When you do rs.slaveOk() on secondary, that allows you to query data from secondary members in the replica set.
It's a provision. It allows you to read from secondary provided that you're can tolerate the possible eventual consistent data. The replication does not happen when you do rs.slaveOk() on secondary
I'm not sure to understand. Your question was about service start. On my part, I install mongo on ubuntu and the service is not started with replicatet mode.
Finally, I disabled the first one and I created another service with the option --replSet myReplicat .
When you have only 2 servers, there is a problem with majority votes. On my part, I had 2 secondary after I stopped the primary and it was difficult to comeback with 1 primary and 1 secondary.
Effectively, the replication is always active. By default, all connections should go to the Primary. If you want to readonly from a secondary, you first enter the commande rs.slaveOk(). This command is active at session level. If you reconnect, you have to pass it again. It is not possible to put it at server side.
I have enabled the security.authorization setting in /etc/mongod.conf
security:
authorization: enabled
But I am still able to connect to the mongo shell without providing credentials.
mongo
Enabling security.authorization seems to enforce access control on the databases and the anonymous user doesn't seem to be able to perform any actions such as listing databases and/or collections.
I have attempted to enable auth in the /etc/mongodb.conf file, but this didn't seem to have any effect and I can still connect anonymously.
auth = true
How do I set the mongo shell to require authentication so that anonymous connections are blocked.
The authorization mode in mongodb does not work like mysql.
It will prevent non authorized or anonymous users to read or write the DB but it won't forbid people to connect to your DB.
Anonymous users will always be able to connect themselves but can't do anything.
If you want to block the connection from unknown users or server, you can enable the net.bindIp parameter to allow only the selected IP to connect to your database.
I have a mongodb replica-set of 3 members (version 2.4) in which the administrator user for the 'admin' db does not have the 'userAdminAnyDatabase' role.
This role is required for managing the users on all databases.
The roles I currently have are: [ "readWriteAnyDatabase", "dbAdminAnyDatabase", "clusterAdmin" ]
I tried updating roles for myself or creating a new user, however I have no permission to access db.system.users in the admin db.
I tried setting noauth=true but that did not help. When removing the keyFile as well, the db was not able to sync with the other members (obviously) and got stuck in RECOVERY state.
I found a similar question that refers to a stand alone db (no replica set) so it doesn't really help in this case.
What would be the best way to add this role while having minimal system downtime?
I would use mongodump and mongorestore to backup the data then rebuild node with right permissions and restore the data.
However this approach should work:
If you have locked yourself out then you need to do the following:
Stop your MongoDB instance
Remove the --auth and/or --keyfile options from your MongoDB config
to disable authentication
Start the instance without authentication
Edit the users as needed
Restart the instance with authentication enabled
As you are using mongo 2.4, that means you have MMAP as a storage engine.
my proposal will be:
create similar replica set on each host but different port, and set database directory on same media as current one.
configure all auth stuff same as running ones
stop old replica set members
MOVE database files to new directory excluding local
change port on new replica set
start it
As moving files to other directory is just a pointer change this will take some seconds.
Please test before implementation.
Any comments welcome!
We have 9 mongo nodes in our environment with:
1 mongos
3 config servers (mongod --configSvr)
9 mongod servers (shards or members of sharded replica-sets)
and we are trying to implement authentication on them.
I have done this in the past with a single server and it was really easy:
just add the admin user to the admin database
add a user on each database
I had to restart mongod with --auth option, but here it doesn't seem to work.
I've added the admin account to our mongos and for our sharded databases; I tried to authenticate as the user I had just created, but it didn't work.
I've tried creating an admin user on each database, and the other user accounts that we need, but it still didn't work.
I also tried making sure all of our mongo servers were running with the --keyFile option specified either on the command-line or in their /etc/mongodb.conf files, but that didn't seem to help.
When I try to authenticate as a given user, like so:
db.auth("user","passwd")
it fails and returns 0, as in false; not non-zero.
I seriously need all the help I can get, so please at least leave some suggestions on things I could try--I can't overstress this, any help is more than welcome since I don't seem to be getting anywhere just from following the official docs on managing/administrating mongo sharded clusters.
In a sharded cluster you should use --keyFile to allow all the members of the cluster to authenticate to each other. When you use this option, --auth is "assumed". Since there've been several version changes since you asked this question, the roles assigned to users are more granular now - you would need to have a 'clusterAdmin', 'userAdmin', 'dbAdmin', etc.
This page has more details about how to configure security in MongoDB for a sharded cluster.