How to Configure OpenLDAP Access Control

Configure OpenLDAP access control rules that select the right entries and attributes, match identities correctly, and grant only required privileges.

Type
Tutorial
Level
Advanced
Technologies
OpenLDAP, LDAP
On this page

The Importance of Access Control in OpenLDAP

Access control is the foundation of any secure OpenLDAP deployment. Without carefully crafted access control lists (ACLs), directory data—including sensitive attributes like passwords and personal information—is exposed to unwanted disclosure or modification. OpenLDAP’s ACL system is not simply about authentication; it is a strict, ordered set of rules that determines who can access which parts of the directory for what operations. Even with strong authentication, a misconfigured default can result in anonymous users reading or modifying private data. Understanding and properly configuring ACLs is absolutely critical—both to restrict access and to enable legitimate use cases like self-service password changes, group management, and administrative operations.

Access and authentication are distinct concepts: binding controls who a user claims to be, but ACLs specify what any given user can read, search, or modify. An insecure rule at the top of your ACLs can override all later protections, exposing or damaging your directory—even if your authentication mechanisms are robust.

OpenLDAP Access Control Basics: How Rules Work

OpenLDAP’s ACLs act much like an ordered firewall for directory operations. Each rule matches a part of the directory (what), a set of subjects (who), and a level of access (how much). The major concepts are as follows:

  • Rule Components:

    • What: The directory subtree (e.g., by DN or entry or attribute) the rule applies to.
    • Who: The target subjects, such as a named DN, group, anonymous, self, or users.
    • Access: The permission level granted, ranging from none to manage.

  • Evaluation Order:
    Rules are parsed and processed top-down; the first rule that matches the target and operation is applied. This order is critical: a broad rule placed before a restrictive one can make the restrictive rule unreachable.

  • Access Levels:
    OpenLDAP defines several finely grained access levels:

    • none: No access
    • disclose: Permit existence checks (not shown in search results)
    • auth: Allow authentication (e.g., to bind using a password attribute)
    • compare: Allow compare operations without revealing value
    • search: Allow inclusion in search results
    • read: Allow attribute value reading
    • write: Allow modification (including deletes and adds)
    • manage: Full control (including ACL management, if not rootdn)

    For example, to prevent accidental exposure of userPassword, set access to auth (for binding) and otherwise deny read/search unless for the owner. If two rules overlap, the first match decides which applies—even if it’s less restrictive.

Configuring ACLs: slapd.conf vs slapd-config (cn=config)

ACL management in OpenLDAP can be performed through two configuration paradigms:

slapd.conf (File-Based Configuration)

  • Where: ACLs are defined directly in the slapd.conf configuration file using access directives.
  • How: Editing is performed by manually changing the file and restarting the slapd service; configuration is static.

Example (in slapd.conf):

text
access to attrs=userPassword
  by self write
  by anonymous auth
  by * none

slapd-config (Dynamic cn=config using LDIF)

  • Where: ACLs are stored as olcAccess attributes in the cn=config directory tree.
  • How: Changes are made through LDAP operations (usually via an LDIF update), allowing for dynamic updates without restarting slapd.

Example (as LDIF fragment for cn=config):

ldif
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: to attrs=userPassword by self write by anonymous auth by * none

To update ACLs in slapd-config, construct an LDIF similar to above and apply it with ldapmodify as the configuration admin user. Each olcAccess attribute corresponds to an ACL rule—ordered numerically by their attribute index.

  • Key differences:
    • Order of rules is determined by the sequence of olcAccess attributes, just as lines in slapd.conf.
    • Syntax is very similar between both methods.
    • slapd-config is the preferred method in contemporary OpenLDAP deployments for its dynamic management.

Crafting Effective and Secure ACLs: Common Patterns

Defensible OpenLDAP deployments rely on explicit, carefully constructed rules. The most common patterns you’ll need to implement include:

Restricting Access to Sensitive Attributes

Protecting userPassword: A standard pattern ensures only authenticated users can attempt to bind (using auth), users can change their own password, and everyone else is denied all access:

text
access to attrs=userPassword
  by self write
  by anonymous auth
  by * none

This pattern blocks reading of the password attribute while still allowing password-based authentication and user self-service resets.

Allowing Self-Modification

Users frequently need to update their own information (e.g., phone numbers):

text
access to dn.subtree="ou=users,dc=example,dc=com"
  by self write
  by * read

This grants users modification rights for their directory entry, but only for themselves.

Denying Anonymous Access

By default, OpenLDAP may permit unauthenticated (anonymous) users to read the directory if not explicitly denied. Close this exposure with a rule such as:

text
access to *
  by anonymous none
  by users read

Place restrictive or exception rules first; broad catch-alls to follow.

Safe Default ACL Order

  1. Most-restrictive, specific rules (e.g., block access to userPassword)
  2. Needed exceptions (e.g., allow self-modification)
  3. Group or admin access
  4. Deny anonymous access
  5. Catch-all rules (lowest priority, least permissive)

Order matters—specific rules must precede more general or permissive ones.

Implementing Group-Based Access Control

Granting access based on group membership is a powerful pattern for managing permissions at scale. OpenLDAP supports dynamic group-based ACLs leveraging correct schema definitions.

How Group-Based ACLs Work

You can specify that access to certain entries or attributes is permitted to the members of a specific group, identified by its DN. The group must be represented in the directory using an objectClass with a DN-valued attribute.

Supported forms include:

  • groupOfNames/member
  • organizationalRole/roleOccupant

Example—granting write access to members of cn=admins,ou=groups,dc=example,dc=com:

text
access to dn.subtree="ou=users,dc=example,dc=com"
  by group/groupOfNames/member="cn=admins,ou=groups,dc=example,dc=com" write
  by * read

This allows all DNs listed as member attributes of the admins group to write to any user entry. The group attribute must contain valid DNs—schema correctness is mandatory.

Key Nuances

  • You can use organizationalRole with the roleOccupant DN attribute instead of groupOfNames/member if it better matches your directory design.
  • The ACL’s group clause must match the group entry’s objectClass and DN attribute exactly.
  • If the group is misconfigured (wrong attribute or missing DNs), no one will have access under that rule.

Avoiding Common Pitfalls and Misconceptions

Missteps in OpenLDAP ACL design have direct security consequences. Some classic errors include:

  • Including rootdn in ACLs:
    RootDN always has full, unrestricted access regardless of ACLs; explicitly listing it in ACLs is not only unnecessary but increases processing overhead.

  • Default overexposure:
    Many installations leave the directory readable by all, including unauthenticated users, unless a restrictive by anonymous none rule is added. Always check your effective defaults.

  • Order mistakes:
    Placing a general access to * by * read at the top makes restrictive rules below it unreachable—the order determines effective security, not just content.

  • Unsupported group attributes:
    Only DN-valued attributes—like member and roleOccupant—in supported objectClasses work for group-based ACLs. Misnaming the attribute or using a custom schema typically breaks group matching.

  • Blocking authentication:
    Setting by anonymous none on userPassword without also granting auth breaks password-based logins. Always allow auth access for anonymous on authentication attributes to support binding, but never allow read unless absolutely required.

Additional Resources and Authoritative References

For a complete reference to ACL syntax, behaviors, and advanced features, consult:

  • OpenLDAP 2.4 Administrator's Guide, Chapter 8: Access Control
  • OpenLDAP FAQ: How do I use groups to manage access control?

Both sources provide canonical examples, authoritative descriptions of behavior, and should be your reference when implementing or troubleshooting OpenLDAP ACLs.

Sources

Related resources