Welcome to Knowledge Base!

KB at your finger tips

Book a Meeting to Avail the Services of MongoDB overtime

This is one stop global knowledge base where you can learn about all the products, solutions and support features.

Categories
All

MongoDB

Configure AWS Integration — MongoDB Cloud Manager

Configure AWS Integration¶

On this page

  • Considerations
  • Rolling Resync onto New EC2 Instances
  • Update a Replica Set’s Hostnames

Important

The ability to provision MongoDB servers in AWS using Cloud Manager was retired in October 2017.

  • Any existing clusters continue as they are.
  • This retirement impacts DNS entries in the following ways:
    • Entries for existing servers continue to resolve to the same IP address to which they currently resolve until at least January 1, 2023.
    • Servers that undergo a change of IP address due to maintenance or an instance stop/restart will no longer be resolvable via their mongodbdns.com hostname.
    • All existing mongodbdns.com hostnames will stop working in May 2023.
  • Cloud Manager can manage hosts provisioned directly through AWS . See Provision Servers for Automation .
  • If you are interested in fully managed provisioning on AWS , evaluate MongoDB Atlas.

If you want to continue using Cloud Manager to manage these deployments, update the hostname for each host using one of the following methods for a replica set:

  • Rolling Resync onto New EC2 Instances
  • Update a Replica Set’s Hostnames

Considerations¶

These procedures involve stepping down the old primary and triggering at least one election for a new primary. All writes to the primary fail during the period starting when the rs.stepDown() method is received until either a new primary is elected, or if there are no electable secondaries, the original primary resumes normal operation. For MongoDB versions 4.0 and earlier, all client connections are closed.

Consider performing this procedure during a maintenance window during which applications stop all write operations to the cluster.

To learn more about elections, see rs.stepDown() behavior and Replica Set Elections .

Rolling Resync onto New EC2 Instances¶

1

Create a new EC2 instance for each member of the replica set.¶

2

Replace each non-primary replica set member with a new EC2 instance.¶

  1. Add a new instance to the replica set using its EC2 hostname. To learn more, see Add Members to a Replica Set.
  2. Wait for the initial sync to complete. To learn how to get the status of an initial sync, see the MongoDB manual.
  3. Remove one old replica set member with a mongodbdns.com hostname. To learn more, see Remove Members from Replica Set.

Repeat for each non-primary replica set member.

3

Change your application connection string to use the AWS EC2 hostnames.¶

4

Replace the primary with a new EC2 instance.¶

  1. Add the last new instance to the replica set using its EC2 hostname. To learn more, see Add Members to a Replica Set.

  2. Wait for the initial sync to complete. To learn how to get the status of an initial sync, see the MongoDB manual.

  3. Connect to the primary and step it down. To learn more, see rs.stepDown() .

    Note

    Stepping down the primary triggers at least one election for a new primary. To learn more about elections, see Replica Set Elections .

  4. Remove the old primary with the mongodbdns.com hostname from the replica set. To learn more, see Remove Members from Replica Set.

Update a Replica Set’s Hostnames¶

Follow the Change Hostnames while Maintaining Replica Set Availability procedure in the MongoDB manual.

An overview of the linked procedure is as follows:

1

Connect to the primary.¶

2

Remove a secondary member from the replica set and re-add it using its EC2 hostname.¶

Repeat for each non-primary member of the replica set.

3

Change your application connection string to use the AWS EC2 hostnames.¶

4

Reconnect to the primary and step it down.¶

Note

Stepping down the primary triggers at least one election for a new primary. To learn more about elections, see Replica Set Elections .

5

Connect to the new primary.¶

6

Remove the old primary from the replica set and re-add it using its EC2 hostname.¶


Stay Ahead in Today’s Competitive Market!
Unlock your company’s full potential with a Virtual Delivery Center (VDC). Gain specialized expertise, drive seamless operations, and scale effortlessly for long-term success.

Book a Meeting to Avail the Services of MongoDBovertime

Stop Monitoring a Process — MongoDB Cloud Manager

Stop Monitoring a Process¶

On this page

  • Understand the Objectives
  • Complete the Prerequisites
  • Follow These Steps

This tutorial shows you how to stop monitoring a process . Once you stop monitoring a process, Cloud Manager stops displaying its status and tracking its metrics.

Understand the Objectives¶

Learn how to use the Cloud Manager Administration API to:

  • Find the host ID for the process.
  • Stop monitoring the process that matches the host ID.
  • Verify that Cloud Manager no longer monitors the process.

Complete the Prerequisites¶

Complete these prerequisites before you complete the tutorial.

  • Configure your access to the Cloud Manager Administration API .
  • Get the permissions needed to change monitoring settings. You need one of the following roles:
    • Project Monitoring Admin
    • Project Owner
  • Terminate the backups for the process before you stop monitoring it.

Follow These Steps¶

Complete all the following steps to use the API to stop monitoring a process.

1

Find the host ID for the process.¶

Use the Get One Host by Hostname and Port resource to find the process and retrieve the id value.

Learn What This Step Does¶

The Get One Host by Hostname and Port resource uses the hostname and port you specify to find the process. Then, it returns information about this process. You can find the id needed for the next step in the response.

Issue This Command¶

Copy the following curl command. Paste it into your preferred terminal or console. Replace the displayed placeholders with these values:

Placeholder Description
{PUBLIC-KEY} Public part of your API key.
{PRIVATE-KEY} Private part of your API key.
{PROJECT-ID} Unique identifier of the project that owns the host.
{HOSTNAME} Primary hostname that Cloud Manager uses to connect to the instance. This may be a hostname, an FQDN , an IPv4 address, or an IPv6 address.
{PORT} Port on which the process listens.

Replace the placeholders in the command, then execute it.

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/hosts/byName/{HOSTNAME}:{PORT}"

Copy the Host’s ID¶

In the response body, copy the value returned in the id field. You need the value for the next step.

Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
{
  "alertsEnabled" : true,
  "aliases": [ "server1.example.com:27017", "203.0.113.3:27017" ],
  "authMechanismName" : "SCRAM-SHA-1",
  "clusterId" : "<cluster-ID-1>",
  "created" : "2021-04-22T19:56:50Z",
  "groupId" : "<project-ID-1>",
  "hasStartupWarnings" : false,
  "hidden" : false,
  "hostEnabled" : true,
  "hostname" : "server1.example.com",
  "id" : "{HOST-ID}",
  "ipAddress": "203.0.113.3",
}
2

Stop monitoring the process that matches the host ID.¶

Use the Stop Monitoring One Host resource to stop monitoring the host.

Learn What This Step Does¶

The Stop Monitoring One Host resource doesn’t actually delete the host. The resource deletes the host from the list of hosts that Cloud Manager monitors. This removes the process from monitoring.

Issue This Command¶

Copy the following curl command. Paste it into your preferred terminal or console. Replace the displayed placeholders with these values:

Placeholder Description
{PUBLIC-KEY} Public part of your API key.
{PRIVATE-KEY} Private part of your API key.
{PROJECT-ID} Unique identifier of the project that owns the host.
{HOST-ID} Unique identifier of the host for the process. Use the id from step 1.

Replace the placeholders in the command, then execute it.

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --request DELETE "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/hosts/{HOST-ID}"
3

Verify that Cloud Manager no longer monitors the process.¶

Use the Get One Host by Hostname and Port resource again to attempt to find the process using its hostname and port. Then, verify that details returns No host with hostname and port {HOSTNAME}:{PORT} exists in group {PROJECT-ID} .

Learn What This Step Does¶

The Get One Host by Hostname and Port resource uses the hostname and port you specify to find the process. Then, it returns information about this process. You can tell that Cloud Manager doesn’t monitor the process if the details value in the response is No host with hostname and port {HOSTNAME}:{PORT} exists in group {PROJECT-ID} . This means that Cloud Manager can’t find the host in the list of processes that it monitors.

