No, in all logs we just see the localhost IP:
This is the bug!2014-02-07 14:21:12,804 WARN [qtp1097575009-258848:http://127.0.0.1:80/service/soap/AuthRequest] [email@example.com;oip=10.40.1.80;ua=zclient/8.0.6_GA_5922;] security - cmd=Auth; firstname.lastname@example.org; protocol=soap; error=authentication failed for [sic], LDAP error: - unable to ldap authenticate: invalid credentials;
I once had also one of this problem too,
in my case some user using mobile client (either Blackberry,Iphone,etc) but yours maybe different .For blackberry log indicate using blackberry IP, for iphone and others the IP appear in the log is localhost or 127.0.0.1.
In my case the user always complaining about his user account always been locked, this happen because he already change the password but forget to update in the mobile, ask the user if he/she using mobile client and try to update the password
sorry for my English
Hope that's help
This happened to me yesterday. The solution is to look in /var/log/zimbra.log, and check the log entries surrounding the 'authentication failed' line. An example from my server:
Feb 9 11:39:30 mx postfix/submission/smtpd: warning: hostname null.null.null does not resolve to address 220.127.116.11: Name or service not known
Feb 9 11:39:30 mx postfix/submission/smtpd: connect from unknown[18.104.22.168]
Feb 9 11:39:30 mx postfix/submission/smtpd: Anonymous TLS connection established from unknown[22.214.171.124]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
Feb 9 11:39:30 mx saslauthd: zmauth: authenticating against elected url 'https://mx.srkconsulting.com:7071/service/admin/soap/' ...
Feb 9 11:39:30 mx saslauthd: zmpost: url='https://mx.srkconsulting.com:7071/service/admin/soap/' returned buffer->data='<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Header><context xmlns="urn:zimbra"/></soap:Header><soap:Body><soap:Fault><soap:Code><soa p:Value>soap:Sender</soap:Value></soap:Code><soap:Reason><soap:Text>authentication failed for [email@example.com]</soap:Text></soap:Reason><soapetail><Error xmlns="urn:zimbra"><Code>account.AUTH_FAILED</Code><Trace>qtp514441508-358:https://126.96.36.199:7071/service/admin/soap/:1391963970915:d51d86aacf37f824</Trace></Error></soapetail></soap:Fault></soap:Body></soap:Envelope>', hti->error=''
Feb 9 11:39:30 mx saslauthd: auth_zimbra: firstname.lastname@example.org auth failed: authentication failed for [email@example.com]
Feb 9 11:39:30 mx saslauthd: do_auth : auth failure: [firstname.lastname@example.org] [service=smtp] [realm=srkconsulting.com] [mech=zimbra] [reason=Unknown]
Feb 9 11:39:30 mx postfix/submission/smtpd: warning: unknown[188.8.131.52]: SASL LOGIN authentication failed: authentication failure
Feb 9 11:39:31 mx postfix/submission/smtpd: lost connection after RSET from unknown[184.108.40.206]
Feb 9 11:39:31 mx postfix/submission/smtpd: disconnect from unknown[220.127.116.11]
The offending IP address was 18.104.22.168. It was trying to guess username/password once/minute, had been running 1.5 days before it happened on a valid username and got that account locked.
If you have a very busy server you might have more than one 'connect from' entry at the same time as the 'authentication failed'. In that case, note the 'connect' IPs, then find another 'authentication failed' entry and check the 'connect' IPs around it for a match.
My solution was to block that IP address with iptables.