Configure User Authentication and Authorization with Microsoft Entra ID Domain Services

Configure Microsoft Entra ID Domain Services for your domain.

To configure Microsoft Entra ID Domain Services, follow the Create an advanced managed domain tutorial in the Azure Documentation using the Custom domain names DNS name option.

When you configure your managed domain, make sure that you note the value you enter in the DNS domain name field. This value is your <managed-domain>. You must provide it in several places in this tutorial.

Obtain an SSL certificate for secure LDAP.

Microsoft Entra ID Domain Services uses SSL certificates to secure LDAP. Your certificate must adhere to the requirements outlined in the Azure Documentation.

To obtain a certificate, either:

• Get one from the public or enterprise certificate authority (CA) your organization uses.

  • You must obtain a wildcard certificate to ensure secure LDAP works properly with Microsoft Entra ID Domain Services.

  • The certificate's subject name must match the <managed-domain> you used when you configured Microsoft Entra ID Domain Services.

    Example

    *.aadds.example.com

• Generate a self-signed certificate. Self-signed certificates are not recommended for production.

To generate a self-signed certificate on MacOS or Linux systems for testing purposes:

brew install openssl

1. Generate a private key with openssl. The following command generates a private key file named <your-key-name>.key:

   openssl genrsa -out <your-key-name>.key 2048

2. Edit the following configuration file template. Update the attributes in the [dn-param] section with values that relate to your organization. Make sure the subject name (CN) matches the following template: *.<managed-domain>

   Example

   *.aadds.example.com

   # openssl x509 extfile params
   extensions = extend
   [req] # openssl req params
   prompt = no
   distinguished_name = dn-param
   [dn-param] # DN fields
   C = US
   ST = NY
   L  = New York
   O = MongoDB
   OU = Atlas
   CN = *.aadds.example.com
   [extend] # openssl extensions
   subjectKeyIdentifier = hash
   authorityKeyIdentifier = keyid:always
   keyUsage = digitalSignature,keyEncipherment,keyCertSign
   extendedKeyUsage=serverAuth,clientAuth

3. Save the file as <your-config-name>.cfg.

4. Generate a certificate signing request using the key and configuration files you created. The following command generates a certificate signing request named <your-csr-name>.csr:

   openssl req -new -key <your-key-name>.key \
   -out <your-csr-name>.csr -config <your-config-name>.cfg \
   -extensions extend

5. Generate a self-signed certificate using key, configuration, and certificate signing request files you created. The following command generates a self-signed certificate file named <your-cert-name>.crt:

   openssl x509 -req -sha256 -days 365 -in <your-csr-name>.csr \
   -signkey <your-key-name>.key -out <your-cert-name>.crt \
   -extfile <your-config-name>.cfg

To generate a self-signed certificate on a Windows system for testing purposes, see the Azure documentation.

Obtain an SSL certificate that includes your private key.

Microsoft Entra ID Domain Services uses private keys to decrypt secure LDAP traffic. Certificates that include private keys use the PKCS#12 format and use the .pfx file format. You must upload a certificate of this format to Microsoft Entra ID Domain Services to decrypt secure LDAP traffic sent over the public internet.

To generate a .pfx certificate on MacOS or Linux systems:

1. Save your public key and SSL certificate to your local machine.

   Note

   Your certificate must use the PEM format.

   If your certificate does not contain your private key, you can save your private key to a .key format file.

2. Generate a .pfx certificate using your private key and your certificate with openssl. The following command generates a .pfx certificate file named <your-cert-name>.pfx:

   openssl pkcs12 -export -out <your-cert-name>.pfx \
   -inkey <your-key-name>.key -in <your-cert-name>.crt

   When prompted, enter and verify a password to encrypt the file. You will enter this password to decrypt your private key when you upload the .pfx certificate to Microsoft Entra ID Domain Services.

To generate a .pfx certificate on a Windows system, see the Azure documentation.

Enable secure LDAP on Microsoft Entra ID Domain Services.

To enable secure LDAP on Microsoft Entra ID Domain Services, see the Azure documentation.

Configure your DNS provider.

You must configure your DNS provider so that Atlas and the database nodes can connect to the LDAP server in the custom domain that Microsoft Entra ID Domain Services manages.

Create a host record for LDAP traffic that resolves a subdomain of your <managed-domain> to the external IP address that the Microsoft Entra ID Domain Services LDAP service uses:

To find the external IP address the Microsoft Entra ID Domain Services LDAP service uses, see the Azure documentation.

Add your custom domain to Microsoft Entra ID.

Add your custom domain name to Microsoft Entra ID to create users that belong to your domain. After you add your domain, you must also add the Microsoft Entra ID DNS information in a TXT record with your DNS provider and verify the configuration.

To add your custom domain to Microsoft Entra ID, see the Azure documentation.

Configure Microsoft Entra ID Domain Services for inbound LDAP traffic.

You must allow all traffic over all ports from the public internet to port 636 to use Microsoft Entra ID Domain Services as an LDAP provider with Atlas.

To add an inbound security rule to allow inbound LDAP traffic on port 636, see the Azure documentation.

Create a bind user.

Create a bind user. The bind user is an Microsoft Entra ID user that you use to query the account and to authenticate database users' credentials when they connect to an Atlas database. The bind user must belong to the custom domain you added to Microsoft Entra ID.

To create Microsoft Entra ID users, see the Azure documentation.

Enable the bind user account for Microsoft Entra ID Domain Services.

You must generate a password hash for the bind user for Kerberos and NTLM authentication before the bind user can use Microsoft Entra ID Domain Services. The steps differ based on the type of Microsoft Entra ID user account.

To learn how to generate password hashes for your users, see the Azure documentation.

Assign the Directory Readers role to the bind user account.

To query Microsoft Entra ID, the bind user must have the permissions granted by the Directory Readers role.

To assign the Directory Readers role to the bind user, see the Azure documentation.

Create Microsoft Entra ID Users.

If they don't exist already, create users in Microsoft Entra ID Domain Services that you want to grant database access to. Users must belong to the custom domain you added to Microsoft Entra ID.

To create Microsoft Entra ID users, see the Azure documentation.

In Atlas, go to the Advanced page for your project.

1. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar.

2. If it's not already displayed, select your project from the Projects menu in the navigation bar.

3. In the sidebar, click Advanced under the Security heading.

   The Advanced page displays.

Toggle the button next to LDAP Authentication to On.

Enter the server details and bind credentials for all of your LDAP servers in the Configure Your LDAP Server panel.

You may list multiple servers separated by commas. You cannot use different ports.

Add a User to DN Mapping.

Add a User to DN mapping similar to the following example to allow clients to provide their username instead of full DNs when they connect to Atlas databases:

[
  {
      "match":"(.+)",
      "substitution":"CN={0},OU=AADDC Users,DC=<managed-domain>,DC=com"
  }
]

If your <managed-domain> consists of one or more subdomains, you must add a DC (domainComponent) attribute to the distinguished name for each.

Enter certificates issued from a Certificate Authority (CA) for your LDAP servers, separated by commas, in the CA Root Certificate field.

You may provide self-signed certificates.

Click Verify and Save.

Wait for Atlas to deploy your changes. Atlas verifies that your clusters can connect to, authenticate with, and query your LDAP servers using the configuration details that you provided.

In Atlas, go to the Database Access page for your project.

1. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar.

2. If it's not already displayed, select your project from the Projects menu in the navigation bar.

3. In the sidebar, click Database Access under the Security heading.

   The Database Access page displays.

Add LDAP users to Atlas.

Add users managed in the Azure AD to Atlas.

1. Click Add New Database User.

2. Click LDAP User.

3. Perform one of the following:

   1. If you have not entered a User to DN Mapping, enter the full DN of the LDAP user. Follow this template:

      CN=<user-name>,OU=AADDC Users,DC=<managed>,DC=<domain>,DC=com

      For example, if your <user-name> is Jane Doe and your <managed-domain> is aadds.example.com, your user's DN is:

      CN=Jane Doe,ou=AADDC Users,DC=aadds,DC=example,DC=com

   2. If you entered a User to DN Mapping, enter the username that your mapping requires.

4. Select the database access level to grant to the user.

5. Click Add User.

In Atlas, go to the Database Access page for your project.

1. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar.

2. If it's not already displayed, select your project from the Projects menu in the navigation bar.

3. In the sidebar, click Database Access under the Security heading.

   The Database Access page displays.

Add the database access LDAP groups to Atlas.

Add each of the Azure database groups you created to Atlas. Members of groups that you add are authorized to perform database actions granted to the group.

1. Click Add New Database User.

1. Click LDAP Group, and then enter the full DN of the group containing your database users, even if you enabled User to DN Mapping. Follow this template:

   CN=<group-name>,OU=AADDC Users,DC=<managed-domain>,DC=com

   Note

   For Microsoft Entra ID Domain Services, the attributes in distinguished names must be upper case.

   If your <managed-domain> consists of one or more subdomains, you must add a DC (domainComponent) attribute to the distinguished name for each.

   Example

   If your <managed-domain> is aadds.example.com, the domain components are:

   DC=aadds,DC=example,DC=com

   For example, if your <group-name> is Atlas read only and your <managed-domain> is aadds.example.com, your user's DN is:

   CN=Atlas read only,OU=AADDC Users,DC=aadds,DC=example,DC=com

1. Select the database access level to grant to users in this group.

2. Click Add User.

In Atlas, go to the Advanced page for your project.

1. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar.

2. If it's not already displayed, select your project from the Projects menu in the navigation bar.

3. In the sidebar, click Advanced under the Security heading.

   The Advanced page displays.

Toggle the button next to LDAP Authorization to On.

Verify the server details and bind credentials for your LDAP server are correct in the Configure Your LDAP Server panel.

Enter a query template in Query Template.

When a user attempts to perform an action, Atlas executes the LDAP query template to obtain the LDAP groups to which the authenticated user belongs. Atlas permits the action if the query returns at least one group that is authorized to perform the action. Atlas does not permit the action if the query returns no groups that are authorized to perform the action.

Atlas substitutes the authenticated username in the {USER} placeholder when it runs the query. The query is relative to the host specified in Server Hostname.

The formatting for the query must conform to RFC4515.

If you want to identify what group a user is a member of, you can use the default Query Template:

{USER}?memberOf?base

Click Verify and Save.

Wait for Atlas to deploy your changes. Atlas verifies that your clusters can connect to, authenticate with, and query your LDAP server using the configuration details that you provide.

In Atlas, go to the Clusters page for your project.

1. If it's not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.

2. If it's not already displayed, select your desired project from the Projects menu in the navigation bar.

3. If it's not already displayed, click Clusters in the sidebar.

   The Clusters page displays.

Use mongosh to connect to your cluster with user credentials that you added to Atlas.

To copy the connection string:

1. Click Connect.

2. Click LDAP, and then click Copy.

3. Paste and edit the string with your User DN and password.

If your <managed-domain> consists of one or more subdomains, you must add a DC (domainComponent) attribute to the distinguished name for each.

Escape spaces in user or group names in the user's full DN:

--username CN=Jane\ Doe,OU=AADDC\ Users,DC=aadds,DC=example,DC=com

After connecting to your cluster, run commands to verify the user has the read or write privileges you assigned them.