Fix This Page
Navigation
You were redirected from a different version of the documentation. Click here to go back.

Configure Backup Agent for MONGODB-CR

On this page

In MongoDB 3.0 and later, MongoDB’s default authentication mechanism is a challenge and response mechanism (SCRAM-SHA-1). Previously, MongoDB used MongoDB Challenge and Response (MONGODB-CR) as the default.

The Backup Agent can use MONGODB-CR or SCRAM-SHA-1 to authenticate to hosts that enforce access control.

To authenticate using SCRAM-SHA-1 or MONGODB-CR, create a user in the admin database with the appropriate roles in MongoDB.

Note

In Ops Manager 1.8 and later, Ops Manager can manage agent authentication for you if you use Automation to manage the agents. With Automation, Ops Manager creates the users for each agent and configures the agent appropriately. See: Enable Username and Password Authentication for your Ops Manager Group for more information.

Procedures

Create MongoDB User for the Agent

Connect to the mongod or mongos instance as a user with access to create users in the database. See db.createUser() method page for more information.

To authenticate to sharded clusters, create shard-local users on each shard and create cluster-wide users:

  • Create cluster users while connected to the mongos: these credentials persist to the config servers.
  • Create shard-local users by connecting directly to the replica set for each shard.

MongoDB 3.0 and Later

To back up MongoDB instances running 3.0 and later, create a user in the admin database with an operation that resembles the following:

use admin
db.createUser(
   {
     user: "<username>",
     pwd: "<password>",
     roles: [ { role: "backup", db: "admin" } ]
   }
)

See Access Control for MongoDB 3.0 for more information on the required access.

MongoDB 2.6

To back up MongoDB 2.6 release series instances, create a user in the admin database with an operation that resembles the following:

use admin
db.createUser(
   {
     user: "<username>",
     pwd: "<password>",
     roles: [
        "clusterAdmin",
        "readAnyDatabase",
        "userAdminAnyDatabase",
        { role: "readWrite", db: "admin" },
        { role: "readWrite", db: "local" },
     ]
   }
)

See Access Control for MongoDB 2.6 for more information on the required access.

MongoDB 2.4

To back up MongoDB 2.4 release series instances, create a user in the admin database with an operation that resembles the following:

use admin
db.addUser(
   {
     user: "<username>",
     pwd: "<password>",
     roles: [
        "clusterAdmin",
        "readAnyDatabase",
        "userAdminAnyDatabase"
     ],
     otherDBRoles: {
        local: ['readWrite'],
        admin: ['readWrite'],
        config: ['readWrite']
     }
   }
)

See Access Control for MongoDB 2.4 for more information on the required access.

Host Settings

MongoDB agents interact with the MongoDB databases in your deployment as a MongoDB user would. Each agent must be authenticated and then granted privileges according to what their roles are on your deployment. As a result, you must configure your MongoDB deployment and your agents to support authentication.

You can specify the deployment’s authentication mechanisms when adding the deployment, or you can edit the settings for an existing deployment. At minimum, the deployment must enable the Kerberos authentication mechanism you want the agents to use.

Adding an agent as a MongoDB user requires configuring an authentication mechanism. Agents can use any supported authentication mechanism, but all agents must use the same mechanism.

For the purposes of this tutorial, you must ensure your:

  • Deployment supports Kerberos authentication and
  • Agents use Kerberos authentication.

See Enable Kerberos Authentication for your Ops Manager Group for how to enable Kerberos authentication.