[SSSD] LDAP connection tracking, sharing and fail-over retry framework

Simo Sorce ssorce at redhat.com
Fri Jun 18 15:19:06 UTC 2010


On Fri, 18 Jun 2010 18:09:00 +0400
Eugene Indenbom <eindenbom at gmail.com> wrote:

> On 06/18/2010 06:03 PM, Simo Sorce wrote:
> > On Fri, 18 Jun 2010 16:18:05 +0400
> > Eugene Indenbom<eindenbom at gmail.com>  wrote:
> >
> >    
> >> I hope that 389-ds team would support dropping expired GSSAPI
> >> connection BEFORE changes to MIT Kerberos implementation become
> >> widely available. Otherwise it will create a substantial hole in DS
> >> security.
> >>      
> > There is really no hole, it would be identical to password
> > authentication over a SSL channel.
> >
> >    
> The problem is currently existing installations may rely on that when 
> Kerberos user gets deleted or otherwise disabled, access to Kerberos 
> domain services would closed after all Kerberos tickets expire.
> 
> After this change in MIT Kerberos, the above policy will not be
> obeyed at least until all the services will be updated to enforce the
> policy themselves.

This change has been proposed to the MIT kerberos team because most
admins and users do not expect connections to drop. As far as I know
there is no one depending on this behavior, quite the contrary.

This behavior is GSSAPI implementation dependent, Heimdal for example
never enforced it, and so other 3rd party libraries.
The RFC also does not state that GSSAPI implementations have to drop
connections.

Therefore depending on that behavior would be an error anyway because
it is not consistent (389ds uses syrus sasl so it has no control on
what is the implementation of the gssapi library used underneath).

Application always need to have their own policy for connection
termination, if that is necessary. If you rely only on the GSSAPI
mechanism you'd be uncovered when a different connection mechanism is
used.

Sorry I don't see the huge security hole, but this is not a place to
discuss it anyway, I suggest you raise the issue in the appropriate
forums if you have strong feelings about this change.

From the SSSD point of view we just need to take in account that this
behavior may not be a mojor issue anymore and decide whether we need to
spend more or less code to handle it. For now I am fine with handling
expiration of credentials and all, given this upstream change in GSSAPI
will take quite a while before we can consider it gone.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list