Discussion:
Enabling cyrus-sasl for gssapi
Mark Foley
2017-12-11 20:46:53 UTC
Permalink
I would like to enable saslauthd for GSSAPI for sendmail authentication. I am
running Samba4 4.4.16 on Slackware64 14.2. Samaba4 includes Heimdal kerberos.
The Dovecot mail server authenticates domain users using the Thunderbird email
client via GSSAPI, so that indicates to me that it is doable. My current
saslauthd has:

$ saslauthd -v
saslauthd 2.1.26
authentication mechanisms: getpwent rimap shadow

So, I believe this means I have to build sasl from source to enable GSSAPI.

I downloaded the 2.1.26 tarball from ftp://ftp.cyrusimap.org/cyrus-sasl/. I did:

$ ./configure --enable-gssapi --with-gss_impl=heimdal
$ make
$ saslauthd/saslauthd -v
saslauthd 2.1.26
authentication mechanisms: getpwent rimap shadow

Despite specifying --enable-gssapi the new binary does not show gssapi as a
mechanism. Why?

Thanks, Mark
Dan White
2017-12-11 21:48:50 UTC
Permalink
Post by Mark Foley
I would like to enable saslauthd for GSSAPI for sendmail authentication. I am
running Samba4 4.4.16 on Slackware64 14.2. Samaba4 includes Heimdal kerberos.
The Dovecot mail server authenticates domain users using the Thunderbird email
client via GSSAPI, so that indicates to me that it is doable. My current
$ saslauthd -v
saslauthd 2.1.26
authentication mechanisms: getpwent rimap shadow
So, I believe this means I have to build sasl from source to enable GSSAPI.
$ ./configure --enable-gssapi --with-gss_impl=heimdal
$ make
$ saslauthd/saslauthd -v
saslauthd 2.1.26
authentication mechanisms: getpwent rimap shadow
Despite specifying --enable-gssapi the new binary does not show gssapi as a
mechanism. Why?
--enable-gssapi= should specify a directory (./configure --help). The
configure script uses the value like so:

if test -d ${gssapi}; then
CPPFLAGS="$CPPFLAGS -I$gssapi/include"
cmu_saved_CPPFLAGS=$CPPFLAGS
LDFLAGS="$LDFLAGS -L$gssapi/lib"

Check your config.log to verify. If successful, add '-a kerberos5' to your
saslauthd command line to enable.

Note that this does not enable SASL GSSAPI authentication, but rather
Kerberos authentication underneath SASL PLAIN or LOGIN.

Consult Sendmail documentation for enabling GSSAPI directly:

http://www.sendmail.org/~ca/email/auth.html
Quanah Gibson-Mount
2017-12-11 22:02:49 UTC
Permalink
Post by Dan White
Post by Mark Foley
I would like to enable saslauthd for GSSAPI for sendmail authentication.
I am running Samba4 4.4.16 on Slackware64 14.2. Samaba4 includes
Heimdal kerberos. The Dovecot mail server authenticates domain users
using the Thunderbird email client via GSSAPI, so that indicates to me
Note that this does not enable SASL GSSAPI authentication, but rather
Kerberos authentication underneath SASL PLAIN or LOGIN.
I would also note that if using a distribution provided SASL build, all
that may be necessary to allow SASL/GSSAPI to function is to install the
appropriate module. For example, on Debian/Ubuntu, you have a choice of
MIT backed Kerberos or Heimdal backed Kerberos:

libsasl2-modules-gssapi-heimdal
libsasl2-modules-gssapi-mit

I believe RedHat has something similar. I personally always chose Heimdal
as the Kerberos library on the client side to back SASL/GSSAPI due to
benchmarks I did, but that was 3 jobs and over a decade ago. ;)

Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Dan White
2017-12-12 15:58:46 UTC
Permalink
Post by Dan White
Post by Mark Foley
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).
Post by Dan White
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.
Post by Dan White
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.
Mark Foley
2017-12-15 17:21:42 UTC
Permalink
It then goes on to discuss downloading cyrus-sasl, verifying SASL is configured
in Sendmail (mine is), etc.. Are you suggesting that SASL and saslauthd are
separate things and that I can use one (SASL) without the other (saslauthd)?
saslauthd is part of Cyrus SASL, but Cyrus SASL does not require running
saslauthd, and saslauthd cannot be used to perform direct SASL GSSAPI for
server authentication.
https://www.cyrusimap.org/sasl/
Dan - thanks for your response.

Yes, that's the exact page I've been consulting.

This site: http://www.linuxfromscratch.org/blfs/view/svn/postlfs/cyrus-sasl.html
further advises downloading and applying *REQUIRED* patches:

