Paranoid Penguin - Secure Mail with LDAP and IMAP, Part II
In the first part of this series on using LDAP with the Cyrus IMAP mail delivery server (LJ, November 2003), we got as far as installing and setting up Cyrus IMAP and Cyrus SASL. In this article, we add some users to Cyrus IMAP and configure Postfix to deliver mail to the Cyrus IMAP server.
Before we dive back in to Cyrus IMAP configuration and administration, a note about documentation. Cyrus IMAP comes with an administrator's manual in HTML format. In the SuSE distribution, the manual is in /usr/share/doc/packages/cyrus-imapd/doc, and in Simon Matter's Red Hat SRPM distribution (see Part I of this article) it's in /usr/share/doc/cyrus-imapd-2.1.12. The link misleadingly labeled Installation actually leads not only to Cyrus installation instructions but to configuration and administration instructions as well. Besides this documentation, several man pages also are included with Cyrus IMAP, most notably imapd.conf(5), imapd(8) and cyradm(1).
In addition to Cyrus IMAP's included documentation, I recommend the book Managing IMAP by Dianna and Kevin Mullet (O'Reilly & Associates, 2000). As far as I know, it's the only book dedicated to IMAP. Although its coverage of Cyrus IMAP doesn't extend to LDAP, it's a well-written book that clearly explains IMAP concepts and Cyrus IMAP administration; it also covers UW-IMAP in some detail.
Cyrus IMAP comes with a Perl script, cyradmn, that provides the most convenient way to create and manage user mailboxes. You should understand several things before using cyradm. First, you should run cyradm from any account with which you also read e-mail. In other words, you never should use an IMAP administrative account as an e-mail account. Due to unusual write-access permissions, using such accounts to read or send e-mail can have strange negative effects on your server. As we learned last time, Cyrus administrative accounts are named according to the variable admins in /etc/imapd.conf.
Second, cyradm uses the same authentication method as does the rest of Cyrus IMAP. In my previous column, we determined this by setting /etc/imapd.conf's variable sasl_pwcheck_method to saslauthd and by editing /etc/sysconfig/saslauthd to use either LDAP or, in the case of SuSE, to use PAM. PAM itself can be configured to use LDAP for IMAP transactions in the files /etc/pam.d/imap and /etc/openldap/ldap.conf. In short, cyradm identifies and authenticates administrative users with LDAP, assuming you've correctly configured LDAP support in Cyrus IMAP, as described last time.
Finally, to authenticate, cyradm performs an LDAP auth lookup against your user name and password, using the LDAP attribute UID as the search criterion. For each user account you want to allow to run cyradm, therefore, the LDAP record needs to contain definitions for both UID and userPassword. UID is a required attribute and userPassword is an allowed attribute in the posixAccount Object Class, so all IMAP user accounts need to be associated with posixAccount.
This last point has another important ramification: in your OpenLDAP server's /etc/openldap/slapd.conf file, you need to have access control list (ACL) statements granting auth access to the userPassword attribute for whatever LDAP user your IMAP server (or its saslauthd process) uses to bind to the LDAP server (that is, to perform authentications). LDAP ACL statements are described in the slapd.conf(5) man page and in my article “Authenticate with LDAP, Part III” (LJ, September 2003).
cyradm usually is run as an administrative shell rather than as a command, per se. When you invoke cyradm, supplying your user name plus the host you wish to administer, it prompts you for a password. On successful authentication, it begins an interactive session with its own commands and help screen. cyradm also can be run non-interactively; see the cyradm(1) man page for information on using cyradm for scripting.
The simplest invocation of cyradm is:
bash-$> cyradm --user username hostname
If you're running cyradm on the same host on which Cyrus IMAP is running, you can use the hostname localhost. If the server you want to administer is a remote host, however, specify its hostname or IP address. By default, cyradm attempts to connect to it over TCP port 143. Because Cyrus IMAP uses this port for clear-text communication, use the --port option to specify TCP port 993 for TLS-encrypted communications instead, like this: --port 993. Personally, in such situations I find it simplest to connect to my remote IMAP servers with SSH and then run cyradm locally on the remote host using my SSH session.
Suppose I want to run cyradm locally on my IMAP server and my admin account is called mick_admin. The command would look like this:
bash-$ cyradm -u mick_admin localhost IMAP Password: ********** localhost>
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?