Ubuntu

Cannot authenticate with saslauthd and mysql

Reported by Eric Munson on 2011-10-16
280
This bug affects 52 people
Affects Status Importance Assigned to Milestone
cyrus-sasl2 (Ubuntu)
High
Unassigned

Bug Description

Upgraded from Natty to Oneiric and now I can no longer authenticate for out going mail using saslauthd. Initial server setup was done following these instructions (http://flurdy.com/docs/postfix/). With mysql logging enabled, user credentials are never selected with a login attempt. /var/log/auth.log with intermittently show:
postfix/smtpd[4930]: sql auxprop plugin using mysql engine
with login attempts and /var/log/mail.log shows:
SASL LOGIN authentication failed: no mechanism available
Every time.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntu:
status: New → Confirmed

 SASL PLAIN authentication failed: no mechanism available
SASL LOGIN authentication failed: no mechanism available

I've been working on this for a few hours and not able to get saslauthd to lookup logins either. upgraded and ensured that libsasl2-2 etc is all installed, has been working fine for the last couple of years and Ubuntu version upgrades without a problem. Logs show nothing useful.

I found a posting about the new version of sasl using multiarch paths and postfix having it hardcoded, not sure if that effects this. No logins will go through at all :x

Juan Rozas (jarozas2010) wrote :

Same problem folks.

At least I can send and receive using squirrelmail (Imap).

Good luck.

Manually upgrading my sasl libs (cyrus-sasl) from 2.1.24rc1 (ubuntu package) to the latest 2.1.25 FIXED my SASL issues. I had to configure --with-ldap --enable-sql (without ldap had version linking problems)

Eric Munson (emunson) wrote :

This did not help for me.

Eric, pls make sure when you do saslauthd -v it shows 2.1.25 and that postfix and saslauthd have been restarted. After that, do the log files show the same thing, and are there any errors popping up when you restart postfix/saslauthd?

Eric Munson (emunson) wrote :

It does show the correct version:
root@server:~/# saslauthd -v
saslauthd 2.1.25
authentication mechanisms: getpwent pam rimap shadow

And there were no errors on restart of saslauthd or postfix

This output claims that sql is not a valid mechanism, but I passed --enable-sql to the configure script and I see

checking SQL... enabled
checking for mysql_select_db in -lmysqlclient... yes

in the configure output

Logs all show the same output, including my mysql log showing that it was never queried.

Eric Munson (emunson) wrote :

Any other suggestions? This has my mail sever down. I have no ability to send, even from webmail. I am happy to test anything but I _really_ need working mail.

Check out my post at the bottom of: http://ubuntuforums.org/showthread.php?t=1859667&page=2

Basically I downgraded libsasl2-2, libsasl2-dev, libsasl2-modules, libsasl2-modules-sql and sasl2-bin
Archives I used: wget http://archive.ubuntu.com/ubuntu/poo...ntu3_amd64.deb http://archive.ubuntu.com/ubuntu/poo...ntu3_amd64.deb http://archive.ubuntu.com/ubuntu/poo...ntu3_amd64.deb http://archive.ubuntu.com/ubuntu/poo...ntu3_amd64.deb http://archive.ubuntu.com/ubuntu/poo...ntu3_amd64.deb

**If you've got a 32bit system, replace _amd64 in all 5 of the urls with _i386

dpkg -i *.deb (assuming you don't have other deb files in this folder!), if it gives you an error add --force-all

Should be good, I finally got mine working again, huge hassle, and someone else used this to get his online too. Good luck!

Eric Munson (emunson) wrote :

This has me working again, thank you so much for the leg work.

Ryan Tucker (rtucker) on 2011-10-18
affects: ubuntu → cyrus-sasl2 (Ubuntu)
potatochip (qpa-simon-44e) wrote :

I did the following;

wget http://archive.ubuntu.com/ubuntu/pool/main/c/cyrus-sasl2/libsasl2-2_2.1.23.dfsg1-5ubuntu3_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/main/c/cyrus-sasl2/libsasl2-modules_2.1.23.dfsg1-5ubuntu3_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/main/c/cyrus-sasl2/libsasl2-modules-sql_2.1.23.dfsg1-5ubuntu3_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/main/c/cyrus-sasl2/libsasl2-dev_2.1.23.dfsg1-5ubuntu3_amd64.deb
wget http://archive.ubuntu.com/ubuntu/pool/main/c/cyrus-sasl2/sasl2-bin_2.1.23.dfsg1-5ubuntu3_amd64.deb
dpkg -i --force-all *.deb

and then installed saslauthd 2.1.25 with the folllowing options;

--enable-sql --with-ldap --enable-login

but I still get;

535 5.7.8 Error: authentication failed: no mechanism available

when I try and connect via smtp

saslauthd -v
saslauthd 2.1.25
authentication mechanisms: getpwent kerberos5 rimap shadow

Is there anything else I need to do or any other information that would be useful.

Thanks

Dan Moore (mooredan) wrote :

Otlay's workaround worked for me. But I had to go through some pushups to get it installed without error. I had a dependency conflict with some :i386 packages.

My procedure was to first turn off the sasl daemon:

sudo /etc/init.d/saslauthd stop

...then remove the existing packages:

sudo dpkg -r libsasl2-dev
sudo dpkg -r libsasl2-modules-sql
sudo dpkg -r sasl2-bin
sudo dpkg -r --force-all libsasl2-2 libsasl2-2:i386
sudo dpkg -r --force-all libsasl2-modules

...and install the older packages:

sudo dpkg -i --force-all libsasl2-modules-sql_2.1.23.dfsg1-5ubuntu3_amd64.deb libsasl2-dev_2.1.23.dfsg1-5ubuntu3_amd64.deb sasl2-bin_2.1.23.dfsg1-5ubuntu3_amd64.deb

...restart:

sudo /etc/init.d/saslauthd restart
sudo /etc/init.d/postfix restart

Note: I think any other updates are on hold until this gets resolved.

e.g.:

sudo apt-get install gnome-tweak-tool

Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
 gnome-tweak-tool : Depends: gnome-shell but it is not going to be installed
 libldap-2.4-2:i386 : Depends: libsasl2-2:i386 but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

potatochip: you first installed the 2.1.23 (which is the version that
WORKS) and then you overwrote some of the files and links by compiling
and installing 2.1.25 (the output of your saslauthd shows 2.1.25 is
what's installed).

Go back into your 2.1.25 source, make uninstall, then run dpkg -i
--force-all *.deb again with the download files. Then restart saslauthd
and postfix and you should be up.

On 10/22/2011 6:53 AM, potatochip wrote:
> I did the following;
>
> wget http://archive.ubuntu.com/ubuntu/pool/main/c/cyrus-sasl2/libsasl2-2_2.1.23.dfsg1-5ubuntu3_amd64.deb
> wget http://archive.ubuntu.com/ubuntu/pool/main/c/cyrus-sasl2/libsasl2-modules_2.1.23.dfsg1-5ubuntu3_amd64.deb
> wget http://archive.ubuntu.com/ubuntu/pool/main/c/cyrus-sasl2/libsasl2-modules-sql_2.1.23.dfsg1-5ubuntu3_amd64.deb
> wget http://archive.ubuntu.com/ubuntu/pool/main/c/cyrus-sasl2/libsasl2-dev_2.1.23.dfsg1-5ubuntu3_amd64.deb
> wget http://archive.ubuntu.com/ubuntu/pool/main/c/cyrus-sasl2/sasl2-bin_2.1.23.dfsg1-5ubuntu3_amd64.deb
> dpkg -i --force-all *.deb
>
>
> and then installed saslauthd 2.1.25 with the folllowing options;
>
> --enable-sql --with-ldap --enable-login
>
> but I still get;
>
> 535 5.7.8 Error: authentication failed: no mechanism available
>
> when I try and connect via smtp
>
>
> saslauthd -v
> saslauthd 2.1.25
> authentication mechanisms: getpwent kerberos5 rimap shadow
>
> Is there anything else I need to do or any other information that would
> be useful.
>
> Thanks
>

On 10/22/2011 1:19 PM, Dan Moore wrote:
> Otlay's workaround worked for me. But I had to go through some pushups
> to get it installed without error. I had a dependency conflict with some
> :i386 packages.
>
> Note: I think any other updates are on hold until this gets resolved.
>
>
> e.g.:
>
> sudo apt-get install gnome-tweak-tool
>
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> You might want to run 'apt-get -f install' to correct these:
> The following packages have unmet dependencies:
> gnome-tweak-tool : Depends: gnome-shell but it is not going to be installed
> libldap-2.4-2:i386 : Depends: libsasl2-2:i386 but it is not going to be installed
> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
@dan: I kept originally had my apt broken with "E: Unmet dependencies.
Try 'apt-get -f install'", and actually running that broke it (and
ruined the next day for me..) Basically if you run it, you'll get your
package manager back, and then you need to run dpkg -i --reinstall again
on the 2.1.23 packages and you'll be good to go. If you try to do any
apt-get dist-upgrade or install something that is related to
sasl/postfix it WILL try to upgrade your sasl packages, do NOT do that
or you'll break your system again.

It's better to be able to install other stuff that you need and not have
a crippled system until a viable update is in place. Nothing worse than
trying to setup software without apt because you're afraid to update :P
best of luck

potatochip (qpa-simon-44e) wrote :

Thanks guys. I didn't realise the versions all had to be in sync.

After reinstalling saslauthd 2.1.23 i had to edit /etc/default/saslauthd and change my OPTIONS parameter to get everything working again.

In my case I had set my instance up according to http://www.howtoforge.com/virtual-users-and-domains-with-postfix-ubuntu-7.10-p3nwhich shows how long this has been working for; Ubuntu 7.10 was that Hoary or Gutsy?

Anywiay I had to reset the OPTIONS parameter of /etc/default/saslauthd to;

OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"

Thanks again.

Juan Rozas (jarozas2010) wrote :

Hello,

I'm unfamiliar with the bugs status, but this "Unassigned" seems to mean that nobody is currently working to solve it.

Bobonov (roberto-braga) wrote :

in answer to Dan Moore https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/875440/comments/12
you can put single package in hold for update by synaptic o at command line by using

echo package_name hold | dpkg --set-selections
to activate the upgrade again
echo package_name install | dpkg --set-selections

Maybe is easyer with aptitude
so in our case is (ofcourse execute as root or add sudo at begin):
aptitude hold libsasl2-dev
aptitude hold libsasl2-modules-sql
aptitude hold libsasl2-2
aptitude hold libsasl2-modules
aptitude hold sasl2-bin

Later, when the bug will be fixed (it seem it will take a lot of time since is still unassigned), to put the package again in the upgrade cycle just execute:
aptitude unhold libsasl2-dev
aptitude unhold libsasl2-modules-sql
aptitude unhold libsasl2-2
aptitude unhold libsasl2-modules
aptitude unhold sasl2-bin

if later on you don't remember what did you put on hold, just type
dpkg --get-selections
to see only package on old
dpkg --get-selections | grep hold

Dan Moore (mooredan) wrote :

Thanks, your advice was helpful. I'm still able to take upgrades and install new stuff while retaining the older versions of the packages in question.

Thomas Schüßler (vindolin) wrote :

@Dan Moore

after installing the natty packages i get this error:

/usr/sbin/saslauthd: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory

any ideas?

Thomas Schüßler (vindolin) wrote :

^ forget that post.. must have done something wrong.. now it works

Buzz Clifton (buzz-clifton) wrote :

@vindolin

I was getting the same error. I had to perform the additional step of:
    apt-get install libssl0.9.8

This was definitely not the problem for me.

I used aptitude and put the sasl packages on hold, but it somehow keeps
breaking through other, what I thought were unrelated packages and I
have 'make install' on the compiled source, re dpkg -i the .23 debs, and
then make uninstall the compiled source. That's the only thing that
fixes my system, and it's rather frustrating to have it keep breaking,
over and over due to this bug...

On 12/2/2011 7:16 PM, Buzz Clifton wrote:
> @vindolin
>
> I was getting the same error. I had to perform the additional step of:
> apt-get install libssl0.9.8
>

Florent (florent-fortin) wrote :

"aptitude hold" doesn't work for me
I used this one instead:
echo “package hold” | dpkg --set-selections

(http://www.debianadmin.com/how-to-prevent-a-package-from-being-updated-in-debian.html)

Dario Nuevo (dn-n) wrote :

How is the progress on this, is anyone picking it up and fixing it?
I mean, manual downgrading is not really an option and MySQL based auth within sasl is an important feature - how can this be broken so long time?

Any idea when we can expect a fix or a valid workaround in form of a patch of the current release?

Bobonov (roberto-braga) wrote :

The fix is upgrading to the latest release of sasl which is not part of 11.10. Actually no one is in charge of the bug because of low "heat" status which is automatically calculated
https://bugs.launchpad.net/+help-bugs/bug-heat.html
Probably it will be fixed at next ubuntu release

Eric Munson (emunson) wrote :

That isn't a solution. I realize that we are not paying for support, but this sort of statement doesn't encourage me to suggest that route to anyone. If the fix truly is to update to the newer version why can this not be done in Onieric?

To anyone that this bug is affecting, make sure to click "This affects me" at the top to up the bug heat, that seems to be the only way to get Canonical to fix something they broke.

I totally agree with you, this is kind of ridiculous. Waiting til the
next version?? I can't wait until April for it to be taken care of. As
a long, long time user of Debian, and a strong advocate for the use of
Ubuntu to anyone with technical savvy enough to handle Linux, I'm pretty
appalled at the seriousness of this problem and how much of an issue
this has been. Anyone running a mail server on Ubuntu with
authentication (and if you're not, you're dumb) is likely to encounter
this. This has seriously made me reconsider if there is a better
distribution I should be using, one that won't significantly damage my
system when I upgrade. EVERY WEEK this re-breaks on my system and I
have to manually fix it. I only know it's down when I wake up to an
inbox of cron errors or an angry phone call from a client. All of the
packages have been set on hold in aptitude, yet every week it seems to
screw itself up again without any help on my part. This SERIOUSLY has
to get taken care of ASAP

On 1/1/2012 12:02 PM, Eric Munson wrote:
> That isn't a solution. I realize that we are not paying for support,
> but this sort of statement doesn't encourage me to suggest that route to
> anyone. If the fix truly is to update to the newer version why can this
> not be done in Onieric?
>
> To anyone that this bug is affecting, make sure to click "This affects
> me" at the top to up the bug heat, that seems to be the only way to get
> Canonical to fix something they broke.
>

Andreas Moog (amoog) on 2012-01-01
Changed in cyrus-sasl2 (Ubuntu):
importance: Undecided → High
JBAT (taylorj) wrote :

I have my Ubuntu server setup with Webmin. (It is a web interface to
manage a server) in that, I have it set to notify me of updates, but not
to do any updating. After I did the manual downgrade of saslauthd, weeks
ago, I have not had a problem of it auto updating everyweek. I just go
in with Webmin, select everyting but sasl*, and install patches. No
problems with it breaking each week, but it is a pain to have to manualy
monitor it so it doesn't get the current (but messed up) sasl.

On 1/1/2012 10:18 AM, Otlay Interactive wrote:
> I totally agree with you, this is kind of ridiculous. Waiting til the
> next version?? I can't wait until April for it to be taken care of. As
> a long, long time user of Debian, and a strong advocate for the use of
> Ubuntu to anyone with technical savvy enough to handle Linux, I'm pretty
> appalled at the seriousness of this problem and how much of an issue
> this has been. Anyone running a mail server on Ubuntu with
> authentication (and if you're not, you're dumb) is likely to encounter
> this. This has seriously made me reconsider if there is a better
> distribution I should be using, one that won't significantly damage my
> system when I upgrade. EVERY WEEK this re-breaks on my system and I
> have to manually fix it. I only know it's down when I wake up to an
> inbox of cron errors or an angry phone call from a client. All of the
> packages have been set on hold in aptitude, yet every week it seems to
> screw itself up again without any help on my part. This SERIOUSLY has
> to get taken care of ASAP
>
> On 1/1/2012 12:02 PM, Eric Munson wrote:
>> That isn't a solution. I realize that we are not paying for support,
>> but this sort of statement doesn't encourage me to suggest that route to
>> anyone. If the fix truly is to update to the newer version why can this
>> not be done in Onieric?
>>
>> To anyone that this bug is affecting, make sure to click "This affects
>> me" at the top to up the bug heat, that seems to be the only way to get
>> Canonical to fix something they broke.
>>

Juan Rozas (jarozas2010) wrote :

Hello folks,

Is really difficult to defend the use of Ubuntu and even Linux when things like this occurs.

Surelly we don't pay, and so we can't not require anyone to solve our problem, I now that. But I wonder if this was solved in case we've used any of the pay services from Ubuntu.

I'm using my server for my small bussines and thus is vital for me. Now i'm installing a second box server for redundancy and test, and this the doubt arrises; Should I install a LTS Ubuntu(is better in terms of buggs?) or definitely move to Debian or others?

Good luck.

Dario Nuevo (dn-n) wrote :

I don't think we have to doubt linux (or Ubuntu) as a platform now, this discussion is simply not productive..

This is just a messy bug with a big impact (which is now reflected by the "high" priority) on many users relying on a specific functionality which is now broken.

We now see a downside of the 4 month release cycle - and yes, I also think now that LTS is better suited for servers ;-) I still think that this bug should've been encountered during testing and the new sasl-release shouldn't have made it into 11.10..

Dario Nuevo (dn-n) wrote :

Hi Quanah

I'm a little bit confused - the links you posted relate to the behavior if you've got no auxprop plugins available - they deal with a decent fallback behavior..

But I think this is another problem - we all have auxprop plugins available (and want to use them), but they don't seem to work anymore.. that's the problem we're trying to fix - or am I missing the point? ;-)

Dario Nuevo (dn-n) wrote :

I could resolve the issue in my particular setup.. Not with new packages (I'm still having installed the latest oneiric packages), just with configuration changes. In my case it's working again..

Just to clarify, I have a Postfix SMTP -> Sasl -> Mysql setup, and updated from 11.04 to 11.10 - after that I experienced this error.

First, I reinstalled libsasl2-modules-sql (don't know if that's necessary)..

Then I changed /etc/postfix/sasl/smtpd.conf as follows:

root@node:/etc/postfix/sasl# diff -u smtpd.conf~ smtpd.conf
--- smtpd.conf~ 2011-11-27 11:06:36.000000000 +0100
+++ smtpd.conf 2012-01-12 10:07:02.000000000 +0100
@@ -1,9 +1,10 @@
 pwcheck_method: saslauthd
-mech_list: plain login
+mech_list: plain login pam
 allow_plaintext: true
-auxprop_plugin: mysql
+auxprop_plugin: sql
+sql_engine: mysql
 sql_hostnames: 127.0.0.1
 sql_user: [REMOVED]
 sql_passwd: [REMOVED]
 sql_database: ispconfig
-sql_select: select password from mail_user where email = '%u'
+sql_select: select password from mail_user where login = '%u@%r'

What changed in the upgrade?
- The auxprop plugin name changed from "mysql" to "sql" (it's generic now)
- The new parameter "sql_engine" needs to be set with your engine (in my case mysql)
- The select query has to be changed *maybe* - it seems usernames like "<email address hidden>" are now automatically split up. Before this version %u contained the whole username, now the part after "@" in the username is defined in %r

So maybe the creator of this bug and other people like me just forgot to make the appropiate changes in the smtpd.conf?

Or maybe - again - I'm missing the point of this bug. But it seems you *can* have mysql based smtp auth with the current oneiric packages - it's working in my case..

Robert Kopaczewski (rk-i) wrote :

Thanks Dario, this works nice for me as well.
But this shouldn't really be required. It is either broken or backwards incompatible with some config syntax. Either way, it should either be fixed or alert you about incompatibility.

Bobonov (roberto-braga) wrote :

I think is a bug since people claim that compiling and installing the latest release it works without config change
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/875440/comments/4

Lafriks (lauris-nix) wrote :

I have tried all possible solutions and only working one is downgrading to version .23. I did build .25 deb packages for oneiric from upstream source and can say that this does not help. It not only affects authorization with mysql but also ldap does not seem to work. To me it seems libsasl2 can not find correct conf file and it does not meter where you place it. I have tried all possible places that are defined where it should look for. Maybe there something to do with multiarch changes when packaging deb?

Riaan Aspeling (y-riaan) wrote :

@Dario Nuevo, thank you, that solved my problem 100%. I'm able to send email via MS Outlook now, no problem.

Rohit Yadav (rohityadav) wrote :

Just upgraded to 12.04 LTS and it broke my mail server. Any fix or workaround for 12.04LTS? Or, has anybody tried to use dovecot instead of cyrus only for smtp authentication.

Rohit Yadav (rohityadav) wrote :

Okay I used dovecot sasl for smtp authentication with postfix based on flurdy's tutorial, I simply switch smtp/sasl auth to dovecot and used dovecot's sql userdb authentication and it worked.

E.T. Anderson (firebringer11) wrote :

I can confirm this effects Precise 12.04.

I was able to somewhat work around this by changing the SASL auth mechanism from 'pam' to 'rimap' though I have yet to get authentication working in Roundcube. At lest testsaslauthd succeeds with the rimap mechanism.

Changed in cyrus-sasl2 (Ubuntu):
assignee: nobody → Steven Tappert (sammy8806)
assignee: Steven Tappert (sammy8806) → nobody
Eric Munson (emunson) wrote :

I explicitly made the changes in smtpd.conf as suggested in comment #34 and I still see the problem, I am back on 2.1.23. I have not upgraded to Precise because this is still a problem.

cubells (cubells) wrote :

This is not a problem, It's a serious problem.

I have three debian servers and I decided to install an ubuntu server in order to test the ubuntu server and because I believe we have to use it to improve it.

And I can't use my ubuntu server due to this problem. And I'm pissed because it's a bug easy to fix.

I have no choice but to uninstall ubuntu server and return to my beloved debian.

Tim Pinet (tim-pinet) wrote :

I installed a clean 12.04 Precise with full updates onto a VM just to test this issue (also following the Flurdy install proc) and this is still an issue. I have tried Dario's (https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/875440/comments/34) reccomendation and still get the same errors:

Jun 14 09:58:54 ubuntuservervm postfix/smtpd[9800]: warning: SASL authentication failure: unable to canonify user and get auxprops
Jun 14 09:58:54 ubuntuservervm postfix/smtpd[9800]: warning: unknown[192.168.75.1]: SASL DIGEST-MD5 authentication failed: no mechanism available
Jun 14 09:58:54 ubuntuservervm postfix/smtpd[9800]: warning: unknown[192.168.75.1]: SASL LOGIN authentication failed: no mechanism available

I see that in the last month the ticket has become Unassigned...not promising. Does anyone have any solutions (ie drop cyrus for dovecot, etc)? I would like minimal impact to my existing server and not have to bring in new systems for something so small.

Lafriks (lauris-nix) wrote :

It's actually very disappointing to see this bug still there and as it seems to be specific to ubuntu I was hoping it will be fixed for 12.04 but because it's not looks like I wont be upgrading anytime soon...

I'm pretty sure this actually no longer classifies as a bug, and is
really an issue in documentation of upgrades / lack of reverse support.

I don't have an old copy of my smtpd.conf file from when I upgraded and
it first broke, but my new smtpd.com shows:

auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: xxxxx
sql:passwd: xxxxx
sql_database: mail
sql_select: select crypt from users where id='%u@%r' LIMIT 1

If I recall, it wasn't listed as auxprop_plugin: sql before, and the
prefixes of the user/pass/etc I think were not sql_ before. I had a
broken mail system and had to downgrade postfix versions, finally got it
working with the configuration change.

On 6/14/2012 10:54 AM, Lafriks wrote:
> It's actually very disappointing to see this bug still there and as it
> seems to be specific to ubuntu I was hoping it will be fixed for 12.04
> but because it's not looks like I wont be upgrading anytime soon...
>

Lafriks (lauris-nix) wrote :

I will probably clarify myself a bit. As I have also said in one of my previous comments problem is not only in smtp configuration. I use cyrus-sasl to get subversion server authenticate with active directory (ldap) and in current ubuntu package it is totally broken. I tried to set up virtual debian server with same version of cyrus-sasl2 package and it does work but does not on ubuntu so it's not just documentation/configuration issue but actually some kind of bug in this or related package. I would bet it's most probably just packaging issue but I was not able to find cause for this bug.

Are you using ldap instead of sql for your mail authentications? If
you're getting the same problem that I initially described here, between
saslauthd and mysql via cyrus-sasl, then I'd say it's almost definitely
a configuration problem, as I spent a couple months pulling my hair out
and screaming trying to come up with a solution or figure out what was
wrong before realizing it was a simple yet uberly important change.

On 6/14/2012 11:26 AM, Lafriks wrote:
> I will probably clarify myself a bit. As I have also said in one of my
> previous comments problem is not only in smtp configuration. I use
> cyrus-sasl to get subversion server authenticate with active directory
> (ldap) and in current ubuntu package it is totally broken. I tried to
> set up virtual debian server with same version of cyrus-sasl2 package
> and it does work but does not on ubuntu so it's not just
> documentation/configuration issue but actually some kind of bug in this
> or related package. I would bet it's most probably just packaging issue
> but I was not able to find cause for this bug.
>

Tim Pinet (tim-pinet) wrote :

@Otlay: so for you to get it to work you:
1) upgraded an 11.x dist to 12.04 Precise
2) downgraded postfix and sasl
3) made the undocumented configuration changes
and it works for you now?

Eric Munson (emunson) wrote :

@Otlay

I have that exact setup in my smtp.conf and updated cyrus-sasl packages break for me with the original error.

Close but not quite.

Originally BEFORE I made the config changes, I had to downgrade sasl
specifically and relink a couple libraries and I was able to get it
working (but every time I would upgrade apt packages, it would manage to
break again, after telling it not put those packages on hold). I still
have the 3x deb packages for the outdated sasl / mysql that works.

Then I found out about the config changes, so I upgraded sasl, which
entirely broke it, then I made the config changes and haven't had
another problem since.

On 6/14/2012 11:39 AM, Tim Pinet wrote:
> @Otlay: so for you to get it to work you:
> 1) upgraded an 11.x dist to 12.04 Precise
> 2) downgraded postfix and sasl
> 3) made the undocumented configuration changes
> and it works for you now?
>

