Guide: MongoDB Security

6 MongoDB Authentication Features You Must Know About

What is MongoDB Authentication?

In MongoDB, authentication is the process of verifying the identity of a client. Clients could be administrators, users, applications connecting to the database, or MongoDB utilities. MongoDB does not enable authentication by default, and so a critical step for MongoDB security is to enable it. 

When MongoDB authentication is enabled, the database ensures clients and servers have permission to connect, restricts user actions to only those determined by their role, and enables tracking and auditing of system events on the MongoDB instance. This makes it possible to conduct forensic analysis in case of a suspected security incident.

In this article:

Key MongoDB Authentication Features

1. Database Authentication

MongoDB does not have a separate user directory—instead, authentication information is stored as part of MongoDB databases. To add user accounts to a MongoDB database, you create a user entity in a specific database—that database becomes the “authentication database” for that user, because it holds their authentication information. 

 

The user entity in a database controls the user’s access to all databases, as shown below. For ease of management, MongoDB recommends creating all user entities in the admin database (but this is not mandatory).

USE admin
db.createUser(
	{
	USER: “dataAnalyst”,
pwd: “s%C8ORN51AUM”,
roles: [
		{ ROLE: “readWrite”, db: “reporting” },
 { ROLE: “READ, db: “finance” },
 { ROLE: “READ, db: “sales” },
 ]
}
)|
 

2. Default Authentication

When authentication is enabled, by default MongoDB uses the Salted Challenge Response Authentication Mechanism (SCRAM) mechanism. This mechanism is based on the IETF RFC 5802 standard. It enables bi-directional authentication between client and server, with a tunable iteration count and per-user random salts. It supports both the SHA-1 and SHA-256 hashing functions.

3. LDAP Authentication

If your organization uses the Lightweight Directory Access Protocol (LDAP) as an authority for user access control, you can use it for authentication and authorization in MongoDB. MongoDB Enterprise Advanced provides LDAP integration, allowing you to authenticate and authorize users directly against your existing LDAP infrastructure.

4. Kerberos Authentication

Kerberos is an industry standard authentication protocol for large client/server systems. MongoDB Enterprise Advanced supports authentication using the Kerberos service. This means MongoDB can leverage existing authentication infrastructure and processes based on Kerberos, including Microsoft Active Directory.

5. Microsoft Active Directory Authentication

MongoDB Enterprise Advanced supports Microsoft Active Directory authentication with both Kerberos and LDAP. In this setup, the Active Directory domain controller can authenticate MongoDB users and servers running on Windows networks.

6. x.509 Certificate Authentication

MongoDB supports x.509 certificates, allowing it to integrate with existing information security infrastructure and certificate authorities. X.509 certificates can support both user and node-to-node authentication:

 

  • Users can authenticate to MongoDB using a client certificate instead of a self-managed password.
  • Cross-cluster authentication and communication between MongoDB nodes can be secured using x.509 membership certificates instead of key files, reducing administrative overhead and improving security by eliminating the need for a shared secret. The same certificates can be used to verify membership of nodes in replica sets and sharded clusters.

 

Depending on the type of communication, one or more Certificate Authority (CA) can be used by the server instance for certificate validation. For example, you can use one CA for client and server communications and another CA for internal cluster communications.

 

You can change certificates or key files, and even change the Distinguished Name, without stopping the MongoDB cluster.

How to Enable Authentication in MongoDB

Authentication is disabled by default, meaning anyone with access to the server can use the mongo command to access the entire MongoDB instance. This makes it critical to enable authentication for any database that is used for important business operations or stores sensitive data.

Once you have authentication in place, you can additionally define authorization. Permissions are either explicitly assigned to a role, inherited from another role, or both. You can use the default database roles, or specify new roles if they are insufficient for your purposes. 

You can also create Superuser roles that provide direct or indirect access to the entire system (but it is recommended to strictly limit the number of users assigned a Superuser role).

To enable MongoDB authentication and authorization:

  1. Create an administrator account.
  2. Start MongoDB without authentication at first.
  3. Connect to the server using the mongo shell from the server itself. The command below shows the default port, change it if you are using another port:
mongo mongodb://localhost:27017
  • Create an administrator in the admin database with a userAdminAnyDatabase role. This role provides the ability to create and modify roles and users on the current database except local and config.

 

