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.
  1. Add the nsslapd-require-secure-binds attribute to the cn=config entry: 
    # ldapmodify -D "cn=Directory Manager" -W -x

dn: cn=config
changetype: modify
replace: nsslapd-require-secure-binds
nsslapd-require-secure-binds: on
  2. 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.
  1. Add the nsslapd-allow-anonymous-access attribute to the cn=config entry: 
    # ldapmodify -D "cn=Directory Manager" -W -x

  dn: cn=config
  changetype: modify
  replace: nsslapd-allow-anonymous-access
  nsslapd-allow-anonymous-access: off
  2. 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 is root
Autobind Connection Path

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.
  1. 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
  2. Enable autobind. 
    replace: nsslapd-ldapiautobind
nsslapd-ldapiautobind: on
  3. To map user entries, add four attributes:
    • nsslapd-ldapimaptoentries to enable entry mapping
    • nsslapd-ldapiuidnumbertype to set the Directory Server attribute to map to the Unix UID number
    • nsslapd-ldapigidnumbertype to set the Directory Server attribute to map to the Unix group ID number
    • nsslapd-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
  4. To map the root entry to Directory Manager, add the nsslapd-ldapimaprootdn attribute: 
    add: nsslapd-ldapimaprootdn
nsslapd-ldapimaprootdn: cn=Directory Manager
  5. Restart the server to apply the new configuration. 
    # systemctl restart dirsrv@instance