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.