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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- Returning Values from Bash Functions
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide