| @@ -0,0 +1,440 @@
+Quick Start to Authenticate with SASL and PAM:
+----------------------------------------------
+
+If you don't need the details and are an experienced system
+administrator you can just do this, otherwise read on.
+
+1) Edit /etc/postfix/main.cf and set this:
+
+smtpd_sasl_auth_enable = yes
+smtpd_sasl_security_options = noanonymous
+broken_sasl_auth_clients = yes
+
+smtpd_recipient_restrictions =
+ permit_sasl_authenticated,
+ permit_mynetworks,
+ reject_unauth_destination
+
+2) Turn on saslauthd:
+
+ /sbin/chkconfig --level 345 saslauthd on
+ /sbin/service saslauthd start
+
+3) Edit /etc/sysconfig/saslauthd and set this:
+
+ MECH=pam
+
+4) Restart Postfix:
+
+ /sbin/service postfix restart
+
+A crash course in using SASL with Postfix:
+------------------------------------------
+
+Red Hat's Postfix RPMs include support for both SASL and TLS. SASL, the
+Simple Authentication and Security Layer, allows Postfix to implement RFC
+2554, which defines an extension to ESMTP, SMTP AUTH, which compliant
+ESMTP clients can use to authenticate themselves to ESMTP servers.
+Typically, this is used to allow roaming users to relay mail through a
+server safely without configuring the SMTP server to be an open relay.
+Inclusion of TLS support allows Postfix to implement RFC 2487, which
+defines an extension to ESMTP, SMTP STARTTLS, which compliant ESMTP
+clients and servers can use to encrypt the SMTP session. This is a
+security enhancement -- normally SMTP is transmitted as cleartext over the
+wire, making it vulnerable to both passive sniffing and active alteration
+via monkey-in-the-middle attacks. In addition, STARTTLS can also be
+used by either or both server and client to verify the identity of the
+other end, making it useful for the same sorts of purposes as SMTP AUTH.
+The two can even be combined. Typically, this is done by first starting
+TLS, to encrypt the SMTP session, and then issuing the SMTP AUTH command,
+to authenticate the client; this combination ensures that the username
+and password transferred as part of the SMTP AUTH are protected by the
+TLS encrypted session.
+
+SMTP AUTH is implemented using SASL, an abstraction layer which can
+authenticate against a variety of sources. On Red Hat, SASL can use
+the /etc/shadow file, or it can use PAM libraries, or it can use its own
+password database (/etc/sasldb), or it can do various more exotic things.
+
+Authentication raises a number of security concerns for obvious
+reasons. As a consequence authentication services on Red Hat systems
+are restricted to processes running with root privileges. However for
+security reasons it is also essential that a mail server such as
+Postfix run without root privileges so that mail operations cannot
+compromise the host system. This means that Postfix cannot directly
+use authentication services because it does not execute with root
+privileges. The answer to this this problem is to introduce an
+intermediary process that runs with root privileges which Postfix can
+communicate with and will perform authentication on behalf of
+Postfix. The SASL package includes an authentication daemon called
+saslauthd which provided this service, think of it as an
+authentication proxy.
+
+Using Saslauthd:
+----------------
+
+To use saslauthd there are several things you must assure are
+configured.
+
+Selecting an Authentication Method:
+-----------------------------------
+
+Recall that it is saslauthd which is authenticating, not
+Postfix. To start with you must tell Postfix to use saslauthd, in
+main.cf edit this configuration parameter:
+
+ smtpd_sasl_auth_enable = yes
+
+It is also recommended that you disable anonymous logins otherwise
+you've left your system open, so also add this configuration
+parameter.
+
+ smtpd_sasl_security_options = noanonymous
+
+Now you must tell saslauthd which authentication method to use. To
+determine the authentication methods currently supported by saslauthd
+invoke saslauthd with the -v parameter, it will print its version and
+its list of methods and then exit, for example:
+
+ /usr/sbin/saslauthd -v
+ saslauthd 2.1.10
+ authentication mechanisms: getpwent kerberos5 pam rimap shadow
+
+When saslauthd starts up it reads its configuration options from the
+file /etc/sysconfig/saslauthd. Currently there are two parameters
+which can be set in this file, MECH and FLAGS. MECH is the
+authentication mechanism and FLAGS is any command line flags you may
+wish to pass to saslauthd. To tell saslauthd to use a specific
+mechanism edit /etc/sysconfig/saslauthd and set the MECH parameter,
+for example to use PAM it would look like this:
+
+ MECH=pam
+
+Of course you may use any of the other authentication mechanisms that
+saslauthd reported it supports. PAM is an excellent choice as PAM
+supports many of the same authentication methods that saslauthd does,
+but by using PAM you will have centralized all of your authentication
+configuration under PAM which is one of PAM's greatest assets.
+
+How Postfix Interacts with SASL to Name its Authentication Services:
+--------------------------------------------------------------------
+
+It can be very helpful to understand how Postfix communicates with
+SASL to name its authentication services. Knowing this will let you
+identify the configuration files the various components will access.
+
+When Postfix invokes SASL it must give SASL an application name that
+SASL will use among other things to locate a configuration file for
+the application. The application name Postfix identifies itself as is
+"smtpd". SASL will append ".conf" to the application name and look for
+a config file in its library and config directories. Thus SASL will
+read Postfix's configuration from
+
+ /etc/sasl2/smtpd.conf
+
+This file names the authentication method SASL will use for Postfix
+(actually for smtpd, other MTA's such as sendmail may use the same
+file). Because we want to use the saslauthd authentication proxy
+daemon the contents of this file is:
+
+ pwcheck_method: saslauthd
+
+This tells SASL when being invoked to authentication for Postfix that
+it should use saslauthd. Saslauthd's mechanism is set in
+/etc/sysconfig/saslauthd (see below).
+
+When Postfix calls on SASL to authenticate it passes to SASL a service
+name. This service name is used in authentication method specific
+way. The service name Postfix passes to SASL is "smtp" (note this is
+not the same as the application name which is "smtpd"). To understand
+this better consider the case of using PAM authentication. When SASL,
+or in our case saslauthd, invokes PAM it passes the service name of
+"smtp" to PAM which means that when PAM wants to read configuration
+information for this client it will find it under the name of "smtp".
+
+Turning on the Authentication Daemon:
+-------------------------------------
+
+Red Hat security policy is not to automatically enable services
+belonging to a package when the package is installed. The system
+administrator must explicitly enable the service. To enable saslauthd
+do the following:
+
+1) Tell the init process to launch saslauthd when entering various run
+ levels. Assuming you want saslauthd to run at run levels 3,4,5
+ invoke chkconfig.
+
+ /sbin/chkconfig --level 345 saslauthd on
+
+2) You will probably want to start saslauthd now without having to
+ reboot, to do this:
+
+ /sbin/service saslauthd start
+
+Trouble Shooting Authentication:
+--------------------------------
+
+The best way to debug authentication problems is to examine log
+messages from the authentication components. However, normally these
+log messages are suppressed. There are two principle reasons the
+messages are suppressed. The first is that they are typically logged
+at the DEBUG logging priority level which is the lowest priority and
+the syslog configuration typically logs only higher priority
+messages. The second reason is that for security reasons authentication
+logging is considered a risk. Authentication logging has been divided
+into two different facilities, auth and authpriv. authpriv is private
+and is typically shunted off to a different log file with higher
+protection. You will want to be able to see both auth and authpriv
+messages at all priorities. To do this as root edit /etc/syslog.conf
+file, find the following line
+
+authpriv.* /var/log/secure
+
+edit the line to:
+
+authpriv.*;auth.* /var/log/secure
+
+Then restart syslogd so the syslog configuration changes will be
+picked up:
+
|
