LDAP_TABLE(5) | File Formats Manual | LDAP_TABLE(5) |
ldap_table - Postfix LDAP client configuration
postmap -q "string" ldap:/etc/postfix/filename postmap -q - ldap:/etc/postfix/filename <inputfile
The Postfix mail system uses optional tables for address rewriting or mail routing. These tables are usually in dbm or db format.
Alternatively, lookup tables can be specified as LDAP databases.
In order to use LDAP lookups, define an LDAP source as a lookup table in main.cf, for example:
alias_maps = ldap:/etc/postfix/ldap-aliases.cf
The file /etc/postfix/ldap-aliases.cf has the same format as the Postfix main.cf file, and can specify the parameters described below. An example is given at the end of this manual.
This configuration method is available with Postfix version 2.1 and later. See the section "OBSOLETE MAIN.CF PARAMETERS" below for older Postfix versions.
For details about LDAP SSL and STARTTLS, see the section on SSL and STARTTLS below.
When using LDAP to store lists such as $mynetworks, $mydestination, $relay_domains, $local_recipient_maps, etc., it is important to understand that the table must store each list member as a separate key. The table lookup verifies the *existence* of the key. See "Postfix lists versus tables" in the DATABASE_README document for a discussion.
Do NOT create tables that return the full list of domains in $mydestination or $relay_domains etc., or IP addresses in $mynetworks.
DO create tables with each matching item as a key and with an arbitrary value. With LDAP databases it is not uncommon to return the key itself.
For example, NEVER do this in a map defining $mydestination:
query_filter = domain=*
result_attribute = domain
Do this instead:
query_filter = domain=%s
result_attribute = domain
In the text below, default values are given in parentheses. Note: don't use quotes in these variables; at least, not until the Postfix configuration routines understand how to deal with quoted strings.
server_host = ldap.example.com
Depending on the LDAP client library you're using, it should be possible to specify multiple servers here, with the library trying them in order should the first one fail. It should also be possible to give each server in the list a different port (overriding server_port below), by naming them like
server_host = ldap.example.com:1444
With OpenLDAP, a (list of) LDAP URLs can be used to specify both the hostname(s) and the port(s):
server_host = ldap://ldap.example.com:1444
ldap://ldap2.example.com:1444
All LDAP URLs accepted by the OpenLDAP library are supported, including connections over UNIX domain sockets, and LDAP SSL (the last one provided that OpenLDAP was compiled with support for SSL):
server_host = ldapi://%2Fsome%2Fpath
ldaps://ldap.example.com:636
server_port = 778
timeout = 5
search_base = dc=your, dc=com
query_filter = (&(mail=%s)(paid_up=true))
This parameter supports the following '%' expansions:
NOTE: DO NOT put quotes around the query_filter parameter.
The default value %s specifies that each attribute value should be used as is.
This parameter was called result_filter in Postfix releases prior to 2.2. If no "result_format" is specified, the value of "result_filter" will be used instead before resorting to the default value. This provides compatibility with old configuration files.
NOTE: DO NOT put quotes around the result format!
domain = postfix.org, hash:/etc/postfix/searchdomains
It is best not to use LDAP to store the domains eligible for LDAP lookups.
NOTE: DO NOT define this parameter for local(8) aliases.
This feature is available in Postfix 1.0 and later.
result_attribute = mailbox, maildrop
Don't rely on the default value ("maildrop"). Set the result_attribute explicitly in all ldap table configuration files. This is particularly relevant when no result_attribute is applicable, e.g. cases in which leaf_result_attribute and/or terminal_result_attribute are used instead. The default value is harmless if "maildrop" is also listed as a leaf or terminal result attribute, but it is best to not leave this to chance.
special_result_attribute = memberdn
DN recursion retrieves the same result_attributes as the main query, including the special attributes for further recursion.
URL processing retrieves only those attributes that are included in both the URL definition and as result attributes (ordinary, special, leaf or terminal) in the Postfix table definition. If the URL lists any of the table's special result attributes, these are retrieved and used recursively. A URL that does not specify any attribute selection, is equivalent (RFC 2255) to a URL that selects all attributes, in which case the selected attributes will be the full set of result attributes in the Postfix table.
If an LDAP URL attribute-descriptor or the corresponding Postfix LDAP table result attribute (but not both) uses RFC 2255 sub-type options ("attr;option"), the attribute requested from the LDAP server will include the sub-type option. In all other cases, the URL attribute and the table attribute must match exactly. Attributes with options in both the URL and the Postfix table are requested only when the options are identical. LDAP attribute-descriptor options are very rarely used, most LDAP users will not need to concern themselves with this level of nuanced detail.
result_attribute =
terminal_result_attribute = maildrop
When using terminal and/or leaf result attributes, the result_attribute is best set to an empty value when it is not used, or else explicitly set to the desired value, even if it is the default value "maildrop".
This feature is available with Postfix 2.4 or later.
result_attribute = memberaddr
special_result_attribute = memberdn
terminal_result_attribute = maildrop
leaf_result_attribute = mail
When using terminal and/or leaf result attributes, the result_attribute is best set to an empty value when it is not used, or else explicitly set to the desired value, even if it is the default value "maildrop".
This feature is available with Postfix 2.4 or later.
# Don't bind
bind = no
# Use SIMPLE bind
bind = yes
# Use SASL bind
bind = sasl
Postfix versions prior to 2.8 only support "bind = no" which means don't bind, and "bind = yes" which means do a SIMPLE bind. Postfix 2.8 and later also supports "bind = SASL" when compiled with LDAP SASL support as described in LDAP_README, it also adds the synonyms "bind = none" and "bind = simple" for "bind = no" and "bind = yes" respectively. See the SASL section below for additional parameters available with "bind = sasl".
If you do need to bind, you might consider configuring Postfix to connect to the local machine on a port that's an SSL tunnel to your LDAP server. If your LDAP server doesn't natively support SSL, put a tunnel (wrapper, proxy, whatever you want to call it) on that system too. This should prevent the password from traversing the network in the clear.
With "bind = sasl" (see above) the DN may be optional for some SASL mechanisms, don't specify a DN if not needed.
bind_dn = uid=postfix, dc=your, dc=com
With "bind = sasl" (see above) the password may be optional for some SASL mechanisms, don't specify a password if not needed.
bind_pw = postfixpw
Note: even a single LDAP entry can generate multiple lookup results, via multiple result attributes and/or multi-valued result attributes. This limit caps the per search resource utilization on the LDAP server, not the final multiplicity of the lookup result. It is analogous to the "-z" option of "ldapsearch".
If you're using the OpenLDAP libraries compiled with SASL support, Postfix 2.8 and later built with LDAP SASL support as described in LDAP_README can authenticate to LDAP servers via SASL.
This enables authentication to the LDAP server via mechanisms other than a simple password. The added flexibility has a cost: it is no longer practical to set an explicit timeout on the duration of an LDAP bind operation. Under adverse conditions, whether a SASL bind times out, or if it does, the duration of the timeout is determined by the LDAP and SASL libraries.
It is best to use tables that use SASL binds via proxymap(8), this way the requesting process can time-out the proxymap request. This also lets you tailer the process environment by overriding the proxymap(8) import_environment setting in master.cf(5). Special environment settings may be needed to configure GSSAPI credential caches or other SASL mechanism specific options. The GSSAPI credentials used for LDAP lookups may need to be different than say those used for the Postfix SMTP client to authenticate to remote servers.
Using SASL mechanisms requires LDAP protocol version 3, the default protocol version is 2 for backwards compatibility. You must set "version = 3" in addition to "bind = sasl".
The following parameters are relevant to using LDAP with SASL
If you're using the OpenLDAP libraries compiled with SSL support, Postfix can connect to LDAP SSL servers and can issue the STARTTLS command.
LDAP SSL service can be requested by using a LDAP SSL URL in the server_host parameter:
server_host = ldaps://ldap.example.com:636
STARTTLS can be turned on with the start_tls parameter:
start_tls = yes
Both forms require LDAP protocol version 3, which has to be set explicitly with:
version = 3
If any of the Postfix programs querying the map is configured in master.cf to run chrooted, all the certificates and keys involved have to be copied to the chroot jail. Of course, the private keys should only be readable by the user "postfix".
The following parameters are relevant to LDAP SSL and STARTTLS:
With no, the server certificate trust chain is not checked, but with OpenLDAP prior to 2.1.13, the name in the server certificate must still match the LDAP server name. With OpenLDAP 2.0.0 to 2.0.11 the server name is not necessarily what you specified, rather it is determined (by reverse lookup) from the IP address of the LDAP server connection. With OpenLDAP prior to 2.0.13, subjectAlternativeName extensions in the LDAP server certificate are ignored: the server name must match the subject CommonName. The no setting corresponds to the never value of TLS_REQCERT in LDAP client configuration files.
Don't use TLS with OpenLDAP 2.0.x (and especially with x <= 11) if you can avoid it.
With yes, the server certificate must be issued by a trusted CA, and not be expired. The LDAP server name must match one of the name(s) found in the certificate (see above for OpenLDAP library version dependent behavior). The yes setting corresponds to the demand value of TLS_REQCERT in LDAP client configuration files.
The "try" and "allow" values of TLS_REQCERT have no equivalents here. They are not available with OpenLDAP 2.0, and in any case have questionable security properties. Either you want TLS verified LDAP connections, or you don't.
The yes value only works correctly with Postfix 2.5 and later, or with OpenLDAP 2.0. Earlier Postfix releases or later OpenLDAP releases don't work together with this setting. Support for LDAP over TLS was added to Postfix based on the OpenLDAP 2.0 API.
Here's a basic example for using LDAP to look up local(8) aliases. Assume that in main.cf, you have:
alias_maps = hash:/etc/aliases,
ldap:/etc/postfix/ldap-aliases.cf
and in ldap:/etc/postfix/ldap-aliases.cf you have:
server_host = ldap.example.com
search_base = dc=example, dc=com
Upon receiving mail for a local address "ldapuser" that isn't found in the /etc/aliases database, Postfix will search the LDAP server listening at port 389 on ldap.example.com. It will bind anonymously, search for any directory entries whose mailacceptinggeneralid attribute is "ldapuser", read the "maildrop" attributes of those found, and build a list of their maildrops, which will be treated as RFC822 addresses to which the message will be delivered.
For backwards compatibility with Postfix version 2.0 and earlier, LDAP parameters can also be defined in main.cf. Specify as LDAP source a name that doesn't begin with a slash or a dot. The LDAP parameters will then be accessible as the name you've given the source in its definition, an underscore, and the name of the parameter. For example, if the map is specified as "ldap:ldapsource", the "server_host" parameter below would be defined in main.cf as "ldapsource_server_host".
Note: with this form, the passwords for the LDAP sources are written in main.cf, which is normally world-readable. Support for this form will be removed in a future Postfix version.
For backwards compatibility with the pre 2.2 LDAP clients, result_filter can for now be used instead of result_format, when the latter parameter is not also set. The new name better reflects the function of the parameter. This compatibility interface may be removed in a future release.
postmap(1), Postfix lookup table manager postconf(5), configuration parameters mysql_table(5), MySQL lookup tables pgsql_table(5), PostgreSQL lookup tables
Use "postconf readme_directory" or "postconf html_directory" to locate this information.
DATABASE_README, Postfix lookup table overview LDAP_README, Postfix LDAP client guide
The Secure Mailer license must be distributed with this software.
Carsten Hoeger, Hery Rakotoarisoa, John Hensley, Keith Stevenson, LaMont Jones, Liviu Daia, Manuel Guesdon, Mike Mattice, Prabhat K Singh, Sami Haahtinen, Samuel Tardieu, Victor Duchovni, and many others.