You're seeing:

   postfix/smtpd[4930]: sql auxprop plugin using mysql engine
   with login attempts and /var/log/mail.log shows:
   SASL LOGIN authentication failed: no mechanism available
   Every time.

?? Were there any changes to the log output when you made the changes? Dumb question but I'm assuming you restarted sasl and postfix etc after changes

On 6/14/2012 11:49 AM, Eric Munson wrote:
> postfix/smtpd[4930]: sql auxprop plugin using mysql engine
> with login attempts and /var/log/mail.log shows:
> SASL LOGIN authentication failed: no mechanism available
> Every time.

Lafriks (lauris-nix) wrote :

@Otlay: I don't use mailserver at all on that server. I use cyrus-sals2 just so that users can be authenticated on subversion server. In my case there are no alternatives (as switching to dovecot) as it's only way to get svnserve daemon to authenticate users against ldap. It just can't be configurtion problem as with same cyrus-sasl2 versions and with same configuration files it does work on debian but does not on ubuntu

Eric Munson (emunson) wrote :

@Otlay

After poking at the config file for some time I now get "Jun 14 13:14:19 machine postfix/smtpd[15252]: connect from localhost[127.0.0.1]
Jun 14 13:14:19 machine postfix/smtpd[15252]: setting up TLS connection from localhost[127.0.0.1]
Jun 14 13:14:19 machine postfix/smtpd[15252]: Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
Jun 14 13:14:19 machine postfix/smtpd[15252]: warning: localhost[127.0.0.1]: SASL LOGIN authentication failed: generic failure"