Issue This Command¶

Copy the following curl command. Paste it into your preferred terminal or console. Replace the displayed placeholders with these values:

Placeholder Description
{PUBLIC-KEY} Public part of your API key.
{PRIVATE-KEY} Private part of your API key.
{PROJECT-ID} Unique identifier of the project that owns the host.
{HOSTNAME} Primary hostname that Cloud Manager uses to connect to this instance. This may be a hostname, an FQDN, an IPv4 address, or an IPv6 address.
{PORT} Port on which the process listens.

Replace the placeholders in the command, then execute it.

curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest \
     --request GET "https://cloud.mongodb.com/api/public/v1.0/groups/{PROJECT-ID}/hosts/byName/{HOSTNAME}:{PORT}"

Check the Response Details¶

In the response body, check the value returned in the details field. If details returns No host with hostname and port {HOSTNAME}:{PORT} exists in group {PROJECT-ID} , you succeeded. Cloud Manager no longer monitors the process.

Read article

Install MongoDB Agent — MongoDB Cloud Manager

Install MongoDB Agent¶

Installation Instructions in Cloud Manager Interface

Cloud Manager displays the MongoDB Agent install instructions after you choose your MongoDB Agent download. You can copy all the necessary commands from the Cloud Manager.

Caution

Please review the MongoDB Agent Prerequisites before installing the MongoDB Agent.

There are two workflows to follow when using MongoDB Agents with MongoDB hosts:

Install the MongoDB Agent to Manage Deployments
Recommended: You have a project and want to install the MongoDB Agent to manage your MongoDB deployments. You can also monitor and back up your MongoDB deployments following this workflow.
Install the MongoDB Agent to Only Monitor or Backup Deployments
You have a project and want to install the MongoDB Agent to monitor and/or back up your MongoDB deployments. You are choosing not to manage your MongoDB deployments at this time.
Read article

View, Retrieve, and Manage Logs — MongoDB Cloud Manager

View, Retrieve, and Manage Logs¶

On this page

  • MongoDB Real-Time Logs
    • View MongoDB Real-Time Logs
    • Enable or Disable Log Collection for a Deployment
    • Enable or Disable Log Collection for the Project
  • MongoDB On-Disk Logs
    • Configure Log Rotation
  • Agent Logs
    • View Agent Logs
    • Configure Agent Log Rotation

Cloud Manager collects log information for both MongoDB processes and its agents. For MongoDB processes, you can access both real-time logs and on-disk logs.

  • The MongoDB logs provide the diagnostic logging information for your mongod and mongos processes.
  • The Agent logs provide insight into the behavior of your Cloud Manager agents.

MongoDB Real-Time Logs¶

The MongoDB Agent issues the getLog command with every monitoring ping. This command collects log entries from RAM cache of each MongoDB process.

Cloud Manager enables real-time log collection by default. You can disable log collection for either all MongoDB deployments in a Cloud Manager project or for individual MongoDB deployments . If you disable log collection, Cloud Manager continues to display previously collected log entries.

View MongoDB Real-Time Logs¶

1
2

(Optional) For sharded clusters, filter which process type is listed.¶

The four buttons are listed in the following order, left to right: Shards , Configs , Mongos , and BIs .

Process Displays
Shards mongod processes that host your data.
Configs mongod processes that run as config servers to store a sharded cluster’s metadata.
Mongos mongos processes that route data in a sharded cluster.
BIs BI processes that access data in a sharded cluster.
3

On the line listing the process, click Metrics

4

Click the Logs tab.¶

The tab displays log information. If the tab is not displayed, see Enable or Disable Log Collection for a Deployment to enable log collection.

5

Refresh the browser window to view updated entries.¶

Enable or Disable Log Collection for a Deployment¶

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 for any process, click the ellipsis [ ] icon then click Monitoring Settings

3

