Show Table of Contents
19.11. 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 19.11.1, “Requiring Secure Binds”) or streamline bind operations (such as Section 19.11.4, “Configuring Autobind”).
19.11.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 Start TLS), 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.
- Add the
nsslapd-require-secure-binds
attribute to thecn=config
entry:# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-require-secure-binds nsslapd-require-secure-binds: on
- Restart the server.
# systemctl restart dirsrv.target
19.11.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.13.1.1.3, “Granting Anonymous Access” has an example on setting ACIs to control what anonymous users can access, and Section 14.1.5, “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.
- Add the
nsslapd-allow-anonymous-access
attribute to thecn=config
entry:# ldapmodify -D "cn=Directory Manager" -W -x dn: cn=config changetype: modify replace: nsslapd-allow-anonymous-access nsslapd-allow-anonymous-access: off
- Restart the server.
# systemctl restart dirsrv.target
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.
19.11.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
to on
:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config changetype: modify replace: nsslapd-allow-unauthenticated-binds nsslapd-allow-unauthenticated-binds: on
19.11.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 (in Section 1.6, “Enabling LDAPI”). Then, configure the autobind mappings (in Section 19.11.4.2, “Configuring Autobind”).
19.11.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 (or the super user defined in
nsslapd-ldapimaprootdn
), if the Unix user isroot

Figure 19.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.9, “Setting up SASL Identity Mapping”.
19.11.4.2. Configuring Autobind
Configuring autobind alone allows anonymous access to the Directory Server. It is possible to enable mapping Unix users to entries and also to map
root
to Directory Manager.
- Run
ldapmodify
to update the Directory Server configuration.#ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=config changetype: modify
- Enable autobind.
replace: nsslapd-ldapiautobind nsslapd-ldapiautobind: on
- To map user entries, add four attributes:
nsslapd-ldapimaptoentries
to enable entry mappingnsslapd-ldapiuidnumbertype
to set the Directory Server attribute to map to the Unix UID numbernsslapd-ldapigidnumbertype
to set the Directory Server attribute to map to the Unix group ID numbernsslapd-ldapientrysearchbase
to set the search base to use to find Directory Server user entries
add: nsslapd-ldapimaptoentries nsslapd-ldapimaptoentries: on - add: nsslapd-ldapiuidnumbertype nsslapd-ldapiuidnumbertype: uidNumber - add: nsslapd-ldapigidnumbertype nsslapd-ldapigidnumbertype: gidNumber - add: nsslapd-ldapientrysearchbase nsslapd-ldapientrysearchbase: ou=people,dc=example,dc=com
- To map the
root
entry to Directory Manager, add thensslapd-ldapimaprootdn
attribute:add: nsslapd-ldapimaprootdn nsslapd-ldapimaprootdn: cn=Directory Manager
- Restart the server to apply the new configuration.
# systemctl restart dirsrv@instance