File _service:download_src_package:README-Postfix-SASL-RedHat.txt of Package postfix (Revision 8b14c598b5f24fab156bcffba25fee5c)
Currently displaying revision 8b14c598b5f24fab156bcffba25fee5c, show latest
1
Quick Start to Authenticate with SASL and PAM:
2
----------------------------------------------
3
4
If you don't need the details and are an experienced system
5
administrator you can just do this, otherwise read on.
6
7
1) Edit /etc/postfix/main.cf and set this:
8
9
smtpd_sasl_auth_enable = yes
10
smtpd_sasl_security_options = noanonymous
11
broken_sasl_auth_clients = yes
12
13
smtpd_recipient_restrictions =
14
permit_sasl_authenticated,
15
permit_mynetworks,
16
reject_unauth_destination
17
18
2) Turn on saslauthd:
19
20
/sbin/chkconfig --level 345 saslauthd on
21
/sbin/service saslauthd start
22
23
3) Edit /etc/sysconfig/saslauthd and set this:
24
25
MECH=pam
26
27
4) Restart Postfix:
28
29
/sbin/service postfix restart
30
31
A crash course in using SASL with Postfix:
32
------------------------------------------
33
34
Red Hat's Postfix RPMs include support for both SASL and TLS. SASL, the
35
Simple Authentication and Security Layer, allows Postfix to implement RFC
36
2554, which defines an extension to ESMTP, SMTP AUTH, which compliant
37
ESMTP clients can use to authenticate themselves to ESMTP servers.
38
Typically, this is used to allow roaming users to relay mail through a
39
server safely without configuring the SMTP server to be an open relay.
40
Inclusion of TLS support allows Postfix to implement RFC 2487, which
41
defines an extension to ESMTP, SMTP STARTTLS, which compliant ESMTP
42
clients and servers can use to encrypt the SMTP session. This is a
43
security enhancement -- normally SMTP is transmitted as cleartext over the
44
wire, making it vulnerable to both passive sniffing and active alteration
45
via monkey-in-the-middle attacks. In addition, STARTTLS can also be
46
used by either or both server and client to verify the identity of the
47
other end, making it useful for the same sorts of purposes as SMTP AUTH.
48
The two can even be combined. Typically, this is done by first starting
49
TLS, to encrypt the SMTP session, and then issuing the SMTP AUTH command,
50
to authenticate the client; this combination ensures that the username
51
and password transferred as part of the SMTP AUTH are protected by the
52
TLS encrypted session.
53
54
SMTP AUTH is implemented using SASL, an abstraction layer which can
55
authenticate against a variety of sources. On Red Hat, SASL can use
56
the /etc/shadow file, or it can use PAM libraries, or it can use its own
57
password database (/etc/sasldb), or it can do various more exotic things.
58
59
Authentication raises a number of security concerns for obvious
60
reasons. As a consequence authentication services on Red Hat systems
61
are restricted to processes running with root privileges. However for
62
security reasons it is also essential that a mail server such as
63
Postfix run without root privileges so that mail operations cannot
64
compromise the host system. This means that Postfix cannot directly
65
use authentication services because it does not execute with root
66
privileges. The answer to this this problem is to introduce an
67
intermediary process that runs with root privileges which Postfix can
68
communicate with and will perform authentication on behalf of
69
Postfix. The SASL package includes an authentication daemon called
70
saslauthd which provided this service, think of it as an
71
authentication proxy.
72
73
Using Saslauthd:
74
----------------
75
76
To use saslauthd there are several things you must assure are
77
configured.
78
79
Selecting an Authentication Method:
80
-----------------------------------
81
82
Recall that it is saslauthd which is authenticating, not
83
Postfix. To start with you must tell Postfix to use saslauthd, in
84
main.cf edit this configuration parameter:
85
86
smtpd_sasl_auth_enable = yes
87
88
It is also recommended that you disable anonymous logins otherwise
89
you've left your system open, so also add this configuration
90
parameter.
91
92
smtpd_sasl_security_options = noanonymous
93
94
Now you must tell saslauthd which authentication method to use. To
95
determine the authentication methods currently supported by saslauthd
96
invoke saslauthd with the -v parameter, it will print its version and
97
its list of methods and then exit, for example:
98
99
/usr/sbin/saslauthd -v
100
saslauthd 2.1.10
101
authentication mechanisms: getpwent kerberos5 pam rimap shadow
102
103
When saslauthd starts up it reads its configuration options from the
104
file /etc/sysconfig/saslauthd. Currently there are two parameters
105
which can be set in this file, MECH and FLAGS. MECH is the
106
authentication mechanism and FLAGS is any command line flags you may
107
wish to pass to saslauthd. To tell saslauthd to use a specific
108
mechanism edit /etc/sysconfig/saslauthd and set the MECH parameter,
109
for example to use PAM it would look like this:
110
111
MECH=pam
112
113
Of course you may use any of the other authentication mechanisms that
114
saslauthd reported it supports. PAM is an excellent choice as PAM
115
supports many of the same authentication methods that saslauthd does,
116
but by using PAM you will have centralized all of your authentication
117
configuration under PAM which is one of PAM's greatest assets.
118
119
How Postfix Interacts with SASL to Name its Authentication Services:
120
--------------------------------------------------------------------
121
122
It can be very helpful to understand how Postfix communicates with
123
SASL to name its authentication services. Knowing this will let you
124
identify the configuration files the various components will access.
125
126
When Postfix invokes SASL it must give SASL an application name that
127
SASL will use among other things to locate a configuration file for
128
the application. The application name Postfix identifies itself as is
129
"smtpd". SASL will append ".conf" to the application name and look for
130
a config file in its library and config directories. Thus SASL will
131
read Postfix's configuration from
132
133
/etc/sasl2/smtpd.conf
134
135
This file names the authentication method SASL will use for Postfix
136
(actually for smtpd, other MTA's such as sendmail may use the same
137
file). Because we want to use the saslauthd authentication proxy
138
daemon the contents of this file is:
139
140
pwcheck_method: saslauthd
141
142
This tells SASL when being invoked to authentication for Postfix that
143
it should use saslauthd. Saslauthd's mechanism is set in
144
/etc/sysconfig/saslauthd (see below).
145
146
When Postfix calls on SASL to authenticate it passes to SASL a service
147
name. This service name is used in authentication method specific
148
way. The service name Postfix passes to SASL is "smtp" (note this is
149
not the same as the application name which is "smtpd"). To understand
150
this better consider the case of using PAM authentication. When SASL,
151
or in our case saslauthd, invokes PAM it passes the service name of
152
"smtp" to PAM which means that when PAM wants to read configuration
153
information for this client it will find it under the name of "smtp".
154
155
Turning on the Authentication Daemon:
156
-------------------------------------
157
158
Red Hat security policy is not to automatically enable services
159
belonging to a package when the package is installed. The system
160
administrator must explicitly enable the service. To enable saslauthd
161
do the following:
162
163
1) Tell the init process to launch saslauthd when entering various run
164
levels. Assuming you want saslauthd to run at run levels 3,4,5
165
invoke chkconfig.
166
167
/sbin/chkconfig --level 345 saslauthd on
168
169
2) You will probably want to start saslauthd now without having to
170
reboot, to do this:
171
172
/sbin/service saslauthd start
173
174
Trouble Shooting Authentication:
175
--------------------------------
176
177
The best way to debug authentication problems is to examine log
178
messages from the authentication components. However, normally these
179
log messages are suppressed. There are two principle reasons the
180
messages are suppressed. The first is that they are typically logged
181
at the DEBUG logging priority level which is the lowest priority and
182
the syslog configuration typically logs only higher priority
183
messages. The second reason is that for security reasons authentication
184
logging is considered a risk. Authentication logging has been divided
185
into two different facilities, auth and authpriv. authpriv is private
186
and is typically shunted off to a different log file with higher
187
protection. You will want to be able to see both auth and authpriv
188
messages at all priorities. To do this as root edit /etc/syslog.conf
189
file, find the following line
190
191
authpriv.* /var/log/secure
192
193
edit the line to:
194
195
authpriv.*;auth.* /var/log/secure
196
197
Then restart syslogd so the syslog configuration changes will be
198
picked up:
199
200
/sbin/service syslog restart
201
202
Now all authentication messages at all priorities will log to
203
/var/log/secure.
204
205
Using PAM to Authenticate:
206
--------------------------
207
208
Edit /etc/sysconfig/saslauthd and set MECH to PAM like this:
209
210
MECH=pam
211
212
When PAM is invoked via SASL it is passed a service name of
213
"smtp". This means that PAM will read its configuration parameters for
214
Postfix from the file: /etc/pam.d/smtp. By default this file is set to
215
refer to the global system PAM authentication policy, thus by default
216
you'll get whatever PAM authentication your system is configured for
217
and virtually all applications use. Configuring PAM authentication is
218
beyond the scope of this document, please refer to the PAM
219
documentation if you which to modify PAM.
220
221
Trouble Shooting PAM Authentication:
222
------------------------------------
223
224
1) One possible reason PAM may fail to authenticate even if the user
225
is known to the system is if PAM fails to find the service
226
configuration file in /etc/pam.d. Service configuration files are not
227
required by PAM, if it does not find a service configuration file it
228
will default to "other". Since PAM does not consider the absence of a
229
service configuration file a problem it does not log anything nor does
230
it return an error to the calling application. In other words it is
231
completely silent about the fact it did not find a service
232
configuration file. On Red Hat system the default implementation of
233
"other" for PAM is to deny access. This means on Red Hat systems the
234
absence of a PAM service configuration file will mean PAM will
235
silently fail authentication. The PAM service configuration file for
236
postfix is /etc/pam.d/smtp and is intalled by the Red Hat Postfix rpm
237
and put under control of "alternatives" with name mta. Alternatives
238
allows one to select between the sendmail and postfix MTA's and
239
manages symbolic links for files the two MTA's share. /etc/pam.d/smtp
240
is one such file, if you have not selected Postfix as your prefered
241
MTA the link to this file will not be present. To select Postfix as
242
your MTA do this: "/usr/sbin/alternatives --config mta" and follow the
243
prompt to select postfix.
244
245
2) Is SASL appending a realm or domain to a username? PAM
246
authentication requires a bare username and password, other
247
authentication methods require the username to be qualified with a
248
realm. Typically the username will be rewritten as user@realm
249
(e.g. user@foo.com) PAM does not understand a username with
250
"@realm" appended to it and will fail the authentication with the
251
message that the user is unknown. If the log files shows saslauthd
252
usernames with "@realm" appended to it then the
253
smtpd_sasl_local_domain configuration parameter is likely set in
254
/etc/postfix/main.cf file, make sure its either not set or set it
255
to an empty string. Restart postfix and test authtentication again,
256
the log file should show only a bare username.
257
258
259
260
Using saslpasswd to Authenticate:
261
---------------------------------
262
263
SASL can maintain its own password database independent of the host
264
system's authentication setup, it is called saslpasswd. You may wish
265
to use saslpasswd if you want to isolate who can smtp authenticate
266
from general system users. However, it does add another password
267
database that a system administrator must maintain.
268
269
To authenticate against sasldb, you'll first have to create accounts.
270
These accounts are entirely separate from system accounts, and are used
271
only by connecting SMTP clients to authenticate themselves. Use the
272
saslpassword command:
273
274
saslpasswd -u `postconf -h myhostname` -c user
275
276
to create an account named user which can log into realm. For the
277
realm, make absolutely certain that you use the same value as is set for
278
myhostname in /etc/postfix/main.cf. If you don't, it likely won't work.
279
280
Also, be aware that saslpasswd is somewhat buggy. The first time you
281
run it, it may generate an error message while initializing the sasldb.
282
If it does, just add that user a second time.
283
284
You'll need to set permissions on the SASL password database so that
285
the Postfix daemons can read it:
286
287
chgrp postfix /etc/sasldb
288
chmod g+r /etc/sasldb
289
290
Now, you'll need to modify /etc/postfix/main.cf to tell it to
291
support SASL. The complete options you might want to use are in the
292
sample-auth.cf file in the Postfix documentation directory. An option
293
you will definitely need is:
294
295
# enable SASL support
296
smtpd_sasl_auth_enable = yes
297
298
You might also need to set the SASL authentication realm to whatever
299
realm you used when you created your sasldb; by default, this is set to
300
$myhostname, but you instead might need something like:
301
302
# set SASL realm to domain instead
303
smtpd_sasl_local_domain = $mydomain
304
305
Other Postfix Authentication Parameters:
306
----------------------------------------
307
308
If you want to allow your already configured users to still use your SMTP
309
server, and to allow users authenticated via SMTP AUTH to use your server
310
as well, then modify your existing smtpd_recipient_restrictions line to;
311
312
# also allow authenticated (RFC 2554) users
313
smtpd_recipient_restrictions = permit_sasl_authenticated ...
314
315
If you want to restrict use of your server to just authenticated clients
316
(Note: this is a bad idea for public mail servers), then instead use:
317
318
# restrict server access to authenticated (RFC 2554) clients
319
smtpd_delay_reject = yes
320
smtpd_client_restrictions = permit_sasl_authenticated ...
321
322
SASL supports several password types which have differing security
323
properties. Different SMTP clients may support some or all of these
324
password types. When the client issues an EHLO command, the server
325
tells it which types it supports:
326
327
$ telnet station6 25
328
Trying 10.100.0.6...
329
Connected to station6.example.com.
330
Escape character is '^]'.
331
220 station6.example.com ESMTP Postfix
332
ehlo station7
333
250-station6.example.com
334
250-PIPELINING
335
250-SIZE 10240000
336
250-VRFY
337
250-ETRN
338
250-STARTTLS
339
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
340
250-XVERP
341
250 8BITMIME
342
343
Here, the server supports PLAIN, LOGIN, DIGEST-MD5, and CRAM-MD5 password
344
methods.
345
346
The client then chooses the first of these listed methods which it also
347
supports, and issues an SMTP AUTH request.
348
349
For security, PLAIN and LOGIN methods are typically disabled. These two
350
methods use trivially decryptable encryption, making the username and
351
password issued by the client vulnerable to interception via a sniffer
352
in between the server and client. Unfortunately, they can't always
353
be disabled. Some popular SMTP clients, including MS Outlook 5.x,
354
only support PLAIN authentication, for example.
355
356
To limit the login methods offered by the server:
357
358
# disable unsafe password methods
359
smtpd_sasl_security_options = noplaintext noanonymous
360
361
Available options are:
362
363
noplaintext, which disables LOGIN and PLAIN
364
noanonymous, which disables disables ANON
365
nodictionary, which disables methods vulnerable to dictionary attacks
366
noactive, which disables methods vulnerable to active attacks
367
368
The last two are rarely used, since almost all supported methods are
369
vulnerable to those attacks ;-).
370
371
Also be aware that some broken clients mis-implement the SMTP AUTH
372
protocol, and send commands using incorrect syntax (AUTH=foo instead of
373
the correct AUTH foo). MS Outlook 4.x clients have this bug, among
374
a legion of others.... If you need to support these clients, use:
375
376
# support braindead MS products
377
broken_sasl_auth_clients = yes
378
379
To help prevent spoofing, you can also create a map file of SASL login
380
names which are allowed to use specific envelope sender (MAIL FROM)
381
addresses. If you choose to do this, you also have to tell Postfix to
382
reject addresses which don't match login names:
383
384
# prevent spoofing by authenticated users
385
reject_sender_login_mismatch
386
smtpd_sender_login_maps=type:/path/to/file
387
388
Configuration of SASL clients is much simpler. Postfix itself can be
389
made a SASL client; this is typically useful when roaming users run Linux
390
on their laptop and need to relay mail back through the organization's
391
main server.
392
393
To enable Postfix to act as an SMTP AUTH client, simply add to
394
/etc/postfix/main.cf:
395
396
# support authentication (RFC 2557) when relaying through a server
397
smtp_sasl_auth_enable = yes
398
399
and tell Postfix where to find the usernames and passwords it should
400
use to authenticate:
401
402
# location of passwords for authentication client
403
smtp_sasl_password_maps = type:/path/to/file
404
405
The file itself should have the format:
406
407
destination username:password
408
409
where destination is the name of the server, and username:password are
410
the username and password which should be presented to that server to
411
authenticate when connecting to it as a client.
412
413
Optionally, the authentication methods to be used can be specified for
414
the Postfix client, just as they can be for the Postfix server:
415
416
# disable plaintext and anonymous
417
smtp_sasl_security_options = noplaintext noanonymous
418
419
Many popular end-user MUAs can also be configured as SMTP AUTH clients.
420
Clients capable of this supplied with Red Hat include pine, Netscape,
421
and Mozilla.
422
423
Other Sources of Documentation:
424
-------------------------------
425
426
/usr/share/doc/postfix-<version>/README_FILES/SASL_README
427
428
Local configuration examples:
429
430
/usr/share/doc/postfix-*/samples
431
432
Postfix Howtos, Guides and Tips by Ralf Hildebrandt and Patrick
433
Koetter can be found at: http://postfix.state-of-mind.de
434
435
------------------------------------------------------------------------------
436
437
Please send any comments / corrections to Chris Ricker
438
<kaboom@gatech.edu>. This material can be freely modified and
439
redistributed. Additional material provided by John Dennis
440
<jdennis@redhat.com> and Dax Kelson <dax@gurulabs.com>.
441