• Security >
• Enable Authentication for a Cloud Manager Project >
• Enable Kerberos Authentication for your Cloud Manager Project

Enable Kerberos Authentication for your Cloud Manager Project

Overview

Cloud Manager enables you to configure the Authentication Mechanisms that all clients, including the Cloud Manager Agents, use to connect to your MongoDB deployments. You can enable multiple authentication mechanisms for each of your projects, but you must choose only one mechanism for the Agents.

MongoDB Enterprise supports authentication using a Kerberos service. Kerberos is an industry standard authentication protocol for large client/server systems.

Important

Setting up and configuring a Kerberos deployment is beyond the scope of this document. This tutorial assumes you have configured a Kerberos principal for each Agent and you have a valid keytab file for each Agent.

To authenticate MongoDB with Kerberos, you must:

1. Have a properly configured Kerberos deployment,
2. Configure Kerberos service principals for MongoDB, and
3. Add the Kerberos user principals for the Agents.

The Kerberos Authentication section of the MongoDB Manual provides more detail about using MongoDB with Kerberos.

Considerations

Kerberos (GSSAPI) is only available on MongoDB Enterprise builds. If you have existing deployments running on a MongoDB Community build, you must upgrade them to MongoDB Enterprise before you can enable Kerberos (GSSAPI) for your Cloud Manager project.

This tutorial describes how to enable Kerberos for one of your Cloud Manager projects and how to configure your Cloud Manager Agents to connect to your Kerberos-enabled deployment.

Note

If you want to reset Authentication and SSL settings for your project, first unmanage any MongoDB deployments that Cloud Manager manages in your project.

Procedures

These procedures describe how to configure and enable Kerberos authentication when using Automation. If Cloud Manager does not manage your Monitoring or Backups, you must manually configure them to authenticate using Kerberos.

See Configure the MongoDB Agent for Kerberos for instructions.

Configure an Existing Linux Deployment for Kerberos-based Authentication

If you use Cloud Manager to manage existing deployments on Linux in your project, all MongoDB deployments in the project must be configured for Kerberos authentication before you can enable Kerberos authentication for your project.

1

Navigate to the Clusters view for your deployment.

1. If it is not already displayed, select the organization that contains your desired project from the office icon Organizations menu in the navigation bar.
2. If it is not already displayed, select your desired project from the Projects menu in the navigation bar.
3. If it is not already displayed, click Deployment in the sidebar.
4. Click the Clusters view.

2

On the line listing the process, click Modify.

3

Expand the Advanced Configuration Options section.

4

Set the kerberosKeytab option.

If kerberosKeytab is not already set:

1. Click Add Option.

   Option	Value
   kerberosKeytab	Provide the absolute path to the keytab file.

2. Click Add.

3. Click Save.

When you have configured the Kerberos options for each deployment, you can proceed to enable Kerberos for your Cloud Manager project.

Enable Kerberos for your Cloud Manager Project

1

Navigate to the Authentication & TLS Settings dialog for your deployment.

1. If it is not already displayed, select the organization that contains your desired project from the office icon Organizations menu in the navigation bar.
2. If it is not already displayed, select your desired project from the Projects menu in the navigation bar.
3. If it is not already displayed, click Deployment in the sidebar.
4. Click the Security tab.
5. Click the Authentication & SSL tab.
6. Click Edit Settings.

2

Select Kerberos.

1. Check Kerberos (GSSAPI).

2. Input your SASL Service Name.

   The SASL Service Name is the Kerberos Service Principal Name for mongod or mongos.

3. Click Next.

3

Configure the LDAP Authorization Settings. (Optional)

Important

Using LDAP Authorization, MongoDB 3.4 allows authenticating users via LDAP, Kerberos, or X.509 certificates without requiring local user documents in the $external database. When such a user successfully authenticates, MongoDB performs a query against the LDAP server to retrieve all groups which that LDAP user possesses and transforms those groups into their equivalent MongoDB roles.

This feature is available only for MongoDB 3.4 or later.

If you do not use LDAP Authorization, you can click Skip.

If you use LDAP Authorization, complete the following steps.

1. Enter values for the following fields:

   Setting	Value
   Authorization Query Template	Specify a template for an LDAP query URL to retrieve the list of LDAP groups for an LDAP user.
   User to Distinguished Name Mapping	Specify an array of JSON documents that provide the ordered transformation(s) MongoDB performs on the authenticated MongoDB usernames. MongoDB then matches the transformed username against the LDAP DNs.

2. Click Use LDAP Authorization.

3. Provide the following values:

   Setting	Value
   Servers	Specify the hostname:port combination of one or more LDAP servers.
   Transport Security	Select TLS to encrypt your LDAP queries. If you do not need to encrypt the LDAP queries, select None.
   Timeout (ms)	Specify how long an authentication request should wait before timing out.
   Bind Method	Select either Simple or SASL. Important If you choose the Simple bind method, select TLS from the Transport Security because the Simple bind method passes the password in plain text.
   SASL Mechanisms	Specify which SASL authentication service MongoDB uses with the LDAP server.
   Query User	Specify the LDAP Distinguished Name to which MongoDB binds when connecting to the LDAP server.
   Query Password	Specify the password with which MongoDB binds when connecting to an LDAP server.
   LDAP User Cache Invalidation Interval (s)	Specify how long MongoDB waits to flush the LDAP user cache. Defaults to 30 seconds.
   Validate LDAP Server Config	Select True to validate the LDAP server configuration or False to skip validation. If True and the configuration is invalid, the MongoDB deployment will not start.

4. Click Next.

4

Configure SSL if desired.

1. Toggle the Enable SSL slider to Yes.
2. Click Next.

Note

See Enable TLS for a Deployment for SSL setup instructions.

SSL is not required for use with Kerberos (GSSAPI) authentication.

5

Configure Kerberos (GSSAPI) for the Agents.

You can enable more than one authentication mechanism for your MongoDB deployment, but the Cloud Manager Agents can only use one authentication mechanism. Select Kerberos (GSSAPI) to connect to your MongoDB deployment.

1. Select Kerberos (GSSAPI) from the Agent Auth Mechanism drop-down menu.

2. Enter Agent Credentials for the appropriate operating system:

   Tip

   Only configure the Agents or functions you installed. For example, if you did not install Backup, do not configure Backup.

   If using Linux, configure:

   Setting	Value
   <Agent> Kerberos Principal	The Kerberos Principal.
   <Agent> Keytab Path	The path for the Agent’s Keytab.
   <Agent> LDAP Group DN	Enter the Distinguished Name for the Agent’s LDAP Group. The LDAP Group DN is then created as a role in MongoDB to grant the Agent the appropriate privileges. Note You only need to provide the Agent’s LDAP Group DN if you use LDAP Authorization.

   If using Windows, configure:

   Setting	Value
   <Agent> Username	The Active Directory user name.
   <Agent> Password	The Active Directory password.
   Domain	The NetBIOS name of a domain in Active Directory Domain Services. Must be in all capital letters.

3. Click Save.

6

Click Review & Deploy to review your changes.

7

Click Confirm & Deploy to deploy your changes.

Otherwise, click Cancel and you can make additional changes.

←   Enable LDAP Authentication for your Cloud Manager Project Enable x.509 Authentication for your Cloud Manager Project  →

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.