13.5. 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 13.5.1, “Requiring Secure Binds”) or streamline bind operations (such as Section 13.5.4, “Configuring Autobind”).

13.5.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 (SSL/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 and 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: 
    /usr/lib64/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389

dn: cn=config
changetype: modify
replace: nsslapd-require-secure-binds
nsslapd-require-secure-binds: on
  2. Restart the server. 
    service dirsrv restart

13.5.2. Disabling Anonymous Binds

If a user attempts to connect to the Directory Server without supplying any username 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.
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 12.9.1, “Granting Anonymous Access” has examples on setting ACIs to control what anonymous users can access, and Section 13.4.3, “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: 
    /usr/lib64/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389

dn: cn=config
changetype: modify
replace: nsslapd-allow-anonymous-access
nsslapd-allow-anonymous-access: off
  2. Restart the server. 
    service dirsrv restart

NOTE

When anonymous binds are disabled, unauthenticated binds are also disabled automatically.

13.5.3. Allowing Unauthenticated Binds

An unauthenticated bind is a bind where the user supplies a username but not a password. For example, running an ldapsearch without supplying a password option: 
/usr/lib64/mozldap/ldapsearch -D "cn=directory manager" -b "dc=example,dc=com" -s sub "(objectclass=*)"
When unauthenticated binds are allowed, the bind attempt goes through as an anonymous bind.
Unauthenticated binds are less secure than authenticated binds, and in some directories can be used to circumvent ACIs or performs denial-of-service attacks. This is why in Directory Server unauthenticated binds are disabled by default. If a user tries to bind without a password, the attempt fails: 
ldap_simple_bind: DSA is unwilling to perform
ldap_simple_bind: additional info: Unauthenticated binds are not allowed
Unauthenticated binds only apply to bind attempts where a password is not given but a bind identity is. If the wrong password is given, the operation fails with an invalid credentials error: 
ldap_simple_bind: Invalid credentials
If no bind ID or password is given, then the directory returns whatever information is allowed for an anonymous bind.
The nsslapd-allow-unauthenticated-binds attribute sets whether to allow an unauthenticated bind to succeed as an anonymous bind. Setting this parameter to on allows unauthenticated binds. By default, this parameter is off.
  1. To configure unauthenticated binds, edit the Directory Server cn=config entry: 
    /usr/lib64/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.com

dn: cn=config
changetype:replace
replace: nsslapd-allow-unauthenticated-binds
nsslapd-allow-unauthenticated-binds: on
  2. Restart the server. 
    service dirsrv restart

13.5.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 13.5.4.2, “Configuring Autobind”).

13.5.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 13.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 username 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 14.3, “Using SASL”.

13.5.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. 
    /usr/lib64/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 -h server.example.com

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. 
    service dirsrv restart example