SupportConsoleDevelopersStart a trialContact

20.12. Enabling Different Types of Binds

Whenever an entity logs into or accesses the Directory Server, it binds to the directory. There are many different types of bind operation, sometimes depending on the method of binding (such as simple binds or autobind) and some depending on the identity of user binding to the directory (anonymous and unauthenticated binds).
The following sections contain configuration parameters that can increase the security of binds (as in Section 20.12.1, “Requiring Secure Binds”) or streamline bind operations (such as Section 20.12.4, “Configuring Autobind”).

20.12.1. Requiring Secure Binds

A simple bind is when an entity uses a simple bind DN-password combination to authenticate to the Directory Server. Although it is possible to use a password file rather than sending a password directly through the command line, both methods still require sending or accessing a plaintext password over the wire. That makes the password vulnerable to anyone sniffing the connection.
It is possible to require simple binds to occur over a secure connection (TLS or STARTTLS), which effectively encrypts the plaintext password as it is sent with the bind operation. (It is also possible to use alternatives to simple binds, such as SASL authentication and certificate-based authentication.)

Important

Along with regular users logging into the server and LDAP operations, server-to-server connections are affected by requiring secure connections for simple binds. Replication, synchronization, and database chaining can all use simple binds between servers, for instance.
Make sure that replication agreements, sync agreements, and chaining configuration specify secure connections if the nsslapd-require-secure-binds attribute is turned on. Otherwise, these operations will fail.

Note

Requiring a secure connection for bind operations only applies to authenticated binds. Bind operations without a password (anonymous and unauthenticated binds) can proceed over standard connections.
  1. Set the nsslapd-require-secure-binds configuration parameter to on: 
    # dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-require-secure-binds=on
  2. Restart the instance: 
    # dsctl instance_name restart

20.12.2. Disabling Anonymous Binds

If a user attempts to connect to the Directory Server without supplying any user name or password, this is an anonymous bind. Anonymous binds simplify common search and read operations, like checking the directory for a phone number or email address, by not requiring users to authenticate to the directory first.

Note

By default, anonymous binds are allowed (on) for search and read operations. This allows access to regular directory entries, which includes user and group entries as well as configuration entries like the root DSE. A different option, rootdse, allows anonymous search and read access to search the root DSE itself, but restricts access to all other directory entries.
However, there are risks with anonymous binds. Adequate ACIs must be in place to restrict access to sensitive information and to disallow actions like modifies and deletes. Additionally, anonymous binds can be used for denial of service attacks or for malicious people to gain access to the server.
Section 18.11.1.1.3, “Granting Anonymous Access” has an example on setting ACIs to control what anonymous users can access, and Section 14.5.4, “Setting Resource Limits on Anonymous Binds” has information on placing resource limits for anonymous users.
If those options do not offer a sufficient level of security, then anonymous binds can be disabled entirely:
  1. Set the nsslapd-allow-anonymous-access configuration parameter to off: 
    # dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-allow-anonymous-access=off
  2. Restart the instance: 
    # dsctl instance_name restart

Note

With anonymous binds disabled, the users cannot log in using their RDN. They are required to provide the full DN to log in.
In addition, when you disable anonymous binds, unauthenticated binds are also disabled automatically.

20.12.3. Allowing Unauthenticated Binds

Unauthenticated binds are connections to Directory Server where a user supplies an empty password. Using the default settings, Directory Server denies access in this scenario for security reasons: 
# ldapsearch -w "" -p 389 -h server.example.com -b "dc=example,dc=com" \
     -s sub -x "(objectclass=*)"

ldap_bind: Server is unwilling to perform (53)
	additional info: Unauthenticated binds are not allowed

Warning

Red Hat recommends not enabling unauthenticated binds. This authentication method enables users to bind without supplying a password as any account, including the Directory Manager. After the bind, the user can access all data with the permissions of the account used to bind.
To enable insecure unauthenticated binds, set the nsslapd-allow-unauthenticated-binds configuration option to on: 
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-allow-unauthenticated-binds=on

20.12.4. Configuring Autobind

Autobind is a way to connect to the Directory Server based on local UNIX credentials, which are mapped to an identity stored in the directory itself. Autobind is configured in two parts:
Before configuring autobind, first make sure that LDAPI is enabled. Then, configure the autobind mappings (in Section 20.12.4.2, “Configuring the Autobind Feature”).

20.12.4.1. Overview of Autobind and LDAPI

Inter-process communication (IPC) is a way for separate processes on a Unix machine or a network to communicate directly with each other. LDAPI is a way to run LDAP connections over these IPC connections, meaning that LDAP operations can run over Unix sockets. These connections are much faster and more secure than regular LDAP connections.
The Directory Server uses these LDAPI connections to allow users to bind immediately to the Directory Server or to access the Directory Server using tools which support connections over Unix sockets. Autobind uses the uid:gid of the Unix user and maps that user to an entry in the Directory Server, then allows access for that user.
Autobind allows mappings to three directory entries:
  • User entries, if the Unix user matches one user entry
  • Directory Manager if the Unix user is root or the super user defined in nsslapd-ldapimaprootdn
Autobind Connection Path

Figure 20.1. Autobind Connection Path

The special autobind users are entries beneath a special autobind suffix (outside the regular user subtree). The entries underneath are identified by their user and group ID numbers: 
gidNumber=gid+uidNumberuid, autobindsuffix
If autobind is not enabled but LDAPI is, then Unix users are anonymously bound to the Directory Server, unless they provide other bind credentials.

Note

Autobind allows a client to send a request to the Directory Server without supplying a bind user name and password or using other SASL authentication mechanism. According to the LDAP standard, if bind information is not given with the request, the server processes the request as an anonymous bind. To be compliant with the standard, which requires some kind of bind information, any client that uses autobind should send the request with SASL/EXTERNAL.
For more information on configuring SASL, see Section 9.10, “Setting up SASL Identity Mapping”.

20.12.4.2. Configuring the Autobind Feature

Enabling the Autobind feature allows only anonymous access to Directory Server. However, you can configure to map Linux users to Directory Server entries and also to map the root user to the Directory Manager:
  1. Verify that the nsslapd-ldapiautobind parameter is enabled, which is the default: 
    # dsconf -D "cn=Directory Manager" ldap://server.example.com config get nsslapd-ldapiautobind
nsslapd-ldapiautobind: on
  2. If nsslapd-ldapiautobind parameter is set to off, enable it: 
    # dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-ldapiautobind=on
  3. To map user entries, set, for example: 
    # dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-ldapimaptoentries=on nsslapd-ldapiuidnumbertype=uidNumber nsslapd-ldapigidnumbertype=gidNumber nsslapd-ldapientrysearchbase=ou=People,dc=example,dc=com
    • nsslapd-ldapimaptoentries=on enables entry mapping.
    • nsslapd-ldapiuidnumbertype=uidNumber sets the attribute in Directory Server that contains the Unix UID number.
    • nsslapd-ldapigidnumbertype=gidNumber sets the attribute in Directory Server that contains the Unix GID number.
    • nsslapd-ldapientrysearchbase=ou=People,dc=example,dc=com sets the DN where to search user entries.
  4. Optionally, to map the root user in Red Hat Enterprise Linux to the cn=Directory Manager account in Directory Server: 
    # dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-ldapimaprootdn="cn=Directory Manager"
  5. Restart the instance: 
    # dsctl instance_name restart
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.