And auth.log complains about not being able to connect to my mysql db

Using the credentials stored in smtp.conf I am able to login by hand and run the login query and everything works but sasl can't seem to connect.

Google is turning up lots of people asking the same question, but I have yet to find an answer.

Devin Bileck (dbileck) wrote :

@Eric
I was having that same issue until I realized I had sql_passw instead of sql_passwd in /etc/postfix/sasl/smtpd.conf.

Eric Munson (emunson) wrote :

I tried both flavors of sql_passwd and neither worked, I just gave up and switched to dovecot for imap and sasl.

The fix from Devin appears to have worked for me:

# cat /etc/postfix/sasl/smtpd.conf
pwcheck_method: saslauthd
mech_list: plain login cram-md5 digest-md5
log_level: 7
allow_plaintext: true
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: <user>
sql_passwd: <pass>
sql_database: <db>
sql_select: select crypt from users where id='%u@%r' and enabled = 1

Eric Munson (emunson) wrote :

----- Reply message -----
From: "Carson Longhorn" <email address hidden>
To: <email address hidden>
Subject: [Bug 875440] Re: Cannot authenticate with saslauthd and mysql
Date: Sat, Jun 23, 2012 01:21

The fix from Devin appears to have worked for me:

# cat /etc/postfix/sasl/smtpd.conf
pwcheck_method: saslauthd
mech_list: plain login cram-md5 digest-md5
log_level: 7
allow_plaintext: true
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: <user>
sql_passwd: <pass>
sql_database: <db>
sql_select: select crypt from users where id='%u@%r' and enabled = 1

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/875440

