1SASLAUTHD(8) BSD System Manager's Manual SASLAUTHD(8)
2
4 saslauthd — sasl authentication server
5
7 saslauthd -a authmech [-Tvdchlr] [-O option] [-m mux_path] [-n threads]
8 [-s size] [-t timeout]
9
11 saslauthd is a daemon process that handles plaintext authentication
12 requests on behalf of the SASL library.
13 The server fulfills two roles: it isolates all code requiring superuser
15 privileges into a single process, and it can be used to provide proxy
16 authentication services to clients that do not understand SASL based
17 authentication.
18 saslauthd should be started from the system boot scripts when going to
20 multi-user mode. When running against a protected authentication database
21 (e.g. the shadow mechanism), it must be run as the superuser. Otherwise
22 it is recommended to run daemon unprivileged as saslauth:saslauth,
23 requiring the runtime directory to have root:saslauthd owner. You can do
24 so by following these steps in machines using systemd(1) :
25 1. create directory /etc/systemd/system/saslauthd.service.d/
27 2. create file /etc/systemd/system/saslauthd.service.d/user.conf with
28 content
29 [Service]
31 User=saslauth
32 Group=saslauth
33 3. Reload systemd service file: run “systemctl daemon-reload”
35 Options
37 Options named by lower-case letters configure the server itself.
38 Upper-case options control the behavior of specific authentication mecha‐
39 nisms; their applicability to a particular authentication mechanism is
40 described in the AUTHENTICATION MECHANISMS section.
41 -a authmech
43 Use authmech as the authentication mechanism. (See the
44 AUTHENTICATION MECHANISMS section below.) This parameter is
45 mandatory.
46 -O option
48 A mechanism specific option (e.g. rimap hostname or config file
49 path)
50 -H hostname
52 The remote host to be contacted by the rimap authentication mech‐
53 anism. (Deprecated, use -O instead)
54 -m path
56 Use path as the pathname to the named socket to listen on for
57 connection requests. This must be an absolute pathname, and MUST
58 NOT include the trailing "/mux". Note that the default for this
59 value is "/var/state/saslauthd" (or what was specified at compile
60 time) and that this directory must exist for saslauthd to func‐
61 tion.
62 -n threads
64 Use threads processes for responding to authentication queries.
65 (default: 5) A value of zero will indicate that saslauthd should
66 fork an individual process for each connection. This can solve
67 leaks that occur in some deployments.
68 -s size
70 Use size as the table size of the hash table (in kilobytes)
71 -t timeout
73 Use timeout as the expiration time of the authentication cache
74 (in seconds)
75 -T Honour time-of-day login restrictions.
77 -h Show usage information
79 -c Enable caching of authentication credentials
81 -l Disable the use of a lock file for controlling access to
83 accept().
84 -r Combine the realm with the login (with an '@' sign in between).
86 e.g. login: "foo" realm: "bar" will get passed as login:
87 "foo@bar". Note that the realm will still be passed, which may
88 lead to unexpected behavior for authentication mechanisms that
89 make use of the realm, however for mechanisms which don't, such
90 as getpwent, this is the only way to authenticate domain-specific
91 users sharing the same userid.
92 -v Print the version number and available authentication mechanisms
94 on standard error, then exit.
95 -d Debugging mode.
97 Logging
99 saslauthd logs its activities via syslogd using the LOG_AUTH facility.
100
102 saslauthd supports one or more "authentication mechanisms", dependent
103 upon the facilities provided by the underlying operating system. The
104 mechanism is selected by the -a flag from the following list of choices:
105 dce (AIX)
107 Authenticate using the DCE authentication environment.
109 getpwent (All platforms)
111 Authenticate using the getpwent() library function. Typically
113 this authenticates against the local password file. See your
114 system's getpwent(3) man page for details.
115 kerberos4 (All platforms)
117 Authenticate against the local Kerberos 4 realm. (See the
119 NOTES section for caveats about this driver.)
120 kerberos5 (All platforms)
122 Authenticate against the local Kerberos 5 realm.
124 pam (Linux, Solaris)
126 Authenticate using Pluggable Authentication Modules (PAM).
128 rimap (All platforms)
130 Forward authentication requests to a remote IMAP server. This
132 driver connects to a remote IMAP server, specified using the
133 -O flag, and attempts to login (via an IMAP ‘LOGIN’ command)
134 using the credentials supplied to the local server. If the
135 remote authentication succeeds the local connection is also
136 considered to be authenticated. The remote connection is
137 closed as soon as the tagged response from the ‘LOGIN’ command
138 is received from the remote server.
139 The option parameter to the -O flag describes the remote
141 server to forward authentication requests to. hostname can be
142 a hostname (imap.example.com) or a dotted-quad IP address
143 (192.168.0.1). The latter is useful if the remote server is
144 multi-homed and has network interfaces that are unreachable
145 from the local IMAP server. The remote host is contacted on
146 the ‘imap’ service port. A non-default port can be specified
147 by appending a slash and the port name or number to the
148 hostname argument.
149 The -O flag and argument are mandatory when using the rimap
151 mechanism.
152 shadow (AIX, Irix, Linux, Solaris)
154 Authenticate against the local "shadow password file". The
156 exact mechanism is system dependent. saslauthd currently
157 understands the getspnam() and getuserpw() library routines.
158 Some systems honour the -T flag.
159 sasldb (All platforms)
161 Authenticate against the SASL authentication database. Note
163 that this is probably not what you want to use, and is even
164 disabled at compile-time by default. If you want to use
165 sasldb with the SASL library, you probably want to use the
166 pwcheck_method of "auxprop" along with the sasldb auxprop
167 plugin instead.
168 ldap (All platforms that support OpenLDAP 2.0 or higher)
170 Authenticate against an ldap server. The ldap configuration
172 parameters are read from /etc/saslauthd.conf. The location of
173 this file can be changed with the -O parameter. See the
174 LDAP_SASLAUTHD file included with the distribution for the
175 list of available parameters.
176 sia (Digital UNIX)
178 Authenticate using the Digital UNIX Security Integration
180 Architecture (a.k.a. "enhanced security").
181
183 The kerberos4 authentication driver consumes considerable resources. To
184 perform an authentication it must obtain a ticket granting ticket from
185 the TGT server on every authentication request. The Kerberos library rou‐
186 tines that obtain the TGT also create a local ticket file, on the reason‐
187 able assumption that you will want to save the TGT for use by other Ker‐
188 beros applications. These ticket files are unusable by saslauthd , how‐
189 ever there is no way not to create them. The overhead of creating and
190 removing these ticket files can cause serious performance degradation on
191 busy servers. (Kerberos was never intended to be used in this manner,
192 anyway.)
193
195 /run/saslauthd/mux The default communications socket.
196 /etc/saslauthd.conf
198 The default configuration file for ldap support.
199
201 passwd(1), getpwent(3), getspnam(3), getuserpw(3), sasl_checkpass(3)
202 sia_authenticate_user(3),
203CMU-SASL 12 12 2005 CMU-SASL