Toggle Collect Logs For Host as desired.¶

  1. Click the Logs tab.
  2. Toggle the Collect Logs For Host to Off or On , as desired.
4

Click X to close the Monitoring Settings box.¶

If you turn off log collection, existing log entries remain in the Logs tab, but Cloud Manager does not collect new entries.

Enable or Disable Log Collection for the Project¶

1

Click Settings , then Project Settings

2

Toggle the Collect Logs For All Hosts option to Yes or No , as desired.¶

MongoDB On-Disk Logs¶

Cloud Manager collects on-disk logs even if the MongoDB instance is not running. The MongoDB Agent collects the logs from the location you specified in the MongoDB systemLog.path configuration option. The MongoDB on-disk logs are a subset of the real-time logs and therefore less verbose.

Note

This option isn’t available for deployed MongoDB processes if the systemLog.destination property is set to syslog .

You can configure log rotation for the on-disk logs. Cloud Manager rotates logs by default.

This procedure rotates both system and audit logs for Cloud Manager.

Configure Log Rotation¶

Cloud Manager can rotate and compress logs for clusters that the MongoDB Agent manages. If the MongoDB Agent only monitors a cluster, it ignores that cluster’s logs.

Important

If you’re running MongoDB Enterprise version 5.0 or later and MongoDB Agent 11.11.0.7355 or later, you can:

  • Set separate rules for rotating server logs and audit logs.
  • Compress and delete audit logs using Cloud Manager. For security reasons, we recommend managing your audit log compression and deletion outside of Cloud Manager.

If you’re running earlier versions of MongoDB Enterprise or the MongoDB Agent, Cloud Manager:

  • Uses your System Log Rotation settings to rotate both the server logs and the audit logs.
  • Doesn’t compress or delete audit logs. If you configure compression and deletion, Cloud Manager applies these settings to the server logs only.

MongoDB Community users can rotate, compress, and delete the server logs only.

Note

When using this feature, disable any platform-based log-rotation services like logrotate . If the MongoDB Agent only monitors the cluster, that cluster may use platform-based services.

1

Open the MongoDB Log Settings

  1. Click Deployment .
  2. In the More drop-down list, click MongoDB Log Settings .
2

Enable log rotation.¶

Toggle System Log Rotation to ON to rotate server logs.

MongoDB Enterprise users running MongoDB Enterprise version 5.0 or later and MongoDB Agent 11.11.0.7355 and later can also toggle Audit Log Rotation to ON to rotate audit logs and configure audit log rotation separately.

If you’re running earlier versions of MongoDB Enterprise or the MongoDB Agent, setting System Log Rotation to ON also rotates audit logs.

Set log rotation to OFF if you don’t want Cloud Manager to rotate its logs. Log rotation is OFF by default.

After you enable log rotation, Cloud Manager displays additional log rotation settings.

3

Configure the log rotation settings.¶

Cloud Manager rotates the logs on your MongoDB hosts per the following settings:

Field Necessity Action Default
Size Threshold (MB) Required Cloud Manager rotates log files that exceed this maximum log file size. 1000
Time Threshold (Hours) Required Cloud Manager rotates logs that exceed this duration. 24
Max Uncompressed Files Optional

Log files can remain uncompressed until they exceed this number of files. Cloud Manager compresses the oldest log files first.

If you leave this setting empty, Cloud Manager will use the default of 5 .

5
Max Percent of Disk Optional

Log files can take up to this percent of disk space on your MongoDB host’s log volume. Cloud Manager deletes the oldest log files once they exceed this disk threshold.

If you leave this setting empty, Cloud Manager will use the default of 2% .

2%
Total Number of Files Optional Total number of log files. If a number is not specified, the total number of log files defaults to 0 and is determined by other Rotate Logs settings. 0

When you are done, click Save to review your changes.

4

Click Confirm & Deploy to deploy your changes.¶

Otherwise, click Cancel and you can make additional changes.

Agent Logs¶

