[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: GSSAPI vs GSS-SPNEGO

On Sun, 2014-12-28 at 02:50 +0000, Howard Chu wrote:
> Brendan Kearney wrote:
> > 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.
> 
> The right way to do this is to store your KDC keystore in slapd.
> 

i am doing this.  the benefits i saw were real-time replication in
conjunction with my MMR, as well as multi-master kadmin that allows
multiple/concurrent write sessions.

> > 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".
> 
> No.
> 
> If you're already using SASL/GSSAPI then there's no need to do anything 
> else. If you're talking about clients performing plaintext 
> authentication, then what you just described is irrelevant. "sasl 
> pass-through" uses LDAP Simple Bind and the {SASL} crypt scheme. The 
> SASL PLAIN mech is only used for LDAP SASL Binds, and is totally 
> irrelevant here. If your client can perform SASL Binds already then it 
> would have used GSSAPI in the first place.
> 
> > 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.
> 
> There is no valid use for SASL/PLAIN in LDAP. There is almost never any 
> valid reason to change the olcSaslSecProps config.
> 
> In the meantime, yes, if you allow LDAP Simple Binds to be authenticated 
> against Kerberos credentials, then you will need TLS otherwise your 
> Kerberos credentials will be easily compromised.
> 

ok, then i have misunderstood PLAIN vs SIMPLE, it seems.  i will back up
and explain what i am trying to do.

apache, dhcp and freeradius can all use ldap for various functionality.
they all use what i now believe to be SIMPLE auth, where they are using
"cn=user,dc=domain,dc=tld" as ldap usernames.  these processes are using
ldap for authentication, whereas i have only kerberos authentication
setup in my environment (and ldap authorization).  my hope was that sasl
could allow me to push the ldap authN request through to kerberos, and
in essence proxy the authentication.

the idea is to not have passwords stored in ldap, but have them stored
in kerberos (even though the kerberos data is housed in ldap).  am i
trying to use a screwdriver, where a wrench is needed?

thank you,

brendan