LDAP System Administration
Page 19
Figure 7-12. inetLocalMailRecipient object class used by Sendmail's FEATURE(`ldap_routing')
The three optional attributes in inetLocalMailRecipient are:
mailLocalAddress
The RFC 822-compliant mail address of the message recipient
mailHost
The DNS name specifying the host to which the message should be relayed
mailRoutingAddress
The RFC 822-compliant mail address to which the original recipient address should be rewritten
OpenLDAP includes a definition for the inetLocalMailRecipient object and associated attributes in misc.schema. You must include this file in slapd.conf and restart OpenLDAP before you can support Sendmail's ldap_routing feature:
## Support the inetLocalMailRecipient object.
include /usr/local/etc/openldap/schema/misc.schema
To enable LDAP mail routing, add the following feature definition to sendmail.mc:
FEATURE(`ldap_routing´)
We must also inform Sendmail which mail domains should be routed. Without control over which email domains Sendmail should attempt to look up in the directory, each incoming message triggers a lookup, resulting in severely degraded performance on high-traffic sites.
To define a single routable domain, Sendmail provides the LDAPROUTE_DOMAIN m4 macro. The configuration for your server requires you to add this line to your sendmail.mc source file:
LDAPROUTE_DOMAIN(`plainjoe.org´)
* * *
Tip
A list of LDAP-routable domains can be read from a file defined by the LDAPROUTE_DOMAIN_FILE macro. Sendmail 8.12 introduced support for retrieving such class values from a directory using the syntax LDAPROUTE_DOMAIN_FILE(`@LDAP´). More information on file class macros can be found in the documentation included with Sendmail.
* * *
As mentioned previously, ldap_routing uses the inetLocalMailRecipient object class. It is possible to use an alternative schema by defining the ldap_routing feature as:
FEATURE(`ldap_routing´,mailHost,mailRoutingAddress,bounce,detail)
The mailHost and mailRoutingAddress entries are just LDAP map configuration lines; they default to:
ldap -1 -T TMPF -v mailHost
-k (&(objectClass=inetLocalMailRecipient)
(mailLocalAddress=%0))
They also default to:
ldap -1 -T TMPF -v mailRoutingAddress
-k (&(objectClass=inetLocalMailRecipient)
(mailLocalAddress=%0))
The search filters and the resulting attributes can be redefined to better suit your directory, if required. Both the bounce and detail parameters specify actions to take if a lookup does not return any routing information. The default behavior is to accept addresses not located by the LDAP search. Sendmail's cf/README file has more details on changing this if you are interested.
The default searches used by ldap_routing do not define an LDAP server, nor do they include a search suffix. The confLDAP_DEFAULT_SPEC option can be used to specify defaults for all of Sendmail's LDAP queries (maps, aliases, classes, and mail routing):
define(`confLDAP_DEFAULT_SPEC´, `-h ldap.plainjoe.org -b
ou=people,dc=plainjoe,dc=org´)dnl
This is fully compatible with the configuration used to retrieve mail aliases from the directory. The ALIAS_FILE option used its own base suffix (-b) which overrode any matching default set by confLDAP_DEFAULT_SPEC.
With three optional attributes in the inetLocalMailRecipient object class, Sendmail must consider six unique routing cases. Note that if the mailLocalAddress attribute is absent, Sendmail will ignore the entry altogether. The possible results are described in Table 7-5.
Table 7-5. Possible results from an ldap_routing search
mailHost value
mailRoutingAddress value
Result
A local host
Exists
The recipient is rewritten to mailRoutingAddress and delivered to the local host.
A local host
Does not exist
The mail is delivered to the original address on the local host.
A remote host
Exists
The mail is relayed to the mailRoutingAddress at the mailHost.
A remote host
Does not exist
The mail is relayed to the original address at mailHost.
Does not exist
Exists
The recipient is rewritten to mailRoutingAddress and delivered to the local host.
Does not exist
Does not exist
The mail is delivered locally to the original address or possibly bounced as a unknown user.
The following LDIF listings help explain the entries in Table 7-5. Here, you extend the original user entries in the ou=people subtree. You could have created a new organizational unit beneath ou=sendmail. However, adding the mail-routing information to a user's entry means that when a user's account is deleted, the mail-routing information is removed as well.
In the first listing, the mailLocalAddress and mailHost attributes cause mail addressed to kcarter@plainjoe.org to be relayed to the host designated by mail.engr.plainjoe.org's DNS MX record for local delivery:
dn: uid=kristi,ou=people,dc=plainjoe,dc=org
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: inetLocalMailRecipient
cn: Kristi Carter
sn: Carter
mail: kcarter@plainjoe.org
mailLocalAddress: kcarter@plainjoe.org
mailHost: mail.engr.plainjoe.org
< . . . remaining attributes not shown . . . >
The following example adds the mailRoutingAddress attribute. With this attribute, all mail addressed to kcarter@plainjoe.org is relayed to the host named by the MX record for mail.engr.plainjoe.org, but only after the recipient address has been rewritten to kristi@engr.plainjoe.org:
dn: uid=kristi,ou=people,dc=plainjoe,dc=org
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: inetLocalMailRecipient
cn: Kristi Carter
sn: Carter
mail: kcarter@plainjoe.org
mailLocalAddress: kcarter@plainjoe.org
mailHost: mail.engr.plainjoe.org
mailRoutingAddress: kristi@engr.plainjoe.org
< . . . remaining attributes not shown . . . >
These rewrites can be verified using Sendmail's rule set-testing mode:
$ /usr/sbin/sendmail -bt
> /parse kcarter@plainjoe.org
< . . . intervening ruleset output deleted . . . >
mailer relay, host mail.engr.plainjoe.org,
user kristi@engr.plainjoe.org
This output shows that mail received for kcarter@plainjoe.org will be forwarded to the host mail.engr.plainjoe.org after rewriting the recipient address to kristi@engr.plainjoe.org.
The mailLocalAddress attribute can also be used to specify that all mail for a domain should be relayed to another host. The following LDIF entry relays all mail addressed to the @plainjoe.org domain to the host denoted by hq.plainjoe.org's MX record:
dn: o=plainjoe.org,ou=people,dc=plainjoe,dc=org
objectclass: organization
objectclass: inetLocalMailRecipient
o: plainjoe.org
description: plainjoe.org mail domain
mailLocalAddress: @plainjoe.org
mailHost: hq.plainjoe.org
It should be noted that Sendmail gives exact matches for the mailLocalAddress precedence over entries returned by matching the @domain syntax.
Postfix
Our next stop during this tour of MTAs is to examine Wietse Venema's Postfix mailer. This MTA is a popular replacement for Sendmail because it has:
Feature and interface compatibility with Sendmail
A simpler configuration
A history of fewer security holes
This section focuses on Postfix's abilit
y to integrate with an LDAP directory. I assume that the terminology and configuration files are familiar to Postfix administrators. If this is your first exposure to Venema's MTA, the Postfix web site (http://www.postfix.org/) offers several good documents on the software's design philosophy and architecture. It may also be helpful to refer to Postfix, by Richard Blum (Sams Publishing) for case studies of working installations.
After the gory details of configuring LDAP queries in Sendmail, Postfix's configuration files are a welcome relief. In comparison to Sendmail, Postfix's configuration is much more intuitive.
We will begin by ensuring that the proper features are enabled when you compile Postfix. The source distribution for Postfix can be downloaded from http://www.postfix.org/. Assuming that the OpenLDAP 2 client libraries have been installed in the directory /usr/local/lib/, the following commands clear all remaining intermediate files from a previous build (just to be safe), and then create the necessary Makefiles to enable LDAP client support:
$ cd postfix-1.1.2/
$ make tidy
$ make makefiles CCARGS="-I/usr/local/include -DHAS_LDAP"
> AUXLIBS="-L/usr/local/lib -lldap -llber"
$ make
$ /bin/su -c "make install"
Refer to the LDAP_README file included with the Postfix distribution for details about building the software on your server platform.
* * *
Warning
Postfix 1.1.2 will not compile when using the OpenLDAP 2.1 client libraries. You must use the most recent OpenLDAP 2.0 libraries in this case (or libraries from some other vendor described in the README_FILES/LDAP_README document). Note that this does not affect communications with an OpenLDAP 2.1 server.
* * *
Once you have built and installed Postfix, verify that LDAP support has been included. To do so, use the postconf utility installed with the Postfix server. The -m switch informs postconf to display the list of supported storage mediums for tables. The output should look something like this:
$ /usr/sbin/postconf -m
static
nis
regexp
environ
ldap
btree
unix
hash
The exact list will vary, depending on how you've built Postfix. Your immediate concern is to verify that ldap is listed as a supported storage medium. However, it's important to understand what's going on. Postfix maintains six tables, any of which may be stored on any of the media reported by postconf -m. Table 7-6 introduces each of the tables and shows which core program acts as the table's main client.
Table 7-6. Postfix tables and associated core programs
Table
Description
Core program
Access
Provides information about which messages to accept or reject based on sender, host, network , etc.
smtpd
Aliases
Provides information on redirecting mail received for local users.
local
Canonical
Provides information on local and nonlocal addresses.
cleanup
Relocated
Provides information on "user has moved to a new location" bounce messages.
qmgr
Transport
Provides information on delivery methods and relay hosts for the domain.
trivial-rewrite
Virtual
Provides information used in redirecting local and nonlocal users or domains.
cleanup
The remainder of this section shows how to configure a Postfix server to retrieve local aliases via LDAP queries. The following configuration file, main.cf, is the starting point for our discussion:
## /etc/postfix/main.cf
## Postfix configuration file for the plainjoe.org SMTP server.
## Written by
## Host/domain information
myhostname = garion.plainjoe.org
mydomain = plainjoe.org
myorigin = plainjoe.org
## Who is local?
mydestination = localhost $myhostname
## Who do we accept mail relaying from?
mynetworks = 192.168.1.0/24 127.0.0.0/8
## Program locations
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
queue_directory = /var/spool/postfix
mail_owner = postfix
## Sendmail-compatible mail spool directory
mail_spool_directory = /var/spool/mail
As before, an alias entry maps a local username to an email address; this address can be either another local user or a user on a remote system. In your LDAP schema, a local user is represented by the uid attribute of the posixAccount object class. The aliased entry is represented by the mail attribute of the inetOrgPerson object class. Note that you do not use the sendmailMTA and related schema objects presented in the previous section, but rely on the original object classes and attributes used by the mail clients presented in the first half of this chapter.
This schema does not address the case of mapping one local user to another for email delivery. Nor does it allow the use of external files to list the addresses that should be used as expansions for aliases; this feature is useful for supporting a local mailing list. This limitation is a result of the attributes chosen and not of Postfix's LDAP implementation.
Here's a typical LDIF entry for a user account that has an email alias. Mail for this account (a guest account) is forwarded to jerry@plainjoe.org:
## User account including a mail alias
dn: uid=guest1,ou=People,dc=plainjoe,dc=org
uid: guest1
cn: Guest Account
objectClass: posixAccount
objectClass: inetOrgPerson
userPassword: {CRYPT}Fd8nE1RtCh5G6
loginShell: /bin/bash
uidNumber: 783
gidNumber: 1000
homeDirectory: /home/guest1
gecos: Guest Account
sn: Account
mail: jerry@plainjoe.org
To inform the Postfix daemons that they should read the alias map from an LDAP directory, add the following entry to the server's main.cf :
alias_maps = ldap:ldapalias
The ldap keyword denotes the type of lookup table; the ldapalias string is the name of the table. This name is used as a prefix for parameter names; it identifies which settings are associated with this table.
After specifying that Postfix should look up alias information from the directory, you have to define several parameters that tell Postfix how to search the directory. These should be familiar by now. The most common settings include the LDAP server name (server_host), the search base (search_base), the search scope (scope), the search filter (query_filter), and the resulting attribute value to return (result_attribute). Each of these parameters is prefaced by the LDAP table name (ldapalias_). Add these definitions to main.cf:
## Parameters for LDAP alias map
ldapalias_server_host = localhost
ldapalias_search_base = ou=people,dc=plainjoe,dc=org
ldapalias_scope = sub
ldapalias_query_filter = (uid=%s)
ldapalias_result_attribute = mail
You can test the alias table lookup using the postmap(1) utility to verify that mail to the user guest1 will be forwarded to the mail account at jerry@plainjoe.org:
$ postmap -q guest1 ldap:ldapalias
jerry@plainjoe.org
After starting the Postfix daemons (/usr/sbin/postfix start), you can test your configuration further by sending a test message to guest1@garion. This slapd log entry (which comes from a logging level of 256) proves that Postfix did query the server using the filter "(uid=guest1)":
Aug 15 10:53:37 ldap slapd[6728]: conn=24 op=1 SRCH
base="ou=people,dc=plainjoe,dc=org" scope=2 filter="(uid=guest1)"
The following excerpt from the header of the deliv
ered message shows that the message was delivered to guest1@garion.plainjoe.org. However, the message was then forwarded to jerry@plainjoe.org, as specified by the value of the mail attribute for the guest1 account:
Return-Path:
Delivered-To: jerry@plainjoe.org
Received: from XXX.XXX.XXX.XXX ([ XXX.XXX.XXX.XXX ] helo=garion.plainjoe.org)
by gamma.jumpserver.net with esmtp (Exim 3.36 #1)
id 18M1Sc-0003tj-00
for jerry@plainjoe.org; Wed, 11 Dec 2002 01:39:14 -0600
Received: by garion.plainjoe.org (Postfix)
id 15CA23FB62; Tue, 10 Dec 2002 11:40:23 -0600 (CST)
Delivered-To: guest1@garion.plainjoe.org
Received: by garion.plainjoe.org (Postfix, from userid 0)
id F042E3FB69; Tue, 10 Dec 2002 12:40:22 -0500 (EST)
To: guest1@garion.plainjoe.org
Subject: testing Postfix/LDAP lookups
Message-Id: <20021210174022.F042E3FB69@garion.plainjoe.org>
Date: Tue, 10 Dec 2002 12:40:22 -0500 (EST)
From: root@plainjoe.org (root)
There are many possibilities beyond the simple example presented here. Your query_filter used only a single attribute, but nothing prevents the use of more complex filters that match on multiple attributes. Furthermore, many additional LDAP parameters allow you to fine-tune the way Postfix interacts with the directory. Table 7-7 gives a complete listing of all LDAP-related Postfix parameters as well as the default setting for each one.
Table 7-7. Postfix LDAP parameters
Parameter
Default
Description
bind
yes
Defines whether an LDAP bind request should be issued prior to performing the query. This value must be yes or no.
bind_dn
""
The DN used when binding to the LDAP directory.
bind_pw
""
The clear-text password used when binding to the directory using the bind_dn value.