Kolab2 Server Troubleshooting - SASL
From Kolab wiki
The Cyrus saslauthd process uses the LDAP server data to authenticate users. So this system is somewhere in the middle between the basic user data and the client attempting to log in. In case you are uncertain why a certain user cannot login, SASL is one of the easiest checkpoints.
Contents |
Can you authenticate via sasl?
Assuming you added a user with the mail address user@mydomain.de and password mypass the following should be possible on the command line of the Kolab server:
/kolab/sbin/testsaslauthd -u user@mydomain.de -p mypass 0: OK "Success."
If this fails there is a either a problem with the sasl setup or with LDAP.
connect() : No such file or directory
Check and make sure that saslauthd is running:
service saslauthd start
0: NO "authentication failed"
Of course this could occur if you did not enter the correct password, but assuming that is not the case, you may wish to try the following:
stop the saslauthd service (service saslauthd stop), then start it in console mode:
saslauthd -d -V -a ldap
where you replace "ldap" with your preferred authentication mechanism (e.g. "getpwent", "kerberos5", "pam", "rimap", "shadow", "ldap"). Then in another console, try authenticating with testsaslauthd as shown above. If you get
0: OK "Success."
You may just need to ensure your authentication mechanism is included in SASL_AUTHMECH. Depending on your distribution, this could be found in /etc/sysconfig/saslauthd or /etc/default/saslauthd. Make sure it contains a line like:
SASL_AUTHMECH="ldap"
again, replacing ldap with your preferred mechanism. Then control-c out of the console-attached saslauthd started above, and restart saslauthd using the sysV scripts (service saslauthd start)
If this didn't help, hopefully the output on the server screen will help. If you find the problem, don't forget to contribute it here.
| Distribution specific information (This information might apply if you run Kolab natively on non-OpenPKG distributions) |
| Gentoo |
|---|
| On Gentoo you should be able to run 'testsaslauth without using a path prefix (you need to be root for this). The program resides in |
My problem persists
None of the above hints did help you to solve your problem?
Please check your options for getting support and reporting errors.
Back
Back to the troubleshooting index
