Paranoid Penguin - Single Sign-on and the Corporate Directory, Part I
We'll be using the Postfix mail transport agent (MTA) v2.1.5. Postfix has well-established support for SASL authentication as well as LDAP support for features such as aliases. Because configuring Postfix from the ground up is beyond the scope of this article, we deal with how to enable Postfix to use SASL and TLS. For information on setting up Postfix, see Resources.
Postfix has two main configuration files, /etc/postfix/main.cf and /etc/postfix/master.cf. The main.cf file is primarily responsible for how to accept incoming mail, and master.cf is primarily responsible for defining mail delivery agents.
An example main.cf is included in the on-line Resources, but to understand the directives in this file fully, you should refer to the Postfix documentation and Web site.
Three main directives define how our SMTP server interacts with other SMTP servers: smtp_sasl_auth_enable, smtp_use_tls and smtp_tls_note_starttls. If your SMTP server will be exposed to the Internet at large, you should set these as flexibly as possible to ensure all other SMTP servers can talk to yours. If it's an internal-only SMTP server, however, you can make it more secure by strengthening these directives.
The more interesting part is how we specify how our users and machines connect to our MTA to send mail. A few more directives are of concern here: smtpd_sasl_auth_enable, smtpd_sasl_security_options, smtpd_sasl_tls_security_options, smtpd_use_tls, smtpd_tls_cert_file, smtpd_tls_key_file and smtpd_tls_auth_only.
If you'll be using IMAP for mail delivery, make sure to set the mailbox_transport directive and the smtp and cyrus transports mechanism in master.cf.
Like OpenLDAP, Postfix is kerberized, uses SASL for authentication negotiation and can use SSL to secure the data transport. To secure Postfix and configure it to use SASL, we need to do a few tasks in addition to modifying main.cf. First we create an SSL certificate/key pair and place the two parts in /etc/ssl/postfix/smtp-cert.pem and /etc/ssl/postfix/smtp-key.pem, making sure that they're owned by the user postfix and group mail, and that the key is readable only by user postfix. Next, we create a host principal for mail.example.com and save it to the normal place. We also create a service principal, smtp/mail.example.com@CI.EXAMPLE.COM and save it to /etc/postfix/smtp.keytab. This file should be owned by root and have the same permissions as the smtp-key.pem file. In addition, we create a SASL configuration file named /etc/sasl2/smtpd.conf and also edit /etc/conf.d/saslauthd. Postfix uses the saslauthd dæmon to get information about authentication mechanisms, and these two files tell SASL how to check passwords, what mechanisms are supported and the minimum security layer to use. Values for minimum_layer are equivalent to the security strength factors (SSFs) in OpenLDAP. Finally, we tell Postfix where its Kerberos keytab file is by creating /etc/conf.d/postfix or by making sure the KRB5_KTNAME environment variable is set in the init script prior to starting Postfix. Once all these tasks have been done, we can start the saslauthd and Postfix init scripts.
LDAP is useful not only for identity management and authorization but also for storing alias maps for Postfix. It's simple to use and maintain, and it removes the need to rebuild the alias database every time there is a change to it. The first step is to make our directory aware that we want to store alias maps in it. We do this by adding the misc.schema to the slapd configuration. Next, we create a branch in the directory for the aliases. We'll use ou=aliases,o=ci,dc=example,dc=com. The last piece is to tell Postfix to use LDAP as a source for aliases by adding ldap:/etc/postfix/aliases.cf to the alias_maps directive in main.cf and creating the /etc/postfix/aliases.cf file that specifies how to connect to LDAP and where the aliases are in LDAP. We restart slapd and then Postfix; we're now ready to add a mail alias. We create an LDIF file called alias.ldif and add it to the directory. That's it!
We'll be using the cyrus IMAP mail delivery agent (MDA) v2.2.10. Complete configuration of the cyrus IMAP server is beyond the scope of this document, but example working configuration files are provided. The cyrus IMAP server is developed by the same group who developed cyrus SASL, so SASL and single sign-on support work as expected.
Like Postfix, cyrus IMAP has two configuration files: /etc/imapd.conf and /etc/cyrus.conf. We'll be dealing only with /etc/imapd.conf. Again there are a few prerequisites: SSL certificate/key pair, host principal and service principal. The service principal should be called imap/mail.example.com@CI.UCHICAGO.EDU and stored in /etc/imap.keytab. To enable SSL, we define tls_ca_path, tls_cert_file and tls_key_file options accordingly. To use SASL, we define sasl_pwcheck_method, sasl_mech_list and sasl_minimum_layer options. The values for these options are identical to those set in /etc/sasl2/smtpd.conf for Postfix. Like Postfix, cyrus IMAP needs to be told where its keytab file is. We do this by editing /etc/conf.d/cyrus or making sure the KRB5_KTNAME environment variable is set in the init script prior to starting the IMAP dæmon. Once all this has been done, we should make sure saslauthd is running and then start the imap init script.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
- Picking Out the Nouns
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- DevOps: Better Than the Sum of Its Parts
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Non-Linux FOSS: .NET?
- Consent That Goes Both Ways