pam_mapi (8) - Linux Manuals
pam_mapi: Module for authentication via MAPI against a Kopano or Zarafa server
NAMEpam_mapi - Module for authentication via MAPI against a Kopano or Zarafa server
SYNOPSISpam_mapi.so [socket=http://localhost:236/kopano] [socket=http://localhost:236/zarafa] [service=pop3|imap|mobile|outlook] [try_first_pass] [use_first_pass] [quiet] [debug]
The pam_mapi module is used to verify a username/password pair via MAPI in SOAP against a Kopano server of Kopano Core and a Zarafa server of the Zarafa Collaboration Platform, respectively.
Use the socket http://localhost:236/kopano for the Kopano login or http://localhost:236/zarafa for the Zarafa login. This also can be HTTPS if the Kopano or Zarafa server is not running on the same machine. The default socket http://localhost:236/kopano or http://localhost:236/zarafa is used, if none has been set.
Be very careful when specifying the UNIX socket here, because the default Kopano or Zarafa configuration option local_admin_users in /etc/kopano/server.cfg or /etc/zarafa/server.cfg contains the root user and saslauthd runs as root user by default, too. In this case, any authentication would succeed, even if wrong credentials are provided, which could make the SMTP service an open relay.
Try authentication by using the given service/feature. Since Kopano 8.0.0 and Zarafa 7.0.0 some features can be enabled and disabled on a per-user basis. If e.g. IMAP is disabled for a specific user any IMAP login will fail. Using this option the same behaviour can be applied to pam_mapi for e.g. SMTP authentication.
Valid values are values from option disabled_features in /etc/kopano/server.cfg or /etc/zarafa/server.cfg. Multiple services can be listed using a pipe character and behave like a digital logic OR gate. So service=pop3|imap will permit authentication if either the feature POP3 or IMAP has been enabled for this user.
- Use the authentication token previously obtained by another module that did the conversation with the application. If this token can not be obtained then the module will try to converse. This option can be used for stacking different modules that need to deal with the authentication tokens.
- Use the authentication token previously obtained by another module that did the conversation with the application. If this token can not be obtained then the module will fail. This option can be used for stacking different modules that need to deal with the authentication tokens.
- Do not treat MAPI_E_LOGON_FAILED authentication failures as errors that need to be logged to syslog(3). This option can be used for stacking different modules, because the existence of an account can be only assured after a succeeded authentication due to limited PAM account functionality.
- Turns on debugging via syslog(3).
Invalid arguments are logged with syslog(3).
MODULE TYPES PROVIDED
The auth and account module types are provided.
- Authentication service cannot retrieve authentication info.
- Authentication token manipulation error.
- Authentication information cannot be recovered.
- Authentication failure.
- Ignore this module.
- Error in service module.
The most typical usage in /etc/pam.d/smtp when authenticating only against Kopano or Zarafa users would be:
#%PAM-1.0 auth required pam_mapi.so try_first_pass account required pam_mapi.so
Since Kopano 8.0.0 and Zarafa 7.0.0 some features can be enabled and disabled on per-user basis. Previous configuration would pass authentication even if e.g. IMAP is disabled for a specific user. By adding the service option one of the given features has to be enabled to pass authentication:
#%PAM-1.0 auth required pam_mapi.so try_first_pass service=imap account required pam_mapi.so
Another common usage in /etc/pam.d/smtp could be authenticating against Linux system and Kopano/Zarafa users. However this configuration depends heavily on the used Linux distribution. Fortunately in many cases the following two lines simply have to be added (before the existing lines):
auth sufficient pam_mapi.so try_first_pass quiet account sufficient pam_mapi.so
On Red Hat Enterprise Linux 5 (and derivates such as CentOS) the authentication against Linux system and Kopano/Zarafa users looks like this:
#%PAM-1.0 auth sufficient pam_mapi.so try_first_pass quiet auth include system-auth account sufficient pam_mapi.so account include system-auth
The same configuration for Red Hat Enterprise Linux 6 and 7 (including CentOS):
#%PAM-1.0 auth sufficient pam_mapi.so try_first_pass quiet auth include password-auth account sufficient pam_mapi.so account include password-auth
Keep in mind while editing, that /etc/pam.d/smtp could be a symbolic link at various Linux systems.
pam_mapi was written by Robert Scheck <kopano [at] robert-scheck.de>.
pam.conf(5), pam.d(5), pam(8), kopano-server.cfg(5), kopano-server(1), zarafa-server.cfg(5), zarafa-server(1), saslauthd(8)