LDAPD.CONF(5) | File Formats Manual | LDAPD.CONF(5) |
ldapd.conf
—
Lightweight Directory Access Protocol daemon configuration
file
ldapd.conf
is the configuration file for
the LDAP daemon ldapd(8).
The current line can be extended over multiple lines using a backslash (‘\’). Comments can be put anywhere in the file using a hash mark (‘#’), and extend to the end of the current line. Care should be taken when commenting out multi-line text: the comment is effective until the end of the entire block.
Argument names not beginning with a letter, digit, or underscore must be quoted. Arguments containing whitespace should be surrounded by double quotes (").
Macros can be defined that will later be expanded in context. Macro names must start with a letter, digit, or underscore, and may contain any of those characters. Macro names may not be reserved words (for example listen, namespace, port). Macros are not expanded inside quotes.
For example:
wan_if = "fxp0" listen on $wan_if listen on $wan_if tls
Additional configuration files can be included with the
include
keyword, for example:
include "/etc/ldap/sub.namespace.conf"
Additional schema files can be included with the
schema
keyword, for example:
schema "/etc/ldap/inetorgperson.schema"
The syntax of ldapd.conf
is described
below.
listen
on
interface [port
port] [legacy
]
[tls
| ldaps
|
secure
] [certificate
name]Secured connections are provided either using STARTTLS
(tls
), by default on port 389, or LDAPS
(ldaps
), by default on port 636.
tls
and ldaps
connections will use the defaults from libtls. If compatibility with the
insecure TLSv1.0 and TLSv1.1 protocols and ciphers is required, they can
be enabled with the legacy
keyword. Creation of
certificates is documented in
starttls(8). If no certificate
name is specified, the
/etc/ldap/certs directory is searched for a file
named by joining the interface name with a .crt extension, e.g.
/etc/ldap/certs/fxp0.crt.
If the certificate name is an absolute path, a .crt and .key extension are appended to form the certificate path and key path respectively.
Only secured connections accept plain text password
authentication. Connections using TLS or unix domain sockets are always
considered secured. The secure
keyword can be
used to mark an otherwise insecure connection secured, e.g. if IPsec is
used.
This option can be given multiple times, in which case the URLs are considered equal. Clients may choose to follow any of the referral URLs.
The URL has the following format:
ldap://ldap.example.com ldaps://ldap.example.com:3890
A namespace is a subtree of the global X.500 DIT (Directory Information Tree), also known as a naming context. All entries' distinguished names (DN) have the same suffix, which is used to identify the namespace. The suffix should consist of the domain components, in reverse order, of your domain name, as recommended by RFC 2247.
namespace "dc=example,dc=com" { rootdn "cn=admin,dc=example,dc=com" rootpw "secret" }
When matching requests against namespace suffixes, the most specific match is used. Each namespace stores data in a separate database file.
A namespace has the following configuration properties:
Cached pages are expired in a least recently used (LRU) order.
allow
|
deny
Each request to the ldapd(8) daemon evaluates the filter rules in sequential order, from first to last. The last matching rule decides what action is taken. If no rule matches the request, the default action is to allow the request. The root DN is always allowed to perform any request.
The allow/deny statement operates on all access types by default. This can be restricted by an access type specification:
The scope of the filter rule can be restricted by the to keyword:
The scope can be restricted to an optional attribute:
Finally, the filter rule can match a bind DN:
Schema files define the structure and format of entries in the directory tree. There are three types of definitions in a schema file:
An attribute type definition specifies the syntax of attribute values, whether it allows multiple values and how it can be compared in search requests. For a complete description of attribute type definitions, see section 4.1.2 in RFC 4512.
An object class definition specifies which attributes are required and which are allowed. For a complete description of object class definitions, see section 4.1.1 in RFC 4512.
objectidentifier MyOidRoot 1.2.3.4 objectidentifier MyOidAttributes MyOidRoot:5.6 objectidentifier MyOidObjects MyOidRoot:7
This would define MyOidAttributes as a symbolic name for the OID 1.2.3.4.5.6, and MyOidObjects for 1.2.3.4.7.
K. Zeilenga, Lightweight Directory Access Protocol (LDAP): Directory Information Models, RFC 4512, June 2006.
The ldapd.conf
file format first appeared
in OpenBSD 4.8.
June 24, 2020 | OpenBSD-current |