I have forgot my mongodb root user password for the shared cluster of 3 nodes. I have gone through stack overflow for the same issue but was unable to replicate due to different configuration. Below is my configuration
mongodb version 4.4.
replication on 3 servers(nodes) using keyfile authentication.
all nodes are running in docker containers.
In case useful, I have other credentials that were created through root user for backup and read write permission but they dont have access to admin database.
Please guide me if you have any solution. thanks
unable to find anything to try
The official way of doing this is:
Restart the MongoDB without authorization, i.e. mongod --noauth ... or via configuration file
security:
authorization: disabled
Then you can logon without password and change credentials of the root user.
Attention: while the MongoDB is running without authorization, every user connects with root privileges, so you better restart the MongoDB in maintenance mode, i.e.
net:
bindIp: localhost
port: 55555
#replication:
# replSetName: shardA
#sharding:
# clusterRole: shardsvr
setParameter:
skipShardingConfigurationChecks: true
disableLogicalSessionCacheRefresh: true
Then you can connect only from localhost using port 55555 (which is not configured by other cluster members nor known by other users)
You need to do this only on the configuration server, because user accounts are stored there, not on the shards or mongos members.
However, there is a much simpler way to achieve the same, use the keyfile for authentication:
mongosh --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"
Related
I just installed MongoDB 4.4 on Ubuntu 20.04. Now, I want one user with a password to have full access (create database, write to it, delete it, etc.) over TCP port 27017. How can I do this?
First, I changed 127.0.0.1 to 0.0.0.0 in /etc/mongodb.conf.
Then, I created a new user:
$ mongo
use admin
db.createUser({user:"admin",pwd:"foo",roles:[{role:"userAdminAnyDatabase",db:"admin"}]})
Then, added these lines to /etc/mongod.conf:
security:
authorization: enabled
Then, restarted it:
$ sudo service mongod restart
Finally, I was able to connect to it both from the server and remotely (after adding TCP port 27017 to the list of inbound rules of my AWS EC2 security group):
$ mongo localhost:27017 -u admin -p foo
So I have a MongoDB cluster deployed on 8 VMs (2 config servers, 2 shards with 2 replicas each and 2 mongos instances).
I configured it all from command line and decided to configure the authentication afterwards.
For that I edited the /etc/mongod.conf of the config servers and mongos to enable auth like so:
setParameter:
enableLocalhostAuthBypass: false
security:
authorization: enabled
Then I restarted both mongod instances as well as the mongos instances, however, when I connect to a mongos I get the following warning: Access control is not enabled for the database. Read and write access to data and configuration is unrestricted
And when I create a user with only permission to read it can still write to a db...
Is there an error on the configuration file or am I missing something?
I seem to be a bit confused regarding the x509 certificate authentication in MongoDB.
TLDR:
I Created server- and client-certificates (signed by the same CA, but different CN and OU), created a user in the MongoDB using the subject name as username and successfully connected using the c# client + client certificates.
With the MongoDB Compass I was able to connect to and read from the server, using the server certificates as client certificates.
Why was I able to do authenticate using the wrong certificate? Is it not possible to control permissions on a per-certificate-basis?
Extended:
I Created a Self-Signed Root-CA using OpenSSL, which signed another certificate which is my Signing-CA.
Using this Signing-CA I created two more Certificates:
Server certificate (CN=Server1,OU=Servers,O=project,ST=SH,C=DE)
Client certificate (CN=Client1,OU=Clients,O=project,ST=SH,C=DE)
Having those certificates in place I started the MongoDB instance without authentication, initiated the replicaSet and created a user for the certificate using this command:
db.getSiblingDB("$external").runCommand({createUser: "CN=Client1,OU=Clients,O=project,ST=SH,C=DE",roles: [{role: "readWrite", db: "admin"}, {role: "userAdminAnyDatabase", db: "admin"}, {role: "clusterAdmin", db: "admin"}, {role: "root", db: "admin"}]});.
I restarded the server, this time using some more parameters to start with enabled authentication:
--replSet *replicaSetName* --port *port* --dbpath *path* --logpath *path* --tlsMode requireTLS --clusterAuthMode x509 --tlsCAFile *path* --tlsCertificateKeyFile *path* --tlsClusterFile *path* --auth
I was able to connect without an issue using the C# client, the MongoDB Compass worked aswell.
But when I tested other certificates to verify the security, I noticed that it was absolutely possible to use the server certificate and key file to connect to the server using the MongoDB compass.
I Could not only connect, but browse and modify data aswell.
I was under the impression that every client certificate has to have an associated account in the $external database and thus only has the permissions/roles I assigned/granted to this specific user account.
Is this behavior supposed to be happening?
Is it possible to create one user account per client-certificate and grant different permisisons on different databases?
Thanks for your attention and answers, have a good day!
It depends on how you have configured your mongod process. Assuming you have a configuration file for your mongod (default path is /etc/mongod.conf) you would look to see if you have net.tls and security.clusterAuthMode settings..
Example Configuration file with these settings:
storage:
dbPath: /data/db
journal:
enabled: true
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
net:
port: 27017
bindIp: 0.0.0.0
tls:
mode: requireTLS
certificateKeyFile: /etc/ssl/node1.pem
CAFile: /etc/ssl/ca.crt
clusterFile: /etc/ssl/node1.pem
processManagement:
fork: true
pidFilePath: /var/run/mongodb/mongod.pid
timeZoneInfo: /usr/share/zoneinfo
security:
authorization: enabled
clusterAuthMode: x509
replication:
replSetName: replset
Other things
Recently MongoDB switched from SSL to TLS so depending on the version you are using you may find SSL instead of TLS.
Also, you might be using a replica set, or you might not be. If using a replica set you need to decide how a replica set member will authenticate to the other members. Should it use a keyfile, or should it use x509 as well as ordinary database users.
Also, you will need to create at least one named database user. The system will allow root access to the connected user if it is bound to localhost and no other users exist. This is called the localhost exception. Missing these steps is an incomplete and insecure installation.
Socket/TLS connection and authentication are separate steps in the high level connection establishment process.
The word "connection" is used by people to refer to multiple separate operations and processes and when troubleshooting any of these you need to be very clear about what it is you are looking at/asking about:
Socket connection from driver to server
Authentication by the driver (doesn't happen on monitoring connections which still go through the socket connection process)
Client object creation (not strictly a connection at all, though many people sloppily/erroneously use the word "connection" to refer to the action of creating a client object - creating a client object itself doesn't connect anything to anywhere)
Performing operations (even a server with authentication enabled permits one to create socket connections to it and execute operations like the ismaster command without authentication)
You probably are meaning to ask about #2 but you tested either #3 or #4, which as you should now see isn't necessarily giving you the expected results.
When TLS is enabled and "insecure TLS" isn't, the server will validate the client's TLS certificate (and the client will validate the server's) during the socket connection process. The certificate being validated must be signed by the CA that the validator is configured with. At this point there isn't anything preventing the client from supplying the server's certificate to the server, if you managed to give the client the private key that goes with the server's certificate (which normally shouldn't happen). The server warns about this situation in the logs. Note that no authentication has happened yet.
If you are using X.509 authentication (which must be configured on the client side and is separate from supplying certificates used for the socket connection, e.g. use the authMechanism URI option) then, after a successful socket connection and any associated certificate verification, the driver will perform the authentication. At this point you need to have the server user created that matches the distinguished name on the certificate.
MongoDB has guides for both setting up TLS connections and X.509 auth, read through them and follow them exactly as written and verify each step of the way.
After initially installing mongodb and running mongod with security.authorization: enabled option, how do I authenticate myself?
I need to access Mongo Shell to create root account, but it requires authentication...
According to this guide you should
first create an admin account
enable authorization and restart mongo instance
When you run mongod with authorization: enabled it will ask for a password, unless you're connecting from the localhost, in which case you'll be able to connect and create users.
This is known as the localhost exception, and it's the way they allow you to create a root or better off a userAdmin on the database. It won't ask you for a pwd.
You can of course, launch mongod without autorization: enabled, create the user, and re-launch. I find the previous approach far more practical than this.
You can simply run the mongo shell and it will run on localhost port 27017 by default.
Connection URL: mongodb://localhost:27017/your-project
That will allow you to create root account without any password.
You can take help of this article,
and also the official MongoDB security options configuration.
Just upgraded from Debian8 to Debian9. My MongoDB instance was upgraded as well (2.4 -> 3.2). Authentication is enabled.
In 2.4 when logging from localhost you could simply connect via mongo and was granted administrative privileges:
mongo
After doing some research it seems to me that in 3.2 you MUST login via some user/password combination even from localhost. But that seems awfully inconvenient.
mongo localhost/admin -u superAdminUser -p
So my question is whether that is really true and you do need to always use user/password combination? Or maybe I missed something and logging as superuser from localhost is still possible with no user/password?
if you start Mongodb by the following command , you will need to insert user name and password
mongod --dbpath /var/lib/mongo/ --auth &
also check /etc/mongod.conf file , you can enable/disable authentication .
security.authorization : enabled
As I know there is no way to disable authentication on local host only .
you can disable/enable authentication for all hosts which want to connect to Database