On 2008-09-28 at 10:10 +0200, Mirko S. wrote:
> Sep 28 09:50:33 myhost PAM-warn[9488]: function=[pam_sm_authenticate]
> service=[] terminal=[<unknown>] user=[myuser] ruser=[<unknown>]
> rhost=[<unknown>]
> Sep 28 09:50:33 myhost saslauthd[9488]: DEBUG: auth_pam:
> pam_authenticate failed: Authentication failure
> Sep 28 09:50:33 myhost saslauthd[9488]: do_auth : auth failure:
> [user=myuser] [service=] [realm=] [mech=pam] [reason=PAM auth error]
>
> I can't get any further information from this :P - Perhaps you can.
> Again, the output is independent of the username and password string I
> enter.
>
> >
> > Hopefully your OS packages testsaslauthd with saslauthd, which will let
> > you directly test that saslauthd is configured correctly.
>
> myhost:~ # testsaslauthd -u myuser -p correctpw
> 0: OK "Success."
> myhost:~ # testsaslauthd -u myuser -p wrongpw
> 0: NO "authentication failed"
>
> Sounds ok - So where is the problem?
What do you see in the auth logs when testsaslauthd reports success?
When you provide the wrong password to saslauthd, does the error message
look like the one you get from an Exim attempt to use saslauthd?
On the bright side, saslauthd sees the connection, so it's not a
permissions problem affecting the socket used to talk to it.
I see from the logs above that the "service" and "realm" are both empty.
I'm not an expert on PAM and don't use saslauthd, but don't you need a
service, so that PAM can pick the right pam.d/ service configuration
file? This won't matter for some backends but I suspect with PAM it
does; in your position, that's what I'd look at next.
Do you have an /etc/pam.d/exim, or whatever, PAM config file? If so,
use the name of that file as the third parameter to the saslauthd
expansion in Exim.
${if saslauthd{{$auth1}{$auth2}{exim}}}
(You don't need the {1}{0} from your original post, the defaults are
"true" and the empty string, which is boolean and the same thing)
-Phil
