Authenticate Using Self-Managed SASL and LDAP with OpenLDAP (original) (raw)

Note

Starting in MongoDB 8.0, LDAP authentication and authorization is deprecated. LDAP is available and will continue to operate without changes throughout the lifetime of MongoDB 8. LDAP will be removed in a future major release.

For details, see LDAP Deprecation.

MongoDB Enterprise provides support for proxy authentication of users. This allows administrators to configure a MongoDB cluster to authenticate users by proxying authentication requests to a specified Lightweight Directory Access Protocol (LDAP) service.

Note

For MongoDB 4.2 Enterprise binaries linked againstlibldap (such as when running on RHEL), access to thelibldap is synchronized, incurring some performance/latency costs.

For MongoDB 4.2 Enterprise binaries linked againstlibldap_r, there is no change in behavior from earlier MongoDB versions.

Warning

MongoDB Enterprise for Windows does not support binding viasaslauthd.

LDAP support for user authentication requires proper configuration of the saslauthd daemon process as well as the MongoDB server.

On systems that configure saslauthd with the/etc/sysconfig/saslauthd file, such as Red Hat Enterprise Linux, Fedora, CentOS, and Amazon Linux AMI, set the mechanism MECH toldap:

On systems that configure saslauthd with the/etc/default/saslauthd file, such as Ubuntu, set the MECHANISMSoption to ldap:

On certain Linux distributions, saslauthd starts with the caching of authentication credentials enabled. Until restarted or until the cache expires, saslauthd will not contact the LDAP server to re-authenticate users in its authentication cache. This allowssaslauthd to successfully authenticate users in its cache, even in the LDAP server is down or if the cached users' credentials are revoked.

To set the expiration time (in seconds) for the authentication cache, see the -t option ofsaslauthd.

If the saslauthd.conf file does not exist, create it. The saslauthd.conf file usually resides in the /etcfolder. If specifying a different file path, see the-O option ofsaslauthd.

To connect to an OpenLDAP server, update the saslauthd.conffile with the following configuration options:


ldap_servers: <ldap uri>

ldap_search_base: <search base>

ldap_filter: <filter>

The ldap_servers specifies the uri of the LDAP server used for authentication. In general, for OpenLDAP installed on the local machine, you can specify the value ldap://localhost:389or if using LDAP over TLS/SSL, you can specify the valueldaps://localhost:636.

The ldap_search_base specifies distinguished name to which the search is relative. The search includes the base or objects below.

The ldap_filter specifies the search filter.

The values for these configuration options should correspond to the values specific for your test. For example, to filter on email, specifyldap_filter: (mail=%n) instead.

A sample saslauthd.conf file for OpenLDAP includes the following content:


ldap_servers: ldaps://ad.example.net

ldap_search_base: ou=Users,dc=example,dc=com

ldap_filter: (uid=%u)

To use this sample OpenLDAP configuration, create users with a uidattribute (login name) and place under the Users organizational unit (ou) under the domain components (dc) example andcom.

For more information on saslauthd configuration, seehttp://www.openldap.org/doc/admin24/guide.html#Configuringsaslauthd.

Use testsaslauthd utility to test the saslauthdconfiguration. For example:


testsaslauthd -u testuser -p testpassword -f /var/run/saslauthd/mux

Modify the file path with respect to the location of thesaslauthd directory on the host operating system.

Important

Add the user to the $external database in MongoDB. To specify the user's privileges, assign roles to the user.

To use Client Sessions and Causal Consistency Guarantees with $external authentication users (Kerberos, LDAP, or X.509 users), usernames cannot be greater than 10k bytes.

For example, the following adds a user with read-only access to the records database.


db.getSiblingDB("$external").createUser(

    {

      user : <username>,

      roles: [ { role: "read", db: "records" } ]

    }

)

Add additional principals as needed. For more information about creating and managing users, seeUser Management Commands.

To configure the MongoDB server to use the saslauthd instance for proxy authentication, include the following options when starting mongod:

Important

If you use the authorization option to enforce authentication, you will need privileges to create a user.

For socket path of /<some>/<path>/saslauthd, set thesaslauthdPath to /<some>/<path>/saslauthd/mux, as in the following command line example:


mongod --auth --setParameter saslauthdPath=/<some>/<path>/saslauthd/mux --setParameter authenticationMechanisms=PLAIN

Include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the--bind_ip.

Or if using a YAML format configuration file, specify the following settings in the file:


security:

   authorization: enabled

setParameter:

   saslauthdPath: /<some>/<path>/saslauthd/mux

   authenticationMechanisms: PLAIN

Or, if using the older configuration file format:


auth=true

setParameter=saslauthdPath=/<some>/<path>/saslauthd/mux

setParameter=authenticationMechanisms=PLAIN

To use the default Unix-domain socket path, set thesaslauthdPath to the empty string "", as in the following command line example:


mongod --auth --setParameter saslauthdPath="" --setParameter authenticationMechanisms=PLAIN

Include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the--bind_ip.

Or if using a YAML format configuration file, specify the following settings in the file:


security:

   authorization: enabled

setParameter:

   saslauthdPath: ""

   authenticationMechanisms: PLAIN

Or, if using the older configuration file format:


auth=true

setParameter=saslauthdPath=""

setParameter=authenticationMechanisms=PLAIN

Include additional options as required for your configuration. For instance, if you wish remote clients to connect to your deployment or your deployment members are run on different hosts, specify the net.bindIp setting.

You can authenticate from the command line during connection, or connect first and then authenticate using db.auth() method.

To authenticate when connecting withmongosh, run mongosh with the following command-line options, substituting <host> and<user>, and enter your password when prompted:


mongosh --host <host> --authenticationMechanism PLAIN --authenticationDatabase '$external' -u <user> -p

Alternatively, connect without supplying credentials and then call the db.auth() method on the $external database. Specify the value "PLAIN" in the mechanism field, the user and password in the user and pwd fields respectively. Use the defaultdigestPassword value (false) since the server must receive an undigested password to forward on to saslauthd, as in the following example:

Tip

You can use the passwordPrompt() method in conjunction with various user authentication management methods and commands to prompt for the password instead of specifying the password directly in the method or command call. However, you can still specify the password directly as you would with earlier versions of themongo shell.


db.getSiblingDB("$external").auth(

   {

     mechanism: "PLAIN",

     user: <username>,

     pwd:  passwordPrompt() // or cleartext password

   }

)

Enter the password when prompted.

The server forwards the password in plain text. In general, use only on a trusted channel (VPN, TLS/SSL, trusted wired network). See Considerations.