What steps will reproduce the problem? 1. read the doc https://prosody.im/doc/cyrus_sasl What is the expected output? What do you see instead? A bit more doc What version of the product are you using? On what operating system? 0.9.12 on Ubuntu 16.04 Please provide any additional information below. When using the GSSAPI authentication method: * on the Kerberos KDC server, create a principal "xmpp/host_fqdn@EXAMPLE.COM" (host_fqdn must be the reverse DNS of your XMPP server, not its virtualhost name) * create a keytab with "xmpp/host_fqdn@EXAMPLE.COM" in, say, /etc/prosody/im.example.com.keytab that is readable only by prosody * in /etc/prosody/prosody.cfg.lua : set cyrus_service_realm to im.example.com and cyrus_server_fqdn to host_fqdn (the reverse DNS of your XMPP server) * in /etc/sasl/prosody.conf or /etc/sasl2/prosody.conf (more exactly, /etc/sasl/$cyrus_service_name.conf), put: pwcheck_method: saslauthd mech_list: GSSAPI keytab: /etc/prosody/im.example.com.keytab * its location does not seem to depend on the distribution (even in Ubuntu, for example, Prosody searches for both /etc/sasl/prosody.conf and /etc/sasl2/prosody.conf).

Hi Matthieu, Thanks for the report to improve our documentation. Nobody on the Prosody has deployment experience with Cyrus SASL. Prosody's code largely just reuses Cyrus SASL for everything. For example, when you say "Prosody searches for both /etc/sasl/prosody.conf and /etc/sasl2/prosody.conf" it is actually Cyrus SASL doing this searching, not our code. It seems like you have some knowledge on the subject however! If you are willing to share, we'd gladly accept changes. The source file for this page is simple Markdown and you can find it here: https://hg.prosody.im/site/file/tip/doc/cyrus_sasl.md If you're unfamiliar with Mercurial and patches, that is no problem - you can just send a new copy of the file.

• tags Component-Docs
• title SASL GSSAPI doc Documentation improvements for Cyrus SASL GSSAPI

Correction in Matthieu's information about /etc/sasl{,2}/*.conf filename: per Prosody's own documentation for Cyrus SASL: - cyrus_service_name: xmpp: The service name to pass to Cyrus SASL. - cyrus_application_name: prosody: The application name to pass to Cyrus SASL. Determines the Cyrus SASL configuration file name. Based on these defaults, /etc/sasl{,2}/prosody.conf will be referenced. This matches my experience. cyrus_service_name will be relevant to Cyrus SASL library if PAM is used by saslauthd. Reading util/sasl_cyrus.lua, I can see that cyrus_application_name will be preferred, but cyrus_service_name will be used if otherwise not specified. However, cyrus_application_name turns out to be a *global* setting rather than local, and first load of the module that specifies it wins! There's an unfortunate bug where util/sasl_cyrus.lua allows pcall(cyrussasl.server_init, service_name); to be invoked only once for all instances of the mod_auth_cyrus module -- but this seems not fixable, as sasl_server_init() can only be invoked once per process (at least until sasl_server_done() is called). This means that cyrus_application_name cannot be different between hosts! How about cyrus_sasl.md is updated to mention this? Why is it important? It has a side effect that I cannot specify the following by using different: - personal host: use saslauthd+LDAP because JID/email username is different than the general login username (specified with /etc/sasl/prosody.personal.conf) - friends+services host: use saslauthd+GSSAPI because friends and services get the same username for general login, and services could use a bit of kerberos I don't know how slow/leaky would it be to constantly perform sasl_server_init() + sasl_server_done(), once per login; is it worth opening a new non-documentation bug for this?