The following example shows how to create an admin user and set their password:

> USE admin
> db.createUser(
{
USER: "Admin",
pwd: "<PASSWORD HERE>",
roles: [ { ROLE: "userAdminAnyDatabase", db: "admin" } ]
}
)
  1. Disconnect from the mongo shell (Ctrl+D).
  2. Locate the following code in the /etc/mongod.conf configuration file, and change disabed to enabled:
security:
authorization: "disabled”
  • Restart MongoDB by running this command:
sudo service mongodb restart

Once complete, any client attempting to connect to the server must authenticate via the default SCRAM authentication mechanism. 

See the documentation to learn how to set up more advanced authentication methods such as LDAP and Kerberos.

Related content: Read our guide to MongoDB authorization

How to Authenticate as a User in MongoDB

If you need to access a MongoDB database with authentication enabled, there are two ways to authenticate:

 

Authenticating using mongo shell

Connect to the MongoDB or mongos instance and run this command:

mongo mongodb://<host>:<port>

The shell will prompt for username and password, use appropriate credentials for the database you accessed.

 

Authenticate using the authentication database

If you know which is the “authentication database” for your user entity, run the following command against your authentication database. You’ll need to know the authentication method set up on the database—in the example below it is SCRAM-SHA-1.

db.auth("<username>", "<password>","SCRAM-SHA-1",FALSE)

This operation returns 0 if authentication is not successful and 1 when it is.

Best Practices for MongoDB Authentication

The following best practices can help you set up MongoDB authentication more effectively and securely.

Create Separate Security Credentials for Each Entity

Create login credentials for each entity (user, process, or device) that needs access to the database. Avoid a single admin account that is shared by multiple entities.

 

Having separate credentials for each entity makes it easy to define, manage, and track system access. If your credentials are compromised, this also makes it easy to revoke access without interrupting access by other entities.

 

This holds true for human users, service accounts, and internal communication: 

 

  • Developers, administrators, and DBAs—these users must all have unique credentials. Shared logins make it difficult to identify users attempting certain actions and limit the ability to assign fine-grained permissions. With a unique login, you can easily remove access for an employee leaving a project or an organization, without affecting others.
  • Applications—create separate login credentials for each application that accesses the database. This approach helps manage access when new applications are introduced and old applications are no longer in use. It is also possible to create multiple accounts for different services within a single application for more granular auditing and query logs.
  • Inter-node communication—configure internal authentication between the nodes in the replica set and the sharded cluster. This prevents unauthorized instances from joining the database cluster and prevents unauthorized data from being copied or moved to insecure nodes.

Use Centralized User Access Management

A MongoDB database manages authentication in one of two ways—within the database itself, or through integration with identity management systems such as LDAP and Kerberos. Integrating MongoDB into your existing authentication infrastructure allows you to centralize, standardize, and control user access. For example, if you need to revoke a user’s access in your central LDAP database, you can apply it to all systems immediately, including MongoDB.

Enforce Password Policies

Passwords must meet the minimum complexity requirements set by your organization and must be reset regularly. Low complexity passwords are easy to crack even if they are encrypted. High complexity passwords can also be cracked given enough time.

MongoDB Security with Satori

Satori’s data security platform enables streamlined access to data in MongoDB by automating access controls and security. With Satori, you can enable just-in-time access to MongoDB and have a unified place to store all logs and manage access control.

To learn more:

Last updated on

March 27, 2022

The information provided in this article and elsewhere on this website is meant purely for educational discussion and contains only general information about legal, commercial and other matters. It is not legal advice and should not be treated as such. Information on this website may not constitute the most up-to-date legal or other information. The information in this article is provided “as is” without any representations or warranties, express or implied. We make no representations or warranties in relation to the information in this article and all liability with respect to actions taken or not taken based on the contents of this article are hereby expressly disclaimed. You must not rely on the information in this article as an alternative to legal advice from your attorney or other professional legal services provider. If you have any specific questions about any legal matter you should consult your attorney or other professional legal services provider. This article may contain links to other third-party websites. Such links are only for the convenience of the reader, user or browser; we do not recommend or endorse the contents of any third-party sites.