Mail Applications
Cyrus SASL
Sun supply an implementation of SASL however, our choice of Cyrus' imapd means we need to build an instance of SASL2.
SASL is no doubt a worthy layer of uniformity atop the various authentication mechanisms that are available to the application. That doesn't make it easy to understand nor does it mean that the supplied documentation is informative enough. We shall bodge together a solution.
Berkeley DB
Before we start we have to be careful as to whether we're going to be using Berkeley DB. If we use Berkeley DB in imapd then we must use Berkeley DB here as well. The reason is that SASL will be used to create the user database. If you don't say anything it'll create it using ndbm. If you compile Berkeley DB into imapd then then it''ll assume the user database is created using it and won't tell you until it (silently) SEGV's. Very tiresome.
Oh, yes, and SASL seems to be OK with Berkeley DB 4.1 and not OK with Berkeley DB 4.6.21.
Building and Installing
First, we'll build SASL2:
cd .../cyrus-sasl-2.1.21
LDFLAGS="-L/usr/sfw/lib -R/usr/sfw/lib" ./configure --prefix=/usr/local/${PWD##*/} --with-openssl=/usr/sfw
make
or, with your Berkeley DB:
B=/usr/local/db-4.1.25
LDFLAGS="-L/usr/sfw/lib -R/usr/sfw/lib -L$B/lib -R$B/lib" ./configure --prefix=/usr/local/${PWD##*/} --with-openssl=/usr/sfw
Note
If the build fails with references to /usr/include/crypt.h try:
vi +/HAVE_CRYPT_H saslauthd/auth_getpwent.c [ change the value of the ifdef to fail eg. s/$/_/ ]
Warning
Two libraries fail to ld -R/usr/sfw/lib which appears to be a bug in libtool. This doesn't prevent SASL2 from compiling and installing successfully. It does prevent subsequent applications from running.
You can determine which ones by running the following command:
for x in plugins/.libs/*.so ; do ldd $x | grep not && echo $x ; done
But don't worry if the missing libraries are libcrypto_extra.so.0.9.8 (or similar). The crypto extra libraries are not required (and are a separate download).
To fix things you'll need to do the following (change the libraries as the previous command suggests):
rm plugins/libdigestmd5.la plugins/libotp.la LD_RUN_PATH=/usr/sfw/lib make
and similarly for Berkeley DB:
rm plugins/.libs/libsasldb.so LD_RUN_PATH=$B/lib make
Finally we can install:
make install
Although that doesn't complete the installation. The SASL2 libraries look in a well known place for their per-mechanisn libraries. That well known place is /usr/lib/sasl2 on Solaris and so we need to make that path a link to where we've just installed SASL2:
su
[ -f /usr/lib/sasl2 ] && mv /usr/lib/sasl2 /usr/lib/sasl2.$(date +%Y%m%d%H%M%S)
ln -s /usr/local/${PWD##*/}/lib/sasl2 /usr/lib/sasl2
Cyrus IMAPd 2.3.x
Cyrus IMAPd 2.3.x causes a function name conflict in plugins/opt.c. Both imapd.c and opt.c define a function hex2bin with unfortunate consequences. The opt.c function is only used if OPIE is not available (true by default on Solaris systems). The fix is to make the otp.c version a function local to the function (grep for hex2bin to see which sed line is appropriate):
cp plugins/otp.c plugins/otp.c.orig sed -e 's/^hex2bin/static hex2bin/' plugins/otp.c.orig > plugins/otp.c sed -e 's/^int hex2bin/static int hex2bin/' plugins/otp.c.orig > plugins/otp.c
Running saslpasswd2 and sasldblistusers2 will be fine but when you kick off cyrus and try using cyradm you'll get an obscure message and the logs will report imapd getting a SEGV.
Configuring
Create the sasldb2 tables
Note
The tables need to be group write accessible for postfix so that smtpd can write OTP secrets.
touch /etc/sasldb2.{dir,pag}
chown cyrus:postfix /etc/sasldb2.{dir,pag}
chmod 660 /etc/sasldb2.{dir,pag}
If you're using Berkeley DB:
touch /etc/sasldb2 chown cyrus:postfix /etc/sasldb2 chmod 660 /etc/sasldb2
Create the admin account
Create the Cyrus admin account (which you'll use with cyradm later) but without a domain. For historical reasons the admin account is named cyrus.
Note
Without -u'' the account will be created in the domain $(uname -n)
/usr/local/${PWD##*/}/sbin/saslpasswd2 -c -u '' cyrus
Note
If you run sasldblistusers2 the account will be shown in the domain $(uname -n) but you don't log in as cyrus@$(uname -n) just cyrus
Warning
If you subsequently lift'n'shift your mail service to a new box (with a new $(uname -n)) then the implied hostname comes back to haunt you.
The /etc/sasldb2.{pag,dir} entries really do have $(uname -n) embedded in them and now it matters. You can log in as, say, cyrus@old-hostname using the original password but you have then authenticated with a different token and so you can't see/do anything.
You must create a new cyrus account (and all other accounts for your default domain) with the implied $(uname -n).
Other
We don't need to do anything with saslauthd or anything else. As we are creating IMAP accounts that are user@domain then we can't look them up in any normal authentication mechanism (notably passwd via PAM) as there are no such user accounts (the closest you would get would be user but not user@domain).
Document Actions