Cloud Manager collects logs for all your MongoDB Agents.

View Agent Logs¶

1

Click Deployment , then the Agents tab, then Agent Logs

The page displays logs for the type of agent selected in the View drop-down list. The page filters logs according to any filters selected in through the gear icon.

2

Filter the log entries.¶

To display logs for a different type of agent, use the View drop-down list.

To display logs for a specific hosts or MongoDB processes, click the gear icon and make your selections.

To clear filters, click the gear icon and click Remove Filters .

To download the selected logs, click the gear icon and click Download as CSV File .

Note

To view logs for a specific agent, you can alternatively click the Agents tab’s All Agents list and then click view logs for the agent.

Configure Agent Log Rotation¶

If you use Automation to manage your cluster, follow this procedure to configure rotation of the Agent log files.

Note

If you haven’t enabled Automation, see the following documentation for information about how to manually configure logging settings in the agent configuration files:

  • MongoDB Agent General Logging Settings
  • MongoDB Agent Monitoring Logging Settings
  • MongoDB Agent Backup Logging Settings
1

Click Deployment , then the Agents tab.¶

2

Click Downloads & Settings

3

Scroll down to the Agent Log Settings section.¶

4

Edit the log settings.¶

Click the pencil icon to edit the Monitoring Agent or Backup Agent log settings:

Name Type Description
Linux Log File Path string

Conditional: Logs on a Linux host. The path to which the agent writes its logs on a Linux host.

The suggested value is:

/var/log/mongodb-mms-automation/monitoring-agent.log
Windows Log File Path string

Conditional: Logs on a Windows host. The path to which the agent writes its logs on a Windows host.

The suggested value is:

%SystemDrive%\MMSAutomation\log\mongodb-mms-automation\monitoring-agent.log
Rotate Logs Toggle A toggle to select if the logs should be rotated.
Size Threshold (MB) integer The size where the logs rotate automatically. The default value is 1000 .
Time Threshold (Hours) integer The duration of time when the logs rotate automatically. The default value is 24 .
Max Uncompressed Files integer Optional. The greatest number of log files, including the current log file, that should stay uncompressed. The suggested value is 5 .
Max Percent of Disk integer Optional. The greatest percentage of disk space on your MongoDB hosts that the logs should consume. The suggested value is 2% .
Total Number of Files integer Optional. The total number of log files. If a number is not specified, the total number of log files defaults to 0 and is determined by other Rotate Logs settings.

When you are done, click Save .

5

Click Review & Deploy to review your changes.¶

6

Click Confirm & Deploy to deploy your changes.¶

Otherwise, click Cancel and you can make additional changes.

Read article

Organizations and Projects — MongoDB Cloud Manager

Organizations and Projects¶

On this page

  • Organizations
  • Projects
  • Teams
  • Invitations to Organizations and Projects

New

Cloud Manager provides a new organizations and projects hierarchy to help you manage your Cloud Manager deployments. Groups are now known as projects. You can create many projects in an organization.

Organizations¶

In the organizations and projects hierarchy, an organization can contain many projects (previously referred to as groups). Under this structure, you can:

  • Use the same billing settings across multiple projects in your organization.
  • View all projects within an organization, create teams of users, and assign teams to projects. See Organizations .
  • Connect to Atlas as part of live migration to Atlas. See Connect to Atlas .

Projects¶

Groups are now projects. Previously, users managed deployments by groups, where each group was managed separately even if a user belonged to multiple groups.

Existing Groups¶

If you have existing groups, organizations have been automatically created for your groups (now projects), and your groups have been placed under these organizations.

If your groups share the same billing settings, they have been placed in the same organization.

Deployments¶

Deployments are now associated with projects. As before, deployments must have unique names within projects. See Projects and Edit Project Settings .

Teams¶

You can create teams of users and then assign teams of users to projects. See Cloud Manager Access .

Invitations to Organizations and Projects¶

You can view and accept invitations to organizations and projects. See Invitations to Organizations and Projects .

Read article

Configure Federated Authentication from Okta — MongoDB Cloud Manager

Configure Federated Authentication from Okta¶

On this page

  • Prerequisites
  • Procedures
    • Configure Okta as an Identity Provider
    • Map your Domain
    • Associate Your Domain with Your Identity Provider
    • Test Your Domain Mapping
    • (Optional) Map an Organization
    • (Optional) Configure Advanced Federated Authentication Options
  • Sign in to Cloud Manager Using Your Login URL

This guide shows you how to configure federated authentication using Okta as your IdP .

After integrating Okta and Cloud Manager, you can use your company’s credentials to log in to Cloud Manager and other MongoDB cloud services.

Note

If you are using Okta’s built-in MongoDB Cloud app, you can use Okta’s documentation.

If you are creating your own SAML app, use the procedures described here.

Prerequisites¶

To use Okta as an IdP for Cloud Manager, you must have:

  • An Okta account.
  • A custom, routable domain name.

Procedures¶

Throughout the following procedure, it is helpful to have one browser tab open to your Federation Management Console and one tab open to your Okta account.

Configure Okta as an Identity Provider¶

1

Add a new application to your Okta account¶

  1. In the Okta top navigation, click the Applications tab.
  2. Click the Add Application button.
  3. Click the Create New App button.
  4. Select Web for the Platform field.
  5. Select SAML 2.0 for the Sign on method field.
  6. Click the Create button.
2

Create Okta SAML integration¶

  1. Fill in the App name text field with your desired application name.
  2. Optionally, add a logo image and set app visibility.
  3. Click the Next button.
3

Download Okta certificate¶

  1. Click the Download Okta Certificate button.
  2. Rename the downloaded file to have a .cer extension instead of .cert .
4
5

Create a new Identity Provider¶

  1. In the FMC dashboard, click the Manage Identity Providers button.
  2. Click the Setup Identity Provider button.
6

Enter SAML settings¶

  1. In the FMC dashboard, fill in the data fields with the following values:

    Field Value
    Configuration Name A descriptive name of your choosing.
    Issuer URI and Single Sign-On URL Click the Fill With Placeholder Values button to the right of the text fields. You will get the real values from Okta in a later step.
    Identity Provider Signature Certificate

    Click the Choose File button to upload the .cer file you received from Okta earlier.

    You can either:

    • Upload the certificate from your computer, or
    • Paste the contents of the certificate into a text box.
    Request Binding HTTP POST
    Response Signature Algorithm SHA-256
  2. Click the Next button.

7

Create SAML Integration¶

  1. In this step, copy values from the Cloud Manager FMC to the Okta Create SAML Integration page.

    Okta Data Field Value
    Single sign on URL

    Use the Assertion Consumer Service URL from the Cloud Manager FMC.

    Checkboxes:

    • Use this for Recipient URL and Destination URL : checked
    • Allow this app to request other SSO URLs : unchecked
    Audience URI (SP Entity ID) Use the Audience URI from the Cloud Manager FMC.
    Default RelayState

    Optionally, add a RelayState URL to your IdP to send users to a URL you choose and avoid unnecessary redirects after login. You can use:

    Destination RelayState URL
    MongoDB MongoDB Atlas The Login URL that was generated for your identity provider configuration in the MongoDB Atlas Federation Management App .
    MongoDB Support Portal
    https://auth.mongodb.com/app/salesforce/exk1rw00vux0h1iFz297/sso/saml
    
    MongoDB University
    https://university.mongodb.com
    
    MongoDB Community Forums
    https://auth.mongodb.com/home/mongodbexternal_communityforums_3/0oa3bqf5mlIQvkbmF297/aln3bqgadajdHoymn297
    
    MongoDB Feedback Engine
    https://auth.mongodb.com/home/mongodbexternal_uservoice_1/0oa27cs0zouYPwgj0297/aln27cvudlhBT7grX297
    
    MongoDB JIRA
    https://auth.mongodb.com/app/mongodbexternal_mongodbjira_1/exk1s832qkFO3Rqox297/sso/saml
    
    Name ID format Unspecified
    Application username Email
    Update application username on Create and update
  2. Click the Click Show Advanced Settings link in the Okta configuration page and ensure that the following values are set:

    Okta Data Field Value
    Response Signed
    Assertion Signature Signed
    Signature Algorithm RSA-SHA256
    Digest Algorithm SHA256
    Assertion Encryption Unencrypted
  3. Leave the remaining Advanced Settings fields in their default state.

  4. Scroll down to the Attribute Statements (Optional) section and create three attributes with the following values:

    Name Name Format Value
    email Unspecified user.email
    firstName Unspecified user.firstName
    lastName Unspecified user.lastName

    Important

    The values in the Name column are case-sensitive. Enter them exactly as shown.

    Note

    These values may be different if Okta is connected to an Active Directory. For the appropriate values, use the Active Directory fields that contain a user’s first name, last name, and full email address.

  5. Click the Next button in the Okta configuration.

  6. Select the radio button marked I’m an Okta customer adding an internal app .

  7. Click the Finish button.

