I'm running ISPConfig 2.2.13 on Debian Etch. I was recently assigned the task of enabling SMTP AUTH on this machine. It looks like SASL is already installed. I've worked through the "Perfect Setup" steps at http://www.howtoforge.com/perfect_setup_debian_etch_p5 and am now testing my auth mechanism. I'm using testsaslauthd and not getting what I expect. Specifically,I'm using: testsaslauthd -u [email protected] -p mypass -f /var/spopostfix/var/run/saslauthd/mux which is returning: 0: NO "authentication failed" The user name and password I'm using are working just fine when I telnet to port 110. When I look in /var/log/auth.log I see: Jan 8 08:56:29 gx saslauthd[8301]: do_auth : auth failure: [service=imap] [realm=] [mech=pam] [reason=PAM auth error] Suggestions? Do I maybe have to do something with a file under /etc/pam.d?
Better you use a normal email client and not testsaslauthd, sasl is configured for postfix and not imap, but you tested imap. Also the username you tested is wrong, ispconfig users have the name web[ID]_user and not [email protected].
Thanks, that fixed it. I had been using testsaslauthd to try to track down why telneting to port 25 and authing manually wasn't working. It's been a few months since I have had to do anything with ISPConfig (once it's installed it just works) so I had forgotten about the domain.tld_user format.
I'm having some issues I've not seen before. I'm still working on getting SMTPAUTH working on my ISPConfig boxes. I'm doing my work on my development machine, then moving configs over to the production machine when I determine that they work. I seem to have the basic hooks running - when I telnet to port 25 and issue an EHLO I get ga:~# telnet localhost 25 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. 220 ge.<my domain> ESMTP Postfix (Debian/GNU) ehlo me 250-ge.<my domain> 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250 8BITMIME I also get the proper response when I issue "auth login". This is where things get interesting. System accounts authenticate just fine. ISPConfig user accounts don't. When I attempt to auth using an ISPConfig user I get entries such as: Jan 21 10:19:40 pr-nwtn saslauthd[2197]: do_auth : auth failure: [service=smtp] [realm=] [mech=pam] [reason=PAM auth error] in /var/log/auth.log. I'm also no longer able to authenticate ISPConfig users via POP. I only come back to look at ISPConfig when the servers develop problems or when management insists on changes. That means that I get plenty of chances to forget ISPConfig's setup :) So, any pointers on what I likely screwed up to keep user auth from working?
Whoa! PAM really doesn't like long user names, does it? I guess my best solution will be to configure SASL to use Courier's userdb to authenticate. I've created some custom maintenance scripts to get the userdb in a format I like, so I'll be researching SASL's auth hooks today. Thanks for pointing out those tools, Till. In all the years I've been using Unix and Linux I've never seen those before. Dan
One thing that might be worth a try is to switch to dovecot and then configure postfix to authenticate against dovecot as external authentication source to avaid using sasl. And you should consider ispconfig 3 for new servers at it is able to use mysql based authentication.
I'd like to do both of those, but around here once a system has gone in to production it takes an act of Congress and a decree from God to get approval to make any changes. For now I'm pretty well stuck figuring out how to get postfix to use Courier's authdaemon. But from what I've found so far it doesn't look like that's going to be an insurmountable problem. Unfortunately when we experienced major problems with Plesk we had to make an immediate change. ISPConfig was the best choice for a replacement, and 2.2.13 was the latest available non-beta version. I had to hack it a bit to get it to fit into our environment (2 servers split between 2 server farms, auto-replicating, configured for auto-failover) and I'm going to have to stick with this version for a while yet. Hosting for our commercial customers has very high visibility with our top-level execs, so I have to be able to present very firm indisputable evidence to get approval to make any changes that aren't requested from on high.
I guess that the courier authdaemon solution will work similar to the one that I suggested with dovecot.