List, I'm trying to set up smtp auth in our network. I've got our mail relay working with it, but I can't seem to get it working under 8.2. I know SuSE does some funny things with their config files due to Yast, so I'm wondering what I'm missing. I have it pretty much set up as the relay (at least all the main config files for postfix and sasl), and it's set to use the saslauthd mechanism through pam. However, smtpd won't authenticate, it fails every time. What am I missing as far as the SuSE way of things goes? Thanks in advance. -- Preston Kutzner
Preston Kutzner wrote:
List,
I'm trying to set up smtp auth in our network. I've got our mail relay working with it, but I can't seem to get it working under 8.2. I know SuSE does some funny things with their config files due to Yast, so I'm wondering what I'm missing. I have it pretty much set up as the relay (at least all the main config files for postfix and sasl), and it's set to use the saslauthd mechanism through pam. However, smtpd won't authenticate, it fails every time. What am I missing as far as the SuSE way of things goes? Thanks in advance.
What does the log say when you try to authenticate? Is saslauthd actually up and running? Sandy
Sandy Drobic wrote:
Preston Kutzner wrote:
List,
I'm trying to set up smtp auth in our network. I've got our mail relay working with it, but I can't seem to get it working under 8.2. I know SuSE does some funny things with their config files due to Yast, so I'm wondering what I'm missing. I have it pretty much set up as the relay (at least all the main config files for postfix and sasl), and it's set to use the saslauthd mechanism through pam. However, smtpd won't authenticate, it fails every time. What am I missing as far as the SuSE way of things goes? Thanks in advance.
What does the log say when you try to authenticate? Is saslauthd actually up and running?
Sandy
saslauthd is running and the only errors I get are: Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: SASL authentication failure: Can only find author/en (no password) Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: unknown[192.168.56.17]: SASL PLAIN authentication failed I've even re-used config files from my working relay, just modified for this machine. This is the same error I get if I try to use the auxprop plugin as well. So, I'm not sure what the deal is. This *should* be working, as I have it pretty much set up like I have my relay set up. I just want our internal mail system's SMTP to match our relay's, that way people don't have to change their settings depending on their location. I'd just like to make it work without them having to worry about it.
Preston Kutzner wrote:
What does the log say when you try to authenticate? Is saslauthd actually up and running?
saslauthd is running and the only errors I get are:
Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: SASL authentication failure: Can only find author/en (no password) Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: unknown[192.168.56.17]: SASL PLAIN authentication failed
Are you checking the login with /etc/passwd or with sasldb? What sort of auth mechanism did you set up for sasl? content of /usr/lib/sasl2/smtpd.conf? content of /etc/sysconfig/saslauthd? Which packages are installed? rpm -qa | grep -i sasl What is the output of telnet localhost 25 ehlo localhost.localdomain Especially the AUTH line? Sandy
Sandy Drobic wrote:
Preston Kutzner wrote:
What does the log say when you try to authenticate? Is saslauthd actually up and running?
saslauthd is running and the only errors I get are:
Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: SASL authentication failure: Can only find author/en (no password) Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: unknown[192.168.56.17]: SASL PLAIN authentication failed
Are you checking the login with /etc/passwd or with sasldb?
What sort of auth mechanism did you set up for sasl? content of /usr/lib/sasl2/smtpd.conf? content of /etc/sysconfig/saslauthd?
Which packages are installed? rpm -qa | grep -i sasl
What is the output of telnet localhost 25 ehlo localhost.localdomain Especially the AUTH line?
Sandy
Here's what you asked for as follows, along with saslfinger output: pkutzner@ein:~> sudo cat /usr/lib/sasl2/smtpd.conf pwcheck_method: saslauthd mech_list: plain login pkutzner@ein:~> sudo cat /etc/sysconfig/saslauthd ## Path: System/Security/SASL ## Type: list(getpwent,kerberos5,pam,rimap,shadow,ldap) ## Default: pam ## ServiceRestart: saslauthd # # Authentication mechanism to use by saslauthd. # See man 8 saslauthd for available mechanisms. # SASLAUTHD_AUTHMECH=pam pkutzner@ein:~> rpm -qa | grep -i sasl perl-Authen-SASL-2.08-2 cyrus-sasl-saslauthd-2.1.19-5 cyrus-sasl-crammd5-2.1.19-7 cyrus-sasl-gssapi-2.1.19-7 cyrus-sasl-devel-2.1.19-7.2 perl-Authen-SASL-Cyrus-0.11-2 cyrus-sasl-otp-2.1.19-7 cyrus-sasl-plain-2.1.19-7 cyrus-sasl-digestmd5-2.1.19-7 cyrus-sasl-2.1.19-7.2 pkutzner@junpei ~$ telnet 192.168.56.73 25 Trying 192.168.56.73... Connected to 192.168.56.73. Escape character is '^]'. 220 ein.mrichi.com ESMTP EHLO junpei.mrichi.com 250-ein.mrichi.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN 250 8BITMIME AUTH PLAIN <base64-encoded login> 535 Error: authentication failed QUIT 221 Bye Connection closed by foreign host. pkutzner@ein:~> sudo /usr/bin/saslfinger -s saslfinger - postfix Cyrus sasl configuration Thu Mar 24 13:58:53 CST 2005 version: 0.9.9.1 mode: server-side SMTP AUTH -- basics -- Postfix: 2.1.5 System: Welcome to SuSE Linux 9.2 (i586) - Kernel \r (\l). -- smtpd is linked to -- libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x4009f000) -- active SMTP AUTH and TLS parameters for smtpd -- broken_sasl_auth_clients = yes smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = $smtpd_sasl_security_options smtpd_tls_session_cache_timeout = 3600s -- listing of /usr/lib/sasl2 -- total 777 drwxr-xr-x 2 root root 1176 2005-03-24 10:56 . drwxr-xr-x 136 root root 57496 2005-03-22 10:07 .. -rwxr-xr-x 1 root root 695 2004-10-14 10:44 libanonymous.la -rwxr-xr-x 1 root root 16297 2004-10-14 10:44 libanonymous.so -rwxr-xr-x 1 root root 16297 2004-10-14 10:44 libanonymous.so.2 -rwxr-xr-x 1 root root 16297 2004-10-14 10:44 libanonymous.so.2.0.19 -rwxr-xr-x 1 root root 683 2004-10-01 21:03 libcrammd5.la -rwxr-xr-x 1 root root 18639 2004-10-01 21:03 libcrammd5.so -rwxr-xr-x 1 root root 18639 2004-10-01 21:03 libcrammd5.so.2 -rwxr-xr-x 1 root root 18639 2004-10-01 21:03 libcrammd5.so.2.0.19 -rwxr-xr-x 1 root root 713 2004-10-01 21:03 libdigestmd5.la -rwxr-xr-x 1 root root 47913 2004-10-01 21:03 libdigestmd5.so -rwxr-xr-x 1 root root 47913 2004-10-01 21:03 libdigestmd5.so.2 -rwxr-xr-x 1 root root 47913 2004-10-01 21:03 libdigestmd5.so.2.0.19 -rwxr-xr-x 1 root root 765 2004-10-01 21:03 libgssapiv2.la -rwxr-xr-x 1 root root 27117 2004-10-01 21:03 libgssapiv2.so -rwxr-xr-x 1 root root 27117 2004-10-01 21:03 libgssapiv2.so.2 -rwxr-xr-x 1 root root 27117 2004-10-01 21:03 libgssapiv2.so.2.0.19 -rwxr-xr-x 1 root root 679 2004-10-14 10:44 liblogin.la -rwxr-xr-x 1 root root 17029 2004-10-14 10:44 liblogin.so -rwxr-xr-x 1 root root 17029 2004-10-14 10:44 liblogin.so.2 -rwxr-xr-x 1 root root 17029 2004-10-14 10:44 liblogin.so.2.0.19 -rwxr-xr-x 1 root root 675 2004-10-01 21:03 libotp.la -rwxr-xr-x 1 root root 49953 2004-10-01 21:03 libotp.so -rwxr-xr-x 1 root root 49953 2004-10-01 21:03 libotp.so.2 -rwxr-xr-x 1 root root 49953 2004-10-01 21:03 libotp.so.2.0.19 -rwxr-xr-x 1 root root 679 2004-10-01 21:03 libplain.la -rwxr-xr-x 1 root root 16987 2004-10-01 21:03 libplain.so -rwxr-xr-x 1 root root 16987 2004-10-01 21:03 libplain.so.2 -rwxr-xr-x 1 root root 16987 2004-10-01 21:03 libplain.so.2.0.19 -rwxr-xr-x 1 root root 704 2004-10-14 10:44 libsasldb.la -rwxr-xr-x 1 root root 21736 2004-10-14 10:44 libsasldb.so -rwxr-xr-x 1 root root 21736 2004-10-14 10:44 libsasldb.so.2 -rwxr-xr-x 1 root root 21736 2004-10-14 10:44 libsasldb.so.2.0.19 -rw------- 1 root root 49 2005-03-24 10:56 smtpd.conf -- content of /usr/lib/sasl2/smtpd.conf -- pwcheck_method: saslauthd mech_list: plain login -- active services in /etc/postfix/master.cf -- # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) smtp inet n - n - 2 smtpd -o smtpd_sasl_auth_enable=yes -o content_filter=smtp:[127.0.0.1]:10024 smtps inet n - n - 2 smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o content_filter=smtp:[127.0.0.1]:10024 pickup unix n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr unix n - n 300 1 qmgr tlsmgr fifo - - n 300 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verify unix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap smtp unix - - n - - smtp relay unix - - n - - smtp showq unix n - n - - showq error unix - - n - - error local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp anvil unix - - n - 1 anvil localhost:10025 inet n - n - - smtpd -o content_filter= maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient} cyrus unix - n n - - pipe user=cyrus argv=/usr/lib/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user} uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient) ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient procmail unix - n n - - pipe flags=R user=nobody argv=/usr/bin/procmail -t -m /etc/procmailrc ${sender} ${recipient} -- mechanisms on localhost -- 250-AUTH LOGIN PLAIN 250-AUTH=LOGIN PLAIN -- end of saslfinger output --
The Thursday 2005-03-24 at 11:46 -0600, Preston Kutzner wrote:
saslauthd is running and the only errors I get are:
Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: SASL authentication failure: Can only find author/en (no password) Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: unknown[192.168.56.17]: SASL PLAIN authentication failed
It might be that suse's postfix does not allow plain authentication. It's got to be encrypted, or over an encrypted connection. I don't remember if it was in 8.2 or later when they did that change. -- Cheers, Carlos Robinson
Carlos E. R. wrote:
The Thursday 2005-03-24 at 11:46 -0600, Preston Kutzner wrote:
saslauthd is running and the only errors I get are:
Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: SASL authentication failure: Can only find author/en (no password) Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: unknown[192.168.56.17]: SASL PLAIN authentication failed
It might be that suse's postfix does not allow plain authentication. It's got to be encrypted, or over an encrypted connection. I don't remember if it was in 8.2 or later when they did that change.
Well, I will eventually be setting up TLS encryption for the session, but I'd like to be able to test and make sure SMTP AUTH is working first, it's more of a pain to debug problems when you have 2 variables, as opposed to just one. Having to worry about SASL *and* TLS problems at the same time (possible) is not what I would prefer.
Preston Kutzner wrote:
saslauthd is running and the only errors I get are:
Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: SASL authentication failure: Can only find author/en (no password) Mar 24 11:42:31 ein postfix/smtpd[12865]: warning: unknown[192.168.56.17]: SASL PLAIN authentication failed
It might be that suse's postfix does not allow plain authentication. It's got to be encrypted, or over an encrypted connection. I don't remember if it was in 8.2 or later when they did that change.
Well, I will eventually be setting up TLS encryption for the session, but I'd like to be able to test and make sure SMTP AUTH is working first, it's more of a pain to debug problems when you have 2 variables, as opposed to just one. Having to worry about SASL *and* TLS problems at the same time (possible) is not what I would prefer.
It might be that SASL is trying other mechanisms before PLAIN. Did you try to uninstall the other mechanisms? In earlier times it was the only way to make sure they don't interfere with the PLAIN authentication. pkutzner@ein:~> rpm -qa | grep -i sasl perl-Authen-SASL-2.08-2 cyrus-sasl-saslauthd-2.1.19-5 cyrus-sasl-crammd5-2.1.19-7 cyrus-sasl-gssapi-2.1.19-7 cyrus-sasl-devel-2.1.19-7.2 perl-Authen-SASL-Cyrus-0.11-2 cyrus-sasl-otp-2.1.19-7 cyrus-sasl-plain-2.1.19-7 cyrus-sasl-digestmd5-2.1.19-7 cyrus-sasl-2.1.19-7.2 From this list uninstall: cyrus-sasl-crammd5-2.1.19-7 cyrus-sasl-gssapi-2.1.19-7 cyrus-sasl-otp-2.1.19-7 cyrus-sasl-digestmd5-2.1.19-7 Then restart the relevant services again (saslauthd, cyrus, postfix) Sandy PS: Please reply only to the list... I do read it (^-^)
Sandy Drobic wrote: --snip--
From this list uninstall: cyrus-sasl-crammd5-2.1.19-7 cyrus-sasl-gssapi-2.1.19-7 cyrus-sasl-otp-2.1.19-7 cyrus-sasl-digestmd5-2.1.19-7
Then restart the relevant services again (saslauthd, cyrus, postfix) --snip--
Tried uninstalling all non-used authentication methods, however I'm still receiving the same errors. :-/ I have even put a 'postfix' config file in my pam.d directory (a la my running test relay), although maybe it's reading the wrong one or isn't right for suse. Here's what I've got: #%PAM-1.0 auth required pam_nologin.so auth required pam_unix2.so shadow nodelay account required pam_unix2.so session required pam_unix2.so
PS: Please reply only to the list... I do read it (^-^)
The reply only to you was due to my lack of hand-eye coordination, coupled with the fact that those stupid reply and reply all buttons are right next to each other and look so much alike, except for the color of the arrows.
Preston Kutzner wrote:
Tried uninstalling all non-used authentication methods, however I'm still receiving the same errors. :-/ I have even put a 'postfix' config file in my pam.d directory (a la my running test relay), although maybe it's reading the wrong one or isn't right for suse. Here's what I've got:
#%PAM-1.0 auth required pam_nologin.so auth required pam_unix2.so shadow nodelay account required pam_unix2.so session required pam_unix2.so
So, are you trying to verify using a sasldb file or /etc/passwd|shadow? If the latter try to set /usr/lib/sasl2/smtpd.conf: pwcheck_method: saslauthd mech_list: shadow plain login Sandy
Sandy Drobic wrote:
Preston Kutzner wrote:
Tried uninstalling all non-used authentication methods, however I'm still receiving the same errors. :-/ I have even put a 'postfix' config file in my pam.d directory (a la my running test relay), although maybe it's reading the wrong one or isn't right for suse. Here's what I've got:
#%PAM-1.0 auth required pam_nologin.so auth required pam_unix2.so shadow nodelay account required pam_unix2.so session required pam_unix2.so
So, are you trying to verify using a sasldb file or /etc/passwd|shadow? If the latter try to set
/usr/lib/sasl2/smtpd.conf: pwcheck_method: saslauthd mech_list: shadow plain login
Sandy
Same error as before, and yes I am trying to verify using pam, which should be using /etc/passwd|shadow. I tried adding in shadow to the mech_list, but no-go, same error as before. This is quite frustrating, as it's working on another, non-suse machine. -- Preston Kutzner
Preston Kutzner wrote:
So, are you trying to verify using a sasldb file or /etc/passwd|shadow? If the latter try to set
/usr/lib/sasl2/smtpd.conf: pwcheck_method: saslauthd mech_list: shadow plain login
Same error as before, and yes I am trying to verify using pam, which should be using /etc/passwd|shadow. I tried adding in shadow to the mech_list, but no-go, same error as before. This is quite frustrating, as it's working on another, non-suse machine.
I'm also starting to run out of ideas. Did you check to see if you have any unfulfilled dependencies? It might also be useful to test if saslauthd is actually used by postfix. What happens if you stop saslauthd? Last question remaining is: do you really need the ancient version of suse? Sandy
Sandy Drobic wrote:
Preston Kutzner wrote:
So, are you trying to verify using a sasldb file or /etc/passwd|shadow? If the latter try to set
/usr/lib/sasl2/smtpd.conf: pwcheck_method: saslauthd mech_list: shadow plain login
Same error as before, and yes I am trying to verify using pam, which should be using /etc/passwd|shadow. I tried adding in shadow to the mech_list, but no-go, same error as before. This is quite frustrating, as it's working on another, non-suse machine.
I'm also starting to run out of ideas. Did you check to see if you have any unfulfilled dependencies? It might also be useful to test if saslauthd is actually used by postfix. What happens if you stop saslauthd?
Last question remaining is: do you really need the ancient version of suse?
Sandy
This is the case for my 9.2 installation too... I figured it might be due to the age of the version, so I've been concurrently trying to set up the same thing on 9.2, with the same results.
Preston Kutzner wrote:
I'm also starting to run out of ideas. Did you check to see if you have any unfulfilled dependencies? It might also be useful to test if saslauthd is actually used by postfix. What happens if you stop saslauthd?
Last question remaining is: do you really need the ancient version of suse?
Sandy
This is the case for my 9.2 installation too... I figured it might be due to the age of the version, so I've been concurrently trying to set up the same thing on 9.2, with the same results.
Since it works for me with 9.2 there must be something we systematically don't notice. You might try the old pwcheck method, it might work for you and it will circumvent saslauthd. /usr/lib/sasl2/smtpd.conf pwcheck_method: pwcheck mech_list: shadow plain login Otherwise I have to confess I am out of ideas. Though I would try to set up a new user and test the system with that account. Sandy
On Sunday 27 March 2005 01:11 am, Sandy Drobic wrote:
Preston Kutzner wrote:
I'm also starting to run out of ideas. Did you check to see if you have any unfulfilled dependencies? It might also be useful to test if saslauthd is actually used by postfix. What happens if you stop saslauthd?
Last question remaining is: do you really need the ancient version of suse?
Sandy
This is the case for my 9.2 installation too... I figured it might be due to the age of the version, so I've been concurrently trying to set up the same thing on 9.2, with the same results.
Since it works for me with 9.2 there must be something we systematically don't notice. You might try the old pwcheck method, it might work for you and it will circumvent saslauthd.
/usr/lib/sasl2/smtpd.conf pwcheck_method: pwcheck mech_list: shadow plain login
Otherwise I have to confess I am out of ideas. Though I would try to set up a new user and test the system with that account.
Sandy
I have some notes I made on this while getting it to work on SuSE 8.2, if anyone wants these send me an email off list without [SLE] in the title and I'll forward them to you. -- _____________________________________ John Andersen
The Thursday 2005-03-24 at 18:48 -0600, Preston Kutzner wrote:
It might be that suse's postfix does not allow plain authentication. It's got to be encrypted, or over an encrypted connection. I don't remember if it was in 8.2 or later when they did that change.
Well, I will eventually be setting up TLS encryption for the session, but I'd like to be able to test and make sure SMTP AUTH is working first, it's more of a pain to debug problems when you have 2 variables, as opposed to just one. Having to worry about SASL *and* TLS problems at the same time (possible) is not what I would prefer.
I can not certify that this is the case, but if it is, you have no option. At some point, the developers or suse decided that plain passwords were simply not acceptable, and compiled several packages removing plain password support. If you insist, you have to recompile. I'm not sure if that happened since SuSE 8.2 or 9.0. -- Cheers, Carlos Robinson
Carlos E. R. wrote:
Well, I will eventually be setting up TLS encryption for the session, but I'd like to be able to test and make sure SMTP AUTH is working first, it's more of a pain to debug problems when you have 2 variables, as opposed to just one. Having to worry about SASL *and* TLS problems at the same time (possible) is not what I would prefer.
I can not certify that this is the case, but if it is, you have no option. At some point, the developers or suse decided that plain passwords were simply not acceptable, and compiled several packages removing plain password support. If you insist, you have to recompile.
I'm not sure if that happened since SuSE 8.2 or 9.0.
Can't remember for sure if I set up TLS first or if SASL worked before I integrated TLS. Though it won't do harm. Just put the IP address of your test client in the mynetworks in main.cf so you won't have to worry about SASL while you set up TLS. Then, when you have successfully set up TLS you can return to the task to make SASL work. If that does the trick please post the solution to the list. (^-^) Sandy
Sandy Drobic wrote:
Carlos E. R. wrote:
I can not certify that this is the case, but if it is, you have no option. At some point, the developers or suse decided that plain passwords were simply not acceptable, and compiled several packages removing plain password support. If you insist, you have to recompile.
I'm not sure if that happened since SuSE 8.2 or 9.0.
Can't remember for sure if I set up TLS first or if SASL worked before I integrated TLS. Though it won't do harm. Just put the IP address of your test client in the mynetworks in main.cf so you won't have to worry about SASL while you set up TLS. Then, when you have successfully set up TLS you can return to the task to make SASL work.
If that does the trick please post the solution to the list. (^-^)
Sandy
Well, I suppose this is a workable solution, but somewhat of a pain from an administration standpoint. I'm looking trying to set up the internal mail server the same way as the gateway server (for sending mail anyhow) so that my users don't have to change their client configurations depending on whether or not they're in the office or on the road. Unless this option will work if the client is also configured to use authentication. I guess, seeing as how I haven't set up authentication up until now, I'm not quite sure if the client software, upon connecting to a server that doesn't support authentication, will just ignore that fact and try to send without authenticating. I guess I'm just looking at this from an administration standpoint, and a "can I keep my users from 'seeing the man behind the curtain'?" standpoint.
participants (4)
-
Carlos E. R. -
John Andersen -
Preston Kutzner -
Sandy Drobic