8

Copy information back to the Cloud Manager FMC¶

  1. On the Okta application page, click the View Setup Instructions button in the middle of the page.

    Note

    The Okta setup instructions appear in a new browser tab.

  2. In the Cloud Manager FMC , click the Finish button to return to the Identity Providers page. Click the Modify button for your newly created IdP .

  3. Fill in the following text fields:

    FMC Data Field Value
    Issuer URI Use the Identity Provider Issuer value from the Okta Setup Instructions page.
    Single Sign-on URL Use the Identity Provider Single Sign-On URL value from the Okta Setup Instructions page.
  4. Close the Okta setup instructions browser tab.

  5. Click the Next button on the Cloud Manager FMC page.

  6. Click the Finish button the FMC Edit Identity Provider page.

9

Assign users to your Okta application¶

  1. On the Okta application page, click the Assignments tab.
  2. Ensure that all your Cloud Manager organization users who will use the Okta service are enrolled.

Map your Domain¶

Mapping your domain to the IdP lets Cloud Manager know that users from your domain should be directed to the Login URL for your identity provider configuration.

When users visit the Cloud Manager login page, they enter their email address. If the email domain is associated with an IdP, they are sent to the Login URL for that IdP.

Important

You can map a single domain to multiple identity providers. If you do, users who log in using the MongoDB Cloud console are automatically redirected to the first matching IdP mapped to the domain.

To log in using an alternative identity provider, users must either:

  • Initiate the MongoDB Cloud login through the desired IdP , or
  • Log in using the Login URL associated with the desired IdP .

Use the Federation Management Console to map your domain to the IdP :

1

Open the Federation Management Console

  1. Log in to Cloud Manager.
  2. Use the dropdown at the top-left of Cloud Manager to select the organization for which you want to manage federation settings.
  3. Click Settings in the left navigation pane.
  4. In Manage Federation Settings , click Visit Federation Management App .
2

Enter domain mapping information.¶

  1. Click Add a Domain .

  2. On the Domains screen, click Add Domain .

  3. Enter the following information for your domain mapping:

    Field Description
    Display Name Name to easily identify the domain.
    Domain Name Domain name to map.
  4. Click Next .

3

Choose how to verify your domain.¶

Note

You can choose the verification method once. It cannot be modified. To select a different verification method, delete and recreate the domain mapping.

Select the appropriate tab based on whether you are verifying your domain by uploading an HTML file or creating a DNS TXT record:

Upload an HTML file containing a verification key to verify that you own your domain.

  1. Click HTML File Upload .
  2. Click Next .
  3. Download the mongodb-site-verification.html file that Cloud Manager provides.
  4. Upload the HTML file to a web site on your domain. You must be able to access the file at <https://host.domain>/mongodb-site-verification.html .
  5. Click Finish .