cyrus-sasl-2.1.26-fixes-3.patch
cyrus-sasl-2.1.26-openssl-1.1.0-1.patch

Do you agree?

The first listed patch is described as, "various package fixes, including
autotools fixes, plugin fixes, security fixes, parallel build fixes, etc.", and
was created Aug-24-2014.

The 2nd patch has no description, but patches
cyrus-sasl-2.1.26-orig/plugins/ntlm.c and is dated May-07-2017 It applies to
openssl 1.1.0 whereas I have 1.0.2k (although it's patching plugin/ntlm.c, not
openssl, so I'm not sure my openssl version matters).
I would personally not use saslauthd in the above manner [authenticating with
sendmail]. 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.
The "configuring Sendmail to support GSSAPI directly" is the bit that got my
attention. To clarify, in order to do Sendmail and GSSAPI directly I *do* need
SASL, but *do not* need saslauthd, right?

Thanks, Mark
Dan White
2017-12-15 17:36:33 UTC
Permalink
Post by Mark Foley
Yes, that's the exact page I've been consulting.
This site: http://www.linuxfromscratch.org/blfs/view/svn/postlfs/cyrus-sasl.html
cyrus-sasl-2.1.26-fixes-3.patch
cyrus-sasl-2.1.26-openssl-1.1.0-1.patch
I haven't reviewed the patches, but it's probably a good idea to used them,
unless you're using a 2.1.27 prerelease, or you could download the
source+patches for your base system (e.g. Debian or Redhat).
Post by Mark Foley
I would personally not use saslauthd in the above manner [authenticating with
sendmail]. 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.
The "configuring Sendmail to support GSSAPI directly" is the bit that got my
attention. To clarify, in order to do Sendmail and GSSAPI directly I *do* need
SASL, but *do not* need saslauthd, right?
Yes, that's correct. You'd configure Sendmail to use the GSSAPI
authentication plugin, but not PLAIN or LOGIN, which would make saslauthd
irrelevant.
Mark Foley
2017-12-17 00:07:47 UTC
Permalink
Post by Dan White
Post by Mark Foley
I would personally not use saslauthd in the above manner [authenticating with
sendmail]. 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.
The "configuring Sendmail to support GSSAPI directly" is the bit that got my
attention. To clarify, in order to do Sendmail and GSSAPI directly I *do* need
SASL, but *do not* need saslauthd, right?
Yes, that's correct. You'd configure Sendmail to use the GSSAPI
authentication plugin, but not PLAIN or LOGIN, which would make saslauthd
irrelevant.
But, I do need SASL for Sendmail, right? Just not saslauthd?

Also, you mentioned in a previous email that to build sasl, in my ./configure, I
need:

./configure --enable-gssapi=<DIR>
Post by Dan White
The directory should point to to where your kerberos library and headers
are installed.
First of all, how did you know that's what "<DIR>" means? I couldn't find
anything about that on the website, in the installation instructions or in the
doc/ files, or by searching the web.

Other than that, I have libraries from the Samba4 installation in:

/usr/lib64/libkrb5samba-samba4.so
/usr/lib64/libheimntlm-samba4.so.1.0.1
/usr/lib64/python2.7/site-packages/samba/dcerpc/krb5pac.so
/usr/lib64/libndr-krb5pac.so.0.0.1
/usr/lib64/winbind_krb5_locator.so
/usr/lib64/gensec/krb5.so
/usr/lib64/libauthkrb5-samba4.so
/usr/lib64/libkrb5-samba4.so.26.0.0
/usr/lib64/libheimbase-samba4.so.1.0.0

And Kerberos related Samaba4 header files in:

/usr/include/openssl/krb5_asn.h
/usr/include/c++/5.3.0/javax/security/auth/kerberos/KerberosPrincipal.h
/usr/include/c++/5.3.0/javax/security/auth/kerberos/KerberosTicket.h
/usr/include/c++/5.3.0/javax/security/auth/kerberos/KerberosKey.h
/usr/include/samba-4.0/gen_ndr/ndr_krb5pac.h
/usr/include/samba-4.0/gen_ndr/krb5pac.h
/usr/local/include/gssapi/gssapi_krb5.h
/usr/local/include/krb5/krb5.h
/usr/local/include/krb5.h

I've also just installed Heimdal Kerberos. Libraries are in:

/usr/heimdal/lib/libheimbase.so.1.0.0
/usr/heimdal/lib/libheimedit.so.0.0.36
/usr/heimdal/lib/libkrb5.so.26.0.0
/usr/heimdal/lib/libheimsqlite.so.0.0.0
/usr/heimdal/lib/libheimntlm.so.0.1.0

and these newly installed header files are in:

/usr/heimdal/include/heimbase.h
/usr/heimdal/include/krb5-types.h
/usr/heimdal/include/krb5-protos.h
/usr/heimdal/include/krb5_asn1.h
/usr/heimdal/include/krb5_ccapi.h
/usr/heimdal/include/heim_err.h
/usr/heimdal/include/heimntlm-protos.h
/usr/heimdal/include/heimntlm.h
/usr/heimdal/include/gssapi/gkrb5_err.h
/usr/heimdal/include/gssapi/gssapi_krb5.h
/usr/heimdal/include/heim-ipc.h
/usr/heimdal/include/krb5_err.h
/usr/heimdal/include/heim_asn1.h
/usr/heimdal/include/krb5.h

I'd like to try using the Heimdal that came with Samba4. I can point the library
DIR to /usr/lib64, but what about the headers? Do the Samba4/Heimdal headers
look like what I need for the build?

If that's not going to work, I'll try building against the new Heimdal install.
In this case, what would my =<DIR> be? /usr/heimdal ?

THX --Mark
Edgar Pettijohn
2017-12-17 00:30:57 UTC
Permalink
Post by Mark Foley
Post by Dan White
Post by Mark Foley
I would personally not use saslauthd in the above manner [authenticating with
sendmail]. 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.
The "configuring Sendmail to support GSSAPI directly" is the bit that got my
attention. To clarify, in order to do Sendmail and GSSAPI directly I *do* need
SASL, but *do not* need saslauthd, right?
Yes, that's correct. You'd configure Sendmail to use the GSSAPI
authentication plugin, but not PLAIN or LOGIN, which would make saslauthd
irrelevant.
But, I do need SASL for Sendmail, right? Just not saslauthd?
Also, you mentioned in a previous email that to build sasl, in my ./configure, I
./configure --enable-gssapi=<DIR>
./configure --help
Post by Mark Foley
Post by Dan White
The directory should point to to where your kerberos library and headers
are installed.
First of all, how did you know that's what "<DIR>" means? I couldn't find
anything about that on the website, in the installation instructions or in the
doc/ files, or by searching the web.
/usr/lib64/libkrb5samba-samba4.so
/usr/lib64/libheimntlm-samba4.so.1.0.1
/usr/lib64/python2.7/site-packages/samba/dcerpc/krb5pac.so
/usr/lib64/libndr-krb5pac.so.0.0.1
/usr/lib64/winbind_krb5_locator.so
/usr/lib64/gensec/krb5.so
/usr/lib64/libauthkrb5-samba4.so
/usr/lib64/libkrb5-samba4.so.26.0.0
/usr/lib64/libheimbase-samba4.so.1.0.0
/usr/include/openssl/krb5_asn.h
/usr/include/c++/5.3.0/javax/security/auth/kerberos/KerberosPrincipal.h
/usr/include/c++/5.3.0/javax/security/auth/kerberos/KerberosTicket.h
/usr/include/c++/5.3.0/javax/security/auth/kerberos/KerberosKey.h
/usr/include/samba-4.0/gen_ndr/ndr_krb5pac.h
/usr/include/samba-4.0/gen_ndr/krb5pac.h
/usr/local/include/gssapi/gssapi_krb5.h
/usr/local/include/krb5/krb5.h
/usr/local/include/krb5.h
./configure --enable-gssapi=/usr/heimdal/lib --with-gss_impl=heimdal
Post by Mark Foley
/usr/heimdal/lib/libheimbase.so.1.0.0
/usr/heimdal/lib/libheimedit.so.0.0.36
/usr/heimdal/lib/libkrb5.so.26.0.0
/usr/heimdal/lib/libheimsqlite.so.0.0.0
/usr/heimdal/lib/libheimntlm.so.0.1.0
/usr/heimdal/include/heimbase.h
/usr/heimdal/include/krb5-types.h
/usr/heimdal/include/krb5-protos.h
/usr/heimdal/include/krb5_asn1.h
/usr/heimdal/include/krb5_ccapi.h
/usr/heimdal/include/heim_err.h
/usr/heimdal/include/heimntlm-protos.h
/usr/heimdal/include/heimntlm.h
/usr/heimdal/include/gssapi/gkrb5_err.h
/usr/heimdal/include/gssapi/gssapi_krb5.h
/usr/heimdal/include/heim-ipc.h
/usr/heimdal/include/krb5_err.h
/usr/heimdal/include/heim_asn1.h
/usr/heimdal/include/krb5.h
I'd like to try using the Heimdal that came with Samba4. I can point the library
DIR to /usr/lib64, but what about the headers? Do the Samba4/Heimdal headers
look like what I need for the build?
If that's not going to work, I'll try building against the new Heimdal install.
In this case, what would my =<DIR> be? /usr/heimdal ?
THX --Mark
Edgar Pettijohn
2017-12-16 14:42:26 UTC
Permalink
It then goes on to discuss downloading cyrus-sasl, verifying SASL is configured
in Sendmail (mine is), etc.. Are you suggesting that SASL and saslauthd are
separate things and that I can use one (SASL) without the other (saslauthd)?
Sorry, I'm coming in to the conversation late and I think I missed the
first message. I was just checking out the source for Slackware and it
didn't look to me like `sendmail' is being built with sasl support at
least not looking at the site.config.m4 provided with the distro. Take a
look at:

http://www.sendmail.org/~ca/email/auth.html

https://dfw.mirror.rackspace.com/slackware/slackware64-current/source/n/libmilter/site.config.m4
APPENDDEF(`conf_libmilter_ENVDEF',`-DNETINET6=1')
APPENDDEF(`conf_libmilter_ENVDEF',`-D_FFR_WORKERS_POOL=1 -DMIN_WORKERS=4')
APPENDDEF(`conf_libmilter_ENVDEF',`-DSM_CONF_POLL=1')
APPENDDEF(`conf_libmilter_ENVDEF', `-DMILTER')
APPENDDEF(`conf_libmilter_ENVDEF', `-D_FFR_MILTER_ROOT_UNSAFE ')
APPENDDEF(`confLIBDIR', `/usr/***@LIBDIRSUFFIX@ ')

Here is the site.config.m4 stuff from the SlackBuild
devtools/Site/site.config.m4
$ grep SASL devtools/Site/site.config.m4.sample
$

I'm not sure why one would include cyrus-sasl and not implement it with
sendmail. My only guess would be since you have the option at install
time not to install cyrus-sasl they don't want it to break the install
of sendmail perhaps.

On the plus side it looks like cyrus-sasl enables `gssapi' by default in
the configure script. However, you may want to add a line to the cyrus
slackbuild to choose your preferred gssapi mech.

--with-gss_impl={heimdal|mit|cybersafe|seam|auto}

The default is auto and without going further down the rabbit hole I
don't know what auto would be on Slack and it may not be what you want.
saslauthd is part of Cyrus SASL, but Cyrus SASL does not require running
saslauthd, and saslauthd cannot be used to perform direct SASL GSSAPI for
server authentication.
https://www.cyrusimap.org/sasl/
Dan - thanks for your response.
Yes, that's the exact page I've been consulting.
This site: http://www.linuxfromscratch.org/blfs/view/svn/postlfs/cyrus-sasl.html
cyrus-sasl-2.1.26-fixes-3.patch
cyrus-sasl-2.1.26-openssl-1.1.0-1.patch
Do you agree?
The first listed patch is described as, "various package fixes, including
autotools fixes, plugin fixes, security fixes, parallel build fixes, etc.", and
was created Aug-24-2014.
The 2nd patch has no description, but patches
cyrus-sasl-2.1.26-orig/plugins/ntlm.c and is dated May-07-2017 It applies to
openssl 1.1.0 whereas I have 1.0.2k (although it's patching plugin/ntlm.c, not
openssl, so I'm not sure my openssl version matters).
I would personally not use saslauthd in the above manner [authenticating with
sendmail]. 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.
The "configuring Sendmail to support GSSAPI directly" is the bit that got my
attention. To clarify, in order to do Sendmail and GSSAPI directly I *do* need
SASL, but *do not* need saslauthd, right?
Thanks, Mark
Edgar Pettijohn
2017-12-20 04:30:47 UTC
Permalink
Post by Edgar Pettijohn
It then goes on to discuss downloading cyrus-sasl, verifying SASL is configured
in Sendmail (mine is), etc.. Are you suggesting that SASL and saslauthd are
separate things and that I can use one (SASL) without the other (saslauthd)?
Sorry, I'm coming in to the conversation late and I think I missed the
first message. I was just checking out the source for Slackware and it
didn't look to me like `sendmail' is being built with sasl support at
least not looking at the site.config.m4 provided with the distro. Take a
http://www.sendmail.org/~ca/email/auth.html
https://dfw.mirror.rackspace.com/slackware/slackware64-current/source/n/libmilter/site.config.m4
APPENDDEF(`conf_libmilter_ENVDEF',`-DNETINET6=1')
APPENDDEF(`conf_libmilter_ENVDEF',`-D_FFR_WORKERS_POOL=1 -DMIN_WORKERS=4')
APPENDDEF(`conf_libmilter_ENVDEF',`-DSM_CONF_POLL=1')
APPENDDEF(`conf_libmilter_ENVDEF', `-DMILTER')
APPENDDEF(`conf_libmilter_ENVDEF', `-D_FFR_MILTER_ROOT_UNSAFE ')
Here is the site.config.m4 stuff from the SlackBuild
devtools/Site/site.config.m4
$ grep SASL devtools/Site/site.config.m4.sample
$
I'm not sure why one would include cyrus-sasl and not implement it with
sendmail. My only guess would be since you have the option at install
time not to install cyrus-sasl they don't want it to break the install
of sendmail perhaps.
On the plus side it looks like cyrus-sasl enables `gssapi' by default in
the configure script. However, you may want to add a line to the cyrus
slackbuild to choose your preferred gssapi mech.
--with-gss_impl={heimdal|mit|cybersafe|seam|auto}
The default is auto and without going further down the rabbit hole I
don't know what auto would be on Slack and it may not be what you want.
saslauthd is part of Cyrus SASL, but Cyrus SASL does not require running
saslauthd, and saslauthd cannot be used to perform direct SASL GSSAPI for
server authentication.
https://www.cyrusimap.org/sasl/
Dan - thanks for your response.
Yes, that's the exact page I've been consulting.
This site: http://www.linuxfromscratch.org/blfs/view/svn/postlfs/cyrus-sasl.html
cyrus-sasl-2.1.26-fixes-3.patch
cyrus-sasl-2.1.26-openssl-1.1.0-1.patch
Do you agree?
The first listed patch is described as, "various package fixes, including
autotools fixes, plugin fixes, security fixes, parallel build fixes, etc.", and
was created Aug-24-2014.
The 2nd patch has no description, but patches
cyrus-sasl-2.1.26-orig/plugins/ntlm.c and is dated May-07-2017 It applies to
openssl 1.1.0 whereas I have 1.0.2k (although it's patching plugin/ntlm.c, not
openssl, so I'm not sure my openssl version matters).
I would personally not use saslauthd in the above manner [authenticating with
sendmail]. 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.
The "configuring Sendmail to support GSSAPI directly" is the bit that got my
attention. To clarify, in order to do Sendmail and GSSAPI directly I *do* need
SASL, but *do not* need saslauthd, right?
Thanks, Mark
Disregard most of what I said. I installed slackware as a qemu guest
which was more difficult than expected. Most linux guests networking
works out of the box. I had to set up a dhcp server and use a tap and
bridge to get it working. Here are the steps to get it going.

1. install your preferred kerberos. I chose heimdal for this.
http://slackbuilds.org/repository/14.2/network/heimdal/

2. download the slackware official cyrus-sasl build stuff and remember
you need all of the files.
https://dfw.mirror.rackspace.com/slackware/slackware64-14.2/source/n/cyrus-sasl/

3. edit the build script
$ diff -u cyrus-sasl.SlackBuild.orig cyrus-sasl.SlackBuild
--- cyrus-sasl.SlackBuild.orig Tue Dec 19 22:16:18 2017
+++ cyrus-sasl.SlackBuild Tue Dec 19 22:17:42 2017
@@ -80,6 +80,8 @@
--disable-anon \
--without-ldap \
--with-saslauthd \
+ --enable-gssapi \
+ --with-gss_impl=heimdal \
--with-gdbm \
--with-dblib=gdbm
# How stupid that I need to specify 'sasldir' again for 'make' or else you get

4. rebuild cyrus sasl and install it
# ./cyrus-sasl.Slackbuild
# installpkg /tmp/cyrus...

5. download the slackware official sendmail build stuff
https://dfw.mirror.rackspace.com/slackware/slackware64-14.2/source/n/sendmail/
rebuild it so it picks up the new sasl and install it

6. cd /usr/share/sendmail/cf/cf
edit sendmail-slackware-tls-sasl.mc and add GSSAPI to the
confAUTH_MECHANISMS as well as the TRUST_AUTH_MECHANISMS and perhaps
make other changes as needed.

7. ./Build sendmail-slackware-tls-sasl.mc
cp sendmail-slackware-tls-sasl.cf /etc/mail && cd /etc/mail
cp sendmail.cf sendmail.cf.orig
cp sendmail-slackware-tls-sasl.cf sendmail.cf
/etc/rc.d/rc.sendmail restart
telnet localhost 25
ehlo test.org

and you should see GSSAPI listed next to AUTH

Loading...