Title:
  Cannot authenticate with saslauthd and mysql

Status in “cyrus-sasl2” package in Ubuntu:
  Confirmed

Bug description:
  Upgraded from Natty to Oneiric and now I can no longer authenticate for out going mail using saslauthd. Initial server setup was done following these instructions (http://flurdy.com/docs/postfix/). With mysql logging enabled, user credentials are never selected with a login attempt. /var/log/auth.log with intermittently show:
  postfix/smtpd[4930]: sql auxprop plugin using mysql engine
  with login attempts and /var/log/mail.log shows:
  SASL LOGIN authentication failed: no mechanism available
  Every time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/875440/+subscriptions

Mark Goldenstein (goldmar) wrote :

PLEASE FIX THIS BUG ASAP!!! I don't understand why you did not fix this yet. I just upgraded from 10.04 LTS to 12.04 LTS and now have the same problem as many other people here.

This bug is a real pain in the ass! I've tried the mentioned workaround - downgrading the sasl packages - and it works. However, I then get an even nastier problem: downgrading sasl causes OpenLDAP to break - it only works until I try to restart slapd. I get the following in my log files:

Jun 25 15:26:59 slapd[6358]: @(#) $OpenLDAP: slapd (Apr 5 2012 16:22:20) $#012#011buildd@allspice:/build/buildd/openldap-2.4.28/debian/build/servers/slapd
Jun 25 15:26:59 slapd[6358]: slap_sasl_init: auxprop add plugin failed
Jun 25 15:26:59 slapd[6358]: slapd stopped.

And slapd does not start anymore (until I reupgrade the sasl packages). I also can't try the sasl configuration change because I use sasl to authenticate via LDAP and not MySQL.

Any ideas how to make both SASL via LDAP and OpenLDAP work?

Mark Goldenstein (goldmar) wrote :

Solved this by downgrading sasl as described and then manually recompiling slapd against the older sasl libraries...

Tim Mann (4za) wrote :

Hi. I've very new to Ubuntu but came across this exact same problem when setting up a mail server. I've been following the Flurdy tutorial line by line from a fresh server install. When I got to the SASL step I got the magic 'mech not available message'.

I carried out the following edits:

(This is the original file on the Flurdy site):

pwcheck_method: saslauthd
mech_list: plain login cram-md5 digest-md5
log_level: 7
allow_plaintext: true
auxprop_plugin: mysql
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: mail
sql_passw: mailPASSWORD
sql_database: maildb
sql_select: select crypt from users where id='%u@%r' and enabled = 1

I changed this file to:

pwcheck_method: saslauthd
mech_list: plain login pam
log_level: 7
allow_plaintext: true
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: mail
sql_passwd: mailPASSWORD
sql_database: maildb
sql_select: select crypt from users where id='%u@%r' and enabled = 1

(database name and pw are from the sample not my own!)

Note the changes to the 3 lines 'mech_list', 'auxprop_plugin' changed to 'sql' rather than 'mysql' and 'sql_passw' changed to 'sql_passwd'.

Before I changed this last one I was getting 'generic error'.

After the above changes I restarted both post fix and saslauthd. It then worked fine. I don't have TLS yet as I haven't got to that part of the doc. But as I said this is using 12.04 from a clean install and following that tutorial line by line. I hope this is of use to someone.

Dario Nuevo (dn-n) wrote :

The discussion here is getting cluttered and messy - we have many different situations which may or may not work which makes it hard to finally solve this one.

So far we have
- People which solve only with config changes
- People which get it to work which downgrading / maybe relinking
- People bringing up sasl -> slapd problems (not postfix related anymore)
- People complaining about this bug in general (like Comment #59 which is not helping at all)

The most important point is that it should be safe to upgrade an Ubuntu Server. If you upgrade, such a delicate component as smtp auth should not be broken. And I think it's only a configuration issue.

We have to find & verify valid configurations for people doing a fresh install and an upgrade. Downgrading cannot be an option and should not be necessary (at least not for postfix -> sasl). I think the approach in comment #44 to verify it in a VM is the most promising one.

I'll try to port my physical server to a VM and upgrading it to Precise during the next week, try to find a working config with the newest packages and post it here. There has to be a way guys, we'll work this out.. ;-)

Dario Nuevo (dn-n) wrote :

So I tried to verify the upgrade consequences - I cloned my physical server into a VM and made the distribution upgrade from Oneiric to Precise.

First let me state (and this has nothing to do with this bug *g), that the upgrade experience as really a pain in the a*s! Incredible.. AppArmor gets re-enabled which breaks a lot of stuff, you get prompted for a MySQL password change 5 times, Apache doesn't work anymore (have to figure that out) and so on - *major* annoyances to say it friendly ;-(

Conclusion
--------------
Anyway.. my conclusion is positive: The configuration I provided in comment #34 (see there) still works with the newest packages in Precise without any relinking and/or downgrading! At least in my case..

The "generic error"
------------------------
It didn't work out of the box - I DID GET the "generic error" message directly after the upgrading.
Turns out, that it was an error with MySQL. MySQL gets upgraded to 5.5..

It seems that the database variable "open_files_limit" comes with a default value of 1024 after the upgrade. This is really low and reached already if you have some databases in my case.

So I inserted one line in /etc/mysql/my.cnf which sets the limit really high to test it:

[mysqld]
open_files_limit = 999999

Restart mysql at this point..

After that, I finally could send mails through the SMTP with working sasl auth! So the "generic error" in my case resulted from the fact that mysql did abort the auth query request with an error message because it didn't have any resources left.. (this error: http://dev.mysql.com/doc/refman/5.5/en/not-enough-file-handles.html)

Next step?
--------------
Could please someone who upgraded to Precise and applied the config from comment #34 and still have the "generic error" check this mysql setting in their setup and verify that they really applied everything correctly?

[Appendix]
Versions of key packages in use now (working combination)
postfix 2.9.1-5
mysql-server 5.5.24-0ubuntu0.12.04.1
libsasl2-dev 2.1.25.dfsg1-3ubuntu0.1
libsasl2-modules-sql 2.1.25.dfsg1-3ubuntu0.1
libsasl2-2 2.1.25.dfsg1-3ubuntu0.1
sasl2-bin 2.1.25.dfsg1-3ubuntu0.1

Mark Goldenstein (goldmar) wrote :

Dario, thanks for classifying my comment as "not helpful at all".

Let me reiterate. I'm using Postfix to authenticate via saslauthd against LDAP (not MySQL) and thus I can't apply the mentioned configuration fix. Since the upgrade I was getting the same error: SASL LOGIN authentication failed: no mechanism available.

The only fix I've found to be working was downgrading SASL as mentioned above. I also needed to recompile / relink (whatever you call it) slapd since it was broken by the sasl downgrade.

Dario Nuevo (dn-n) wrote :

Hi Mark

Well, I didn't mean that personally, hope it didn't come across the wrong way.. sorry!
The main problem is that this bug is about postfix -> sasl -> mysql, bringing ldap into it makes this one harder to solve.

Anyway - you didn't post your configuration file - did you fiddle around with the config file? It really seems that the newer sasl versions just require a different configuration.

Your error
> Jun 25 15:26:59 slapd[6358]: slap_sasl_init: auxprop add plugin failed
suggests that it can't find the auxprop plugin - maybe the name of the plugin also changed (as "mysql" changed to "sql") or it requires new parameters?

As I see the name should be "ldapdb", you can review the parameters here: http://cyrusimap.web.cmu.edu/docs/cyrus-sasl/2.1.25/options.php

And if it's really broken (confirmed), you should open a new bug which is purely postfix -> sasl -> ldap related.

Panos Asimakopoulos (pasimako) wrote :

I'd like to share my experience with this issue.

I'm also following the Flurdy tutorial for setting up postfix (http://flurdy.com/docs/postfix/), which used to work perfectly fine on my Ubuntu 10.04 installation. However on a fresh 12.04 (AMD64) installation with all recent upgrades I'm experiencing the issue described in this bug report.

As was mentioned above, with the original setting of "sql_engine: mysql", mail.log reports "SASL PLAIN authentication failed: no mechanism available". So change this to: "sql_engine: sql"

Also with "sql_passw: <mailPASSWORD>", mail.log reports "SASL PLAIN authentication failed: generic failure". So change this to: "sql_passwd: <mailPASSWORD>"

However I was still getting a "SASL LOGIN authentication failed: authentication failure" in mail.log and a "PAM (smtp) illegal module type: host=127.0.0.1" in auth.log. I found out that when I copy-pasted the contents of /etc/pam.d/smtp from the Flurdy site I had accidentally created 2 lines per entry in /etc/pam.d/smtp:

(2 lines per entry):
auth required pam_mysql.so user=mail passwd=aPASSWORD
   host=127.0.0.1 db=maildb table=users usercolumn=id passwdcolumn=crypt crypt=1
account sufficient pam_mysql.so user=mail passwd=aPASSWORD
   host=127.0.0.1 db=maildb table=users usercolumn=id passwdcolumn=crypt crypt=1

Which I corrected to:

(1 line per entry):
auth required pam_mysql.so user=mail passwd=aPASSWORD host=127.0.0.1 db=maildb table=users usercolumn=id passwdcolumn=crypt crypt=1
account sufficient pam_mysql.so user=mail passwd=aPASSWORD host=127.0.0.1 db=maildb table=users usercolumn=id passwdcolumn=crypt crypt=1

After restarting /etc/init.d/saslauthd restart and /etc/init.d/postfix restart everything worked as expected.

Mark Goldenstein (goldmar) wrote :

For the record, the saslauthd => ldap bug seems to be fixed after updating all the related packages.

Dario, thanks for your answer. However, please note that auxprop/ldapdb and saslauthd/ldap are different modules and not related to each other.

Well, this bug (or whatever you call this) is out for so long and the held back packages started to effect other ones. So, I decided to change my authentication method from "auxprop" to "rimap". I did this because, I couldn't risk changing from courier to devocot like mentioned in other posts. And since I got a working imap authentication, I asked, why not?

So, basically, what i did is,
1- I stopped holding sasl2 packages which are at version 2.1.23,
2- Upgraded to latest packages for sasl2 in Ubuntu 12.04 (This OS has been upgraded from 9.04->9.10->10.04->12.04),
3- Configured new sasl2 to work with "rimap" (search for "rimap configuration" in google to tune configuration for your own machine)
4- Restarded saslauthd daemon and postfix service.
5- Enjoyed sending e-mail with the latest packages installed...

Kevin (kevin-cousins) wrote :

@Dario - Thanx a million! I just upgraded from Lucid to Precise, had the same authentication problem, followed your edit as described in post 34:

pwcheck_method: saslauthd
mech_list: plain login pam
allow_plaintext: true
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: [REMOVED]
sql_passwd: [REMOVED]
sql_database: dbispconfig
sql_select: select password from mail_user where login = '%u@%r'

My outgoing mail is now unbroken.

Axe (jfo123) wrote :

After a few hours of trying different configurations, resisting to downgrade the packages, I finally succeeded to do a reconfiguration as mentioned above (as Dario) among others.

BUT, I still didn't get authenticated, the domain part "fell off" the sql until I did a change to change to OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r" in "/etc/default/saslauthd" just like potatochip stated. But note, I did not need to downgrade anything. Still running the original packages after the upgrade to 12.04 LTS.

Finally a word of testing and releases. It is a disgrace that packages in an LTS isn't fixed sooner. No matter where the problem lies, Linux consists of several packages developed by many different teams. Email servers are even more important than webservers and cannot fail because of lack of interest to fix critical upgrades like this. I deeply respect all developers taking part in open source development, but failures to address issues like this just cannot be part of professional releases ( as an LTS version is supposed to be ) in the future.

potatochip (qpa-simon-44e) wrote :

Found myself back on this thread a year after and am now using Dario's fix in post 34.
Nice work Dario!

potatochip (qpa-simon-44e) wrote :

Bugger I spoke too soon. It seems to have stopped working again.

I've now done as evrimfuruncu suggested and used rimap. it's far easier than banging my head against the wall.
For anyone interested my steps were;

Edit /etc/postfix/sasl/smtpd.conf so that it only conatins;

pwcheck_method: saslauthd
mech_list: plain login

Edit /etc/default/saslauthd and change these lines;

MECHANISMS="rimap"
MECH_OPTIONS="127.0.0.1"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"

Everything is now working and my system is up to date.

I've had the same problem.
what fixed it for me was to change in /etc/postfix/sasl/smtpd.conf:

Replace:
auxprop_plugin: mysql

with:
auxprop_plugin: sql
sql_engine: mysql

and change the %u in "sql_select: select password from mail_user where login = '%u'" to %u@%r

thats all..

cubells (cubells) wrote :

I can confirm that Arnold solution (#73) works in my ubuntu precise.

I've perfomed a do-release-upgrade and all works fine after made these changes.

cheers.

Monkberry (peter-monkberry) wrote :

Solved-Works
I really hope this helps some people on here but I've found a solution that does NOT require uninstalling packages or installing anything that's not in the stock repos for precise 12.04 for use in saslauthd(cyrus), mysql, postfix scenario.
The gist of the problem seems to be syntax changes and the fact that if used in postfix (with chroot environment), a missing link in /var/run to the chroot of /var/spool/postfix/var/run/saslauthd.

If postfix is chrooted (and it probably is)
/etc/default/saslauthd
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"
(needed the -r option, that puts the name and domain together, short for realm, without that it will send the user as "george" not "<email address hidden>"

/etc/pam.d/smtp
auth required pam_mysql.so user=mail passwd=yourdbpassword host=127.0.0.1 db=maildb table=users usercolumn=id passwdcolumn=clear crypt=0
account sufficient pam_mysql.so user=mail passwd=yourdbpassword host=127.0.0.1 db=maildb table=users usercolumn=id passwdcolumn=clear crypt=0
(this file needed the appropriate references to the database and table names and since I used clear passwords, I needed to change crypt=1 to crypt=0. (and the passwdcolumn from crypt to clear) I did this so the clear passwords would read all the password. Using crypt in the mysql table, it would only recognize the first 8 characters and ignore the rest.

And here's where the real changes took place, in the syntax.
/etc/postfix/sasl/smtpd.conf file need the changed syntax (alot) and relevant sql query info. NOTE: I did NOT need the "pam" mech_list option that I thought before.
pwcheck_method: saslauthd
mech_list: plain login cram-md5 digest-md5
log_level: 7 #Remove this line when done
allow_plaintext: true
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: mail
sql_passwd: yourdbpasswd
sql_database: maildb
sql_select: select clear from users where id='%u@%r' and enabled = 1
(note the use of the field "clear", you probably want "crypt" if using flurdy's how-to.

/etc/postfix/master.cf
submission inet n - - - - smtpd
# -o syslog_name=postfix/submission
# -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

/etc/postfix/main.cf
# SASL
smtpd_sasl_auth_enable = yes
# If your potential clients use Outlook Express or other older clients
# this needs to be set to yes
broken_sasl_auth_clients = no
smtpd_sasl_security_options = noanonymous
# also add
# Add permit_sasl_authenticated to you existing smtpd_sender_restrictions
# Add permit_sasl_authenticated to you existing smtpd_recipient_restrictions

Fixed the sasl path problem by writing a script as such to run at boot as I didn't want to try and figure out what the hell the deal was with the path, how it starts, what starts it, what names it, sasl is a pain in the ass!

#!/bin/bash
sleep 5
ln -s /var/spool/postfix/var/run/saslauthd /var/run/saslauthd
/etc/init.d/saslauthd restart
/etc/init.d/postfix restart

That did it!!
Finally got port 587 working and authenticating.
Don't forget to open the port if not already done on the firewall!!!!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.