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

Eugene Indenbom eindenbom at gmail.com
Fri Jun 18 12:18:05 UTC 2010


On 06/17/2010 05:04 PM, Simo Sorce wrote:
> On Thu, 17 Jun 2010 16:39:44 +0400
> Eugene Indenbom<eindenbom at gmail.com>  wrote:
>
>    
>> On 06/16/2010 06:47 PM, Simo Sorce wrote:
>>      
>>> On Wed, 16 Jun 2010 10:43:08 +0400
>>> Eugene Indenbom<eindenbom at gmail.com>   wrote:
>>>
>>>
>>>        
>>>> 0001-GSSAPI-ticket-expiry-time-is-returned-from-ldap_chil.patch
>>>>            A small utility patch saving GSSAPI ticket expiry time in
>>>> sdap_handle for future use.
>>>>
>>>>          
>>> Just an FYI, in a recent meeting with the MIT krb5 folks, it was
>>> finally decided to stop breaking GSSAPI sealed connections when the
>>> original ticket expires. (Heimdal never did that either).
>>>
>>>        
>> That sounds really strange for me. Although it is OK to keep the
>> connection on CLIENT side after ticket expiration, the connection
>> should be broken on the SERVER side as permission to use the SERVICE
>> granted by kerberos TGS is expired and ticket must be renewed before
>> the SERVICE is resumed.
>>      
> This is a very long discussion, and the server or even the client app
> is entitle to do the check and kill the connection if it is wished.
>
> But ticket expiration does not mean that the peer does not have anymore
> access to the service. Whether killing the connection is appropriate or
> not is a decision the application (both client and server side) should
> make and not something the library should enforce regardless.
>
> That's why the change is being done.
>
>    
The situation is still unclear: as far as I remember, Cyrrus SASL do not 
allow to access GSSAPI credentials. So how server applications are 
supposed to handle ticket expiration?

Another thing: as LDAP server definitely should break the connection 
after GSSAPI ticket expires, the cached LDAP connection should be 
dropped by SSSD regardless of changes made to MIT Kerberos.

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.



More information about the sssd-devel mailing list