4

Verify your domain.¶

The Domains screen displays both unverified and verified domains you’ve mapped to your IdP . To verify your domain, click the target domain’s Verify button. Cloud Manager shows whether the verification succeeded in a banner at the top of the screen.

Associate Your Domain with Your Identity Provider¶

After successfully verifying your domain, use the Federation Management Console to associate the domain with Okta:

1

Click Identity Providers in the left navigation.¶

2

For the IdP you want to associate with your domain, click pencil icon next to Associated Domains

3

Select the domain you want to associate with the IdP .

4

Click Confirm

Test Your Domain Mapping¶

Important

Before you begin testing, copy and save the Bypass SAML Mode URL for your IdP . Use this URL to bypass federated authentication in the event that you are locked out of your Cloud Manager organization.

While testing, keep your session logged in to the Federation Management Console to further ensure against lockouts.

To learn more about Bypass SAML Mode , see Bypass SAML Mode .

Use the Federation Management Console to test the integration between your domain and Okta:

1

In a private browser window, navigate to the Cloud Manager log in page.¶

2

Enter a username (usually an email address) with your verified domain.¶

Example

If your verified domain is mongodb.com , enter alice@mongodb.com .

3

Click Next

If you mapped your domain correctly, you’re redirected to your IdP to authenticate. If authenticating with your IdP succeeds, you’re redirected back to Cloud Manager.

Note

You can bypass the Cloud Manager log in page by navigating directly to your IdP ’s Login URL . The Login URL takes you directly to your IdP to authenticate.

(Optional) Map an Organization¶

Use the Federation Management Console to assign your domain’s users access to specific Cloud Manager organizations:

1

Open the Federation Management Console

  1. Log in to Cloud Manager.
  2. Use the dropdown at the top-left of Cloud Manager to select the organization for which you want to manage federation settings.
  3. Click Settings in the left navigation pane.
  4. In Manage Federation Settings , click Visit Federation Management App .
2

Connect an organization to the Federation Application.¶

  1. Click View Organizations .

    Cloud Manager displays all organizations where you are an Organization Owner .

    Organizations which are not already connected to the Federation Application have Connect button in the Actions column.

  2. Click the desired organization’s Connect button.

3

Apply an Identity Provider to the organization.¶

From the Organizations screen in the management console:

  1. Click the Name of the organization you want to map to an IdP .

  2. On the Identity Provider screen, click Apply Identity Provider .

    Cloud Manager directs you to the Identity Providers screen which shows all IdPs you have linked to Cloud Manager.

  3. For the IdP you want to apply to the organization, click Modify .

  4. At the bottom of the Edit Identity Provider form, select the organizations to which this IdP applies.

  5. Click Next .

  6. Click Finish .

4

Connect an organization to the Federation Application.¶

  1. Click Organizations in the left navigation.
  2. In the list of Organizations , ensure that your desired organization(s) now have the expected Identity Provider .

(Optional) Configure Advanced Federated Authentication Options¶

You can configure the following advanced options for federated authentication for greater control over your federated users and authentication flow:

  • Bypass SAML Mode

Note

The following advanced options for federated authentication require you to map an organization .

  • Assign a Default User Role for an Organization
  • Restrict Access to an Organization by Domain
  • Restrict User Membership to the Federation

Sign in to Cloud Manager Using Your Login URL¶

All users you assigned to the Okta application can log in to Cloud Manager using their Okta credentials on the Login URL . Users have access to the organizations you mapped to your IdP .

Important

You can map a single domain to multiple identity providers. If you do, users who log in using the MongoDB Cloud console are automatically redirected to the first matching IdP mapped to the domain.

To log in using an alternative identity provider, users must either:

  • Initiate the MongoDB Cloud login through the desired IdP , or
  • Log in using the Login URL associated with the desired IdP .

If you selected a default organization role, new users who log in to Cloud Manager using the Login URL have the role you specified.

Read article