[SOLVED] NE Migration: SMTP AUTH Failure

[markpr]

Hi Bill,

I had not changed the mode but I *may* have prepared the new server with the mode set to HTTPS whereas my old server was set to MIXED. I tried earlier today to move the server to HTTP mode (restart, test) and then back to MIXED mode (restart,test) just in case that would help resolve any problems.. but this didn't help.

I ran the fixperms script yesterday just-in-case and no luck either. I also confirmed the libraries as below (this is from my system)

# more zimbra.ld.conf
/opt/zimbra/lib
/opt/zimbra/sleepycat/lib
/opt/zimbra/openldap/lib
/opt/zimbra/cyrus-sasl/lib

$ more /etc/redhat-release
Red Hat Enterprise Linux Server release 5 (Tikanga)

$ Linux 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

I've been going through all the config files looking for any possible config problems but everything does look good. I need a way to debug this problem.. I don't know the internals of your LDAP schama or MySQL schema in order to understand the internal interaction for SMTP AUTH to work....

thanks Mark

[markpr]

Bill,

Yes saslauthd and everything else is running.. nothing else in the logs apart from this problem. I think at this stage we need to look at the understandingthe interaction of saslauthd, postfix and ldap for SMTP AUTH within zimbra.

How does saslauthd perform the username/pass verification check? (where is it looking for this information and what could be broken here?)

How does saslauthd deliver the secret key to the client before accepting the clients credentials for authentication? Is this generated or reused from some keystore? The error about a lack of a secret key.. is that saslauthd complaining it can't find a standard key to deliver to the client????

thanks - Mark

[markpr]

Just a recap of how things look on the system:

1) SASLAUTHD sees the Zimbra authentication mechanism as being available:

$ /opt/zimbra/cyrus-sasl-2.1.22.3/sbin/saslauthd -v
saslauthd 2.1.22
authentication mechanisms: getpwent kerberos5 pam rimap shadow zimbra

2) SASLAUTHD is running with the Zimbra authentication mechanism active

zimbra 23499 1 0 09:07 ? 00:00:00 /opt/zimbra/cyrus-sasl-2.1.22.3/sbin/saslauthd -r -a zimbra

3) saslauthd configuration looks good:

$ more /opt/zimbra/cyrus-sasl-2.1.21.ZIMBRA/etc/saslauthd.conf
zimbra_url: https://mail.mydomain.com/service/soap/
zimbra_cert_file: /opt/zimbra/conf/smtpd.crt
zimbra_cert_check: off

4) postfix configuration looks good:

$ more /opt/zimbra/cyrus-sasl/lib/sasl2/smtpd.conf
#
log_level: 7
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
saslauthd_path: /opt/zimbra/cyrus-sasl/state/mux

(note that I increased the log level to 7 and uncommented the saslauthd_path but neither helped)

5) From the logs we know that postfix is accepting the SMTP AUTH request and handing this off to SASL for authentication. We can also see that SASL tries 3 authentication mechanisms (CRAM-MD5, PLAIN and LOGIN).

This is one thing that makes me believe that the postfix configuration file (smtpd.conf in #4 is not being used... increased logging doesn't help, the commented saslauthd_path and the attempt at an undocumented authentication method CRAM-MD5. I think that Zimbra is built to use a different method to configure postfix for saslauthd.... and that this smtpd.conf is a hold-over from an earlier version of Zimbra.


The help I need is to understand the "Zimbra" authentication method that is confgured for saslauthd. I can't troubleshoot too far without help on this...

What may help is also to understand where postfix is getting the smtp.conf for saslauthd so that I can turn up debugging to level 7 and see what else may be going on....

thanks

Mark

BTW here's the logs again

Oct 1 09:41:26 www postfix/smtpd[5139]: TLS connection established from unknown[x.x.x.x]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
Oct 1 09:41:26 www postfix/smtpd[5139]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Oct 1 09:41:26 www postfix/smtpd[5139]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Oct 1 09:41:26 www postfix/smtpd[5139]: warning: SASL authentication failure: no secret in database
Oct 1 09:41:26 www postfix/smtpd[5139]: warning: unknown[x.x.x.x]: SASL CRAM-MD5 authentication failed
Oct 1 09:41:26 www postfix/smtpd[5139]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Oct 1 09:41:26 www last message repeated 4 times
Oct 1 09:41:26 www postfix/smtpd[5139]: warning: SASL authentication failure: Password verification failed
Oct 1 09:41:26 www postfix/smtpd[5139]: warning: unknown[x.x.x.x]: SASL PLAIN authentication failed
Oct 1 09:41:27 www postfix/smtpd[5139]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Oct 1 09:41:27 www last message repeated 5 times
Oct 1 09:41:27 www postfix/smtpd[5139]: warning: unknown[x.x.x.x]: SASL LOGIN authentication failed
Oct 1 09:41:32 www postfix/smtpd[5139]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Oct 1 09:41:32 www last message repeated 2 times

[markpr]

This problem is resolved (thanks all)

SMTP AUTH follows this path:

postfix => hands off to cyrus-sasl => uses the SOAP TOMCAT URL => retrieves credentials data from ZIMBRA LDAP.

The problem was that postfix "master" was linking against the Operating System version of libsasl. You could see this with an ldd on /opt/zimbra/postfix/libexec/master.

The workaround was to perform this action:

cp /etc/ld.so.conf.d/zimbra.ld.conf /etc/ld.so.conf.d/azimbra.ld.conf
ldconfig /etc/ld.so.conf.d/azimbra.ld.conf

An ldd on master would then show the correct Zimbra libraries being used.

This problem occurs in RH (64bit) 5 with Zimbra 4.5.6 and 4.5.7

Mark

[mmorse]

the usual marking as [solved]