Postfix LDAP Howto

LDAP Support in Postfix

Postfix can use an LDAP directory as a source for any of its
lookups: aliases(5), virtual(5), canonical(5), etc. This allows
you to keep information for your mail service in a replicated
network database with fine-grained access controls. By not storing
it locally on the mail server, the administrators can maintain it
from anywhere, and the users can control whatever bits of it you
think appropriate. You can have multiple mail servers using the
same information, without the hassle and delay of having to copy
it to each.

The 'make tidy' command is needed only if you have previously
built Postfix without LDAP support.

Instead of '/usr/local' specify the actual locations of your
LDAP include files and libraries. Be sure to not mix LDAP include
files and LDAP libraries of different versions!!

If your LDAP libraries were built with Kerberos support, you'll
also need to include your Kerberos libraries in this line. Note
that the KTH Kerberos IV libraries might conflict with Postfix's
lib/libdns.a, which defines dns_lookup. If that happens, you'll
probably want to link with LDAP libraries that lack Kerberos support
just to build Postfix, as it doesn't support Kerberos binds to the
LDAP server anyway. Sorry about the bother.

If you're using one of the Netscape LDAP SDKs, you'll need to
change the AUXLIBS line to point to libldap10.so or libldapssl30.so
or whatever you have, and you may need to use the appropriate linker
option (e.g. '-R') so the executables can find it at runtime.

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.my.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.

If you want to keep information for virtual lookups in your
directory, it's only a little more complicated. First, you need to
make sure Postfix knows about the virtual domain. An easy way to
do that is to add the domain to the mailacceptinggeneralid attribute
of some entry in the directory. Next, you'll want to make sure all
of your virtual recipient's mailacceptinggeneralid attributes are
fully qualified with their virtual domains. Finally, if you want
to designate a directory entry as the default user for a virtual
domain, just give it an additional mailacceptinggeneralid (or the
equivalent in your directory) of "@virtual.dom". That's right, no
user part. If you don't want a catchall user, omit this step and
mail to unknown users in the domain will simply bounce.

In summary, you might have a catchall user for a virtual domain
that looks like this:

Other common uses for LDAP lookups include rewriting senders and
recipients with Postfix's canonical lookups, for example in order
to make mail leaving your site appear to be coming from
"First.Last@site.dom" instead of "userid@site.dom".

The bits of schema and attribute names used in this document are just
examples. There's nothing special about them, other than that some are
the defaults in the LDAP configuration parameters. You can use
whatever schema you like, and configure Postfix accordingly.

You probably want to make sure that mailacceptinggeneralids are
unique, and that not just anyone can specify theirs as postmaster or
root, say.

An entry can have an arbitrary number of mailacceptinggeneralids or
maildrops. Maildrops can also be comma-separated lists of addresses.
They will all be found and returned by the lookups. For example, you
could define an entry intended for use as a mailing list that looks
like this (Warning! Schema made up just for this example):

If you use an LDAP map for lookups other than aliases, you may have to
make sure the lookup makes sense. In the case of virtual lookups,
maildrops other than mail addresses are pretty useless, because
Postfix can't know how to set the ownership for program or file
delivery. Your query_filter should probably look something like this:

And for that matter, even for aliases, you may not want users able to
specify their maildrops as programs, includes, etc. This might be
particularly pertinent on a "sealed" server where they don't have
local UNIX accounts, but exist only in LDAP and Cyrus. You might allow
the fun stuff only for directory entries owned by an administrative
account,
so that if the object had a program as its maildrop and weren't owned
by "cn=root" it wouldn't be returned as a valid local user. This will
require some thought on your part to implement safely, considering the
ramifications of this type of delivery. You may decide it's not worth
the bother to allow any of that nonsense in LDAP lookups, ban it in
the query_filter, and keep things like majordomo lists in local alias
databases.

LDAP lookups are slower than local DB or DBM lookups. For most sites
they won't be a bottleneck, but it's a good idea to know how to tune
your directory service.

Multiple LDAP maps share the same LDAP connection if they differ
only in their query related parameters: base, scope, query_filter, and
so on. To take advantage of this, avoid spurious differences in the
definitions of LDAP maps: host selection order, version, bind, tls
parameters, ... should be the same for multiple maps whenever possible.

If you have questions, send them to postfix-users@postfix.org. Please
include relevant information about your Postfix setup: LDAP-related
output from postconf, which LDAP libraries you built with, and which
directory server you're using. If your question involves your directory
contents, please include the applicable bits of some directory entries.