Enabling cyrus-sasl for gssapi
Dan White
dwhite at olp.net
Tue Dec 12 10:58:46 EST 2017
On 12/12/17 10:28 -0500, Mark Foley wrote:
>On Mon, 11 Dec 2017 15:48:50 -0600 dwhite at olp.net wrote:
>> On 12/11/17 15:46 -0500, Mark Foley wrote:
>> >Despite specifying --enable-gssapi the new binary does not show gssapi as a
>> >mechanism. Why?
>>
>> --enable-gssapi= should specify a directory (./configure --help). The
>
>What directory? Where is it suppose to point to? I'm not gleaning that from your
>script usage below.
The directory should point to to where your kerberos library and headers
are installed. If you're using system packages verify you have the
appropriate '-dev' or '-devel' package installed (for heimdal or mit).
>> Check your config.log to verify. If successful, add '-a kerberos5' to your
>> saslauthd command line to enable.
>
>Would that also be the -s parameter on testsaslauthd?
No. testsaslauthd won't require any options, unless you've placed the
saslauthd mux in a non standard (-m) location. testsaslauthd will default
to a service name of 'imap', but that shouldn't matter, assuming you have
an appropriately configured /etc/krb5.conf. Without saslauthd in the mix,
your Sendmail configuration should specify where your keytab is located.
>> Note that this does not enable SASL GSSAPI authentication, but rather
>> Kerberos authentication underneath SASL PLAIN or LOGIN.
>
>So, are you having me try two different authentications? GSSAPI and Kerberos? Or
>are you saying that GSSAPI is really Kerberos? I understood that GSSAPI involves
>Kerberos, but I didn't think they were synonmyms. Your statement this does not
>enable SASL GSSAPI authentication is giving me pause.
I would personally not use saslauthd in the above manner. If you have a
controlled environment where your clients (Thunderbird) are known to
support GSSAPI negotiation over the network, then configuring Sendmail to
support GSSAPI directly is secure and recommended.
saslauthd, with the above configuration, is a crutch to support plain text
authentication over the network, with the saslauthd daemon implementing a
kerberos shim, and is insecure without TLS to protect it.
More information about the Cyrus-sasl
mailing list