If you installed the RPMS you might not have been through this yet. By default Cyrus-SASL's configuration file needs to be put in /usr/lib/sasl. There can be several configuration files, each named after the application that wants Cyrus-SASL to authenticate users.
In our case it is Postfix' smtpd seeking assistance; therefore the file must be named /usr/lib/sasl/smtpd.conf.
This file holds the parameter that tells Cyrus-SASL which method of authentication we want it to use: saslauthd or sasldb.
So there's only one thing that's needs to be done: Replace the value saslauthd with sasldb.
[firstname.lastname@example.org]# vi /usr/lib/sasl/smtpd.conf
After the edit our smtpd.conf looks like that:
This has changed in Cyrus-SASL-2.x! To use sasldb2 you must set the following in /usr/lib/sasl2/smtpd.conf:
Why should we disable the saslauthd daemon. First of all we don't need it, when we use method sasldb, secondly we are kind of greedy and don't want unused daemons wasting CPU-time and MEM and last and most important in our context: Only when we do not run saslauthd and succeed in authentication we really can tell the sasldb method did the job.
If you start|stop the saslauthd from an INIT script, as the RPM-Version does, all you need to do is call the INIT script and order it to stop the saslauthd. If you use a different method you will hopefully know how to stop the daemon by yourself.
[email@example.com]# /etc/init.d/saslauthd stop Shutting down saslauthd: [ OK ]
If you plan to use sasldb instead of saslauthd on your system then you should make sure the daemon will not get started automatically when you system enters the different runlevels or when you reboot. So you either disable the daemon or remove it completely.
Example 3. Disabling saslauthd
[firstname.lastname@example.org]# cd /etc/init.d/ [email@example.com]# chkconfig --del saslauthd
When we create the sasldb database we must provide information that we defined when we configured Postfix - the value of the realm. This value is set in the smtpd_sasl_local_domain parameter in main.cf
Let's see what we have in /etc/postfix/main.cf:
[firstname.lastname@example.org]# egrep myhostname /etc/postfix/main.cf
In the output of the egrep we find these two lines:
smtpd_sasl_local_domain = $myhostname myhostname = mail.example.com
So in our HOWTO mail.example.com is the value that Postfix will pass as realm when it asks Cyrus-SASL to look for users in the sasldb. We must remember that when we add users, because then we must provide exactly this value to the sasldb; if we don't do that, authentication will fail.
If you set smtpd_sasl_local_domain = $myhostname, then you will always have to submit the REALM that equals $myhostname when you pass the username to SASL.
If you don't want to pass a REALM, then you must leave this parameter empty, but still you need to set it:
Cyrus-SASL provides us with a tool to create, edit and delete users in the sasldb: saslpasswd. The first time we use it, it will also create the sasldb if it hadn't been there before. Default for saslpasswd, unless compiled with different option, is to create the sasldb in /etc. You might want to check if that file exist, before we override some settings that another application might depend on.
In Cyrus-SASL-2.x name of the tool is saslpasswd2 and it will create a database with the name sasldb2. The steps in this HOWTO are the same, but you must use saslpasswd2 to create and change sasldb2.
[email@example.com]# cd /etc/ [firstname.lastname@example.org]# ls -all sasldb ls: sasldb: No such file or directory
Perfect. Let's focus on the parameters and values that we need to pass when we create users in sasldb.
There are three parameters that we must provide when adding users to the sasldb. We begin our statement with the option -c and tell saslpasswd to create a new entry, then we add the already mentioned realm with -u realmname add the task with -a smtpauth and finally we provide the username. If you need a little more information read man saslpasswd.
In the HOWTO we will add our user test to the sasldb.
[email@example.com]# saslpasswd -c -u mail.example.com -a smtpauth test
This is how our command reads. When you add your user, don't forget to use our own, specific realm.
Next thing is to change the owner because it's going to be the user postfix who will want to access the sasldb. There is an option called autotransition which will have Cyrus-SASL upgrade passwords from PLAIN to the other mechanisms that are available. If you enable that option with autotransition:true Postfix will also need to write to that file. This will not be needed in this HOWTO, but we'll prepare the sasldb for use of that option by setting correct r/w permissions.
[firstname.lastname@example.org]# ls -all sasldb -rw------- 1 root root 12515 Mar 15 04:32 sasldb
Since we created it as root it is owned by root and the group root. We'll hand it over to Postfix this way:
[email@example.com]# chown postfix sasldb [firstname.lastname@example.org]# ls -all sasldb -rw------- 1 postfix root 12515 Mar 15 04:32 sasldb
Permissions and ownership are correct, but what about it's content?
Cyrus-SASL provides yet another tool that will list all the users inside the sasldb: sasldblistusers. You simply execute the tool and it will write all the users, their different realms and keys to standard-output.
Our output produces this:
[email@example.com]# sasldblistusers user: test realm: mail.example.com mech: PLAIN user: test realm: mail.example.com mech: CRAM-MD5 user: test realm: mail.example.com mech: DIGEST-MD5
In Cyrus-SASL-2.x users in sasldb2 are listed with sasldblistusers2 and the output will only produce one single line.
[root@example root]# sasldblistusers2 firstname.lastname@example.org: userPassword
That's it. We're done configuring. Ready to find out if everything works.