Docs4dev
Docs
mongodb / v3.6 / reference / core-security-ldap.html

LDAP Proxy Authentication

On this page

MongoDB Enterprise supports proxying authentication requests to a Lightweight Directory Access Protocol (LDAP) service.

MongoDB 3.4 supports simple and SASL binding to LDAP servers via:

  • Operating system libraries

    New in version 3.4: MongoDB 3.4 supports binding to an LDAP server via operating system libraries. This allows Linux and Windows MongoDB 3.4 servers to use an LDAP server for authentication.

  • saslauthd

    Linux MongoDB servers supports binding to an LDAP server via the saslauthd daemon.

    Important

    The parent directory of the saslauthd Unix domain socket file specified to security.sasl.saslauthdSocketPath or --setParameter saslauthdPath must grant read and execute (r-x) permissions for either:

    • The user starting the mongod or mongos, or
    • a group to which that user belongs.

    The mongod or mongos cannot successfully authenticate via saslauthd without the specified permission on the saslauthd directory and its contents.

Previous versions of MongoDB support LDAP authentication using saslauthd. This restricted LDAP authentication support to Linux MongoDB deployments only.

Previous versions of Microsoft Windows MongoDB cannot connect to LDAP servers. MongoDB 3.4 on Windows remains incompatible with saslauthd.

Considerations

A full description of LDAP is beyond the scope of this documentation. This page assumes prior knowledge of LDAP.

This documentation only describes MongoDB LDAP authentication, and does not replace other resources on LDAP. We encourage you to thoroughly familiarize yourself with LDAP and its related subject matter before configuring LDAP authentication.

MongoDB can provide professional services for optimal configuration of LDAP authentication for your MongoDB deployment.

Managing LDAP Users on the MongoDB server

User management requires managing users both on the LDAP server and the MongoDB server. For each user authenticating via LDAP, MongoDB requires a user on the $external database whose name exactly matches the authentication username. Changes to a user on the LDAP server may require changes to the corresponding MongoDB $external user.

Changed in version 3.6.3: To use sessions with $external authentication users (i.e. Kerberos, LDAP, x.509 users), the usernames cannot be greater than 10k bytes.

Example

A user authenticates as sam@dba.example.com. The MongoDB server binds to the LDAP server and authenticates the user, respecting any username transformations. On successful authentication, the MongoDB server then checks the $external database for a user sam@dba.example.com and grants the authenticated user the roles and privileges associated to that user.

To manage users on the MongoDB server, you must authenticate as an LDAP user whose corresponding MongoDB $external user has user administrative privileges on the $external database, such as those provided by userAdmin.

Important

If no $external users have user administrative privileges on $external database, you cannot perform user management for LDAP authentication. This scenario may occur if you configure users prior to enabling LDAP authentication, but do not create the appropriate user administrators.

Managing existing non-LDAP users

If there are existing users not on the $external database, you must meet the following requirements for each user to ensure continued access:

  • User has a corresponding user object on the LDAP server
  • User exists on the $external database with equivalent roles and privileges

If you want to continue allowing access by users not on the $external database, you must configure setParameter authenticationMechanisms to include SCRAM-SHA-1. Users must then specify --authenticationMechanism SCRAM-SHA-1 when authenticating.

Deploying LDAP authentication on a replica set

For replica sets, configure LDAP authentication on secondary and arbiter members first before configuring the primary. This also applies to shard replica sets, or config server replica sets. Configure one replica set member at a time to maintain a majority of members for write availability.

Deploying LDAP authentication on a sharded cluster

In sharded clusters, you must configure LDAP authentication on the config servers and each mongos for cluster-level users. You can optionally configure LDAP authorization on each shard for shard-local users.

LDAP Authentication via the Operating System LDAP libraries

New in version 3.4.

The LDAP authentication via OS libraries process is summarized below:

  1. A client authenticates to MongoDB, providing a user’s credentials.

  2. If the username requires mapping to an LDAP DN prior to binding against the LDAP server, MongoDB can apply transformations based on the configured security.ldap.userToDNMapping setting.

  3. MongoDB binds to an LDAP server specified in security.ldap.servers using the provided username or, if a transformation was applied, the transformed username.

    MongoDB uses simple binding by default, but can also use sasl binding if configured in security.ldap.bind.method and security.ldap.bind.saslMechanisms.

    If a transformation requires querying the LDAP server, or if the LDAP server disallows anonymous binds, MongoDB uses the username and password specified to security.ldap.bind.queryUser and security.ldap.bind.queryPassword to bind to the LDAP server before attempting to authenticate the provided user credentials.

  4. The LDAP server returns the result of the bind attempt to MongoDB. On success, MongoDB attempts to authorize the user.

  5. The MongoDB server attempts to map the username to a user on the $external database, assigning the user any roles or privileges associated to a matching user. If MongoDB cannot find a matching user, authentication fails.

  6. The client can perform those actions for which MongoDB granted the authenticated user roles or privileges.

To use LDAP for authentication via operating system libraries, specify the following settings as a part of your mongod or mongos configuration file:

option description required
security.ldap.servers Quote-enclosed comma-separated list of LDAP servers in host[:port] format. YES
security.ldap.bind.method

Used to specify the method the mongod or mongos uses to authenticate, or bind, to the LDAP server. Specify sasl to use one of the SASL protocols defined in security.ldap.bind.saslMechanisms.

Defaults to simple.

 NO, unless using sasl for binding to the LDAP server.
security.ldap.bind.saslMechanisms

Used to specify the SASL mechanisms mongod or mongos can use when authenticating or binding to the LDAP server. MongoDB and the LDAP server must agree on at least one SASL mechanism.

Defaults to DIGEST-MD5.

 NO, unless setting method to sasl and you need different or additional SASL mechanisms.
security.ldap.bind.queryUser

The LDAP entity, identified by its distinguished name (DN) or SASL name, with which the MongoDB server authenticates, or binds, when connecting to an LDAP server.

Use with queryPassword.

The user specified must have the appropriate privileges to execute queries on the LDAP server.

 NO, unless specifying a query as part of a userToDNMapping transformation, or if the LDAP server’s security settings disallow anonymous binds.
security.ldap.bind.queryPassword The password used to authenticate to an LDAP server when using queryUser. NO, unless specifying queryUser
security.ldap.bind.useOSDefaults Windows MongoDB deployments can use the operating system credentials in place of queryUser and queryPassword for authenticating or binding as when connecting to the LDAP server. NO, unless replacing queryUser and queryPassword.
security.ldap.userToDNMapping

Clients may authenticate using a username whose format is incompatible with the format expected by the configured bind method. For example, simple binding may require a full LDAP DN while the username used to authenticate to MongoDB might be an e-mail address.

userToDNMapping allows MongoDB to transform incoming usernames into a format compatible with your LDAP schema. MongoDB supports transformations using either a substitution template or an LDAP query template.

If you specify a