On 12/12/17 10:28 -0500, Mark Foley wrote:
On Mon, 11 Dec 2017 15:48:50 -0600 dwhite@xxxxxxx 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.
