Re: GSSAPI vs GSS-SPNEGO
On Fri, 2014-12-26 at 14:53 -0600, Dan White wrote:
On 12/26/14 12:10 -0500, Brendan Kearney wrote:
>i am in the process of updating all of my systems to fedora 20 from
>fedora 16, and am using all the latest available builds for openldap,
>cyrus-sasl and mit kerberos. i have put everything together as i had on
>fedora 16, and i am finding that the sasl instance is using
>sasl/gss-spnego, and not sasl/gssapi like it did on the older version.
>
>i am not sure if i should be concerned about this, but it feels like i
>should be. i am not able to find anything that allow me to configure
>things one way or another, so i can force the use of gssapi from
>configs, it seems.
>
>can anyone point me in a direction about this, tell me if i should be
>concerned, or if you might have come across this before what i should be
>doing that i am not?
To limit the use of specific sasl mechanisms, configure a libsasl
slapd.conf file which contains a 'mech_list' option explicitly listing the
mechanisms (space separated) you wish to offer.
Consult the fedora documentation for both slapd and libsasl2 for the
location to place the slapd.conf file in.
To obtain a list of advertised mechanisms, do:
ldapsearch -LLL -x -H ldap://ldap.example.org -s "base" -b ""
supportedSASLMechanisms
You should also force your clients to use gssapi explicitly if that's your
preferred mechanism. The OpenLDAP client utilities offer a '-Y' option for
to do that.
kudos and thanks to mr. white. /etc/sasl2/slapd.conf containing
"mech_list: gssapi" did the trick.
having put this in brought to mind something i will be looking to do in
the near future, and i am now wondering if i am limiting myself in that
effort.
i want to use the "pass-through" auth mechanism with sasl, so that i
validate credentials against the kerberos database, and not have to
maintain passwords in multiple places. right now, saslauthd is
configured and if i test with my id, i get OK/Success back.
it seems i need to add PLAIN to the "mech_list" along with maybe a
couple other directives for this to be enabled. i have olcSaslSecProps
set to "noanonymous,noplain", so i am assuming i will need to remove the
"noplain".
being that this weakens a security posture (at least it looks to do so),
what can be done to mitigate the risk. i would imagine tls is one step,
but would any other steps be necessary? acls can help, too, but the
plain bind/auth would have already occurred.