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

Simo Sorce ssorce at redhat.com
Fri Jul 9 13:25:14 UTC 2010


On Fri, 09 Jul 2010 15:50:16 +0400
Eugene Indenbom <eindenbom at gmail.com> wrote:

> Although your point about consistency and lack of transactions is 
> completely valid, there is another kind of consistence that is still 
> obeyed by LDAP - order of writes. Let's consider the following setup:
>      - there are 2 LDAP master servers
>      - there is a HBAC rule that allows login (let's call it R)
>      - there is a host group G to which rule R applies
>      - there is a remote host B which does not belong to group A and
> to which rule R does not apply
> 
> In this setup login from host B to A is prohibited.
> 
> After that:
>      - Replication agreement between LDAP masters gets broken for
> some reason (communication problems or some other issue)
>      - On first LDAP server:
>          - Rule R is reversed, now it denies login
>          - Host B is added to group G
>          - login from B to A is still prohibited
>      - User attempts a login from host B to host A:
>          - SSSD receives host info about host B from first LDAP
> servers and finds out that it belongs to group G
>          - connection to first LDAP server goes down
>          - SSSD receives rule R from second LDAP server, but this is
> an old rule version
>          - login from B to A is allowed.
> 
> Therefore there is actually a scenario when inconsistency between 2
> LDAP masters can lead to more serious implications, then simple lack
> of transactions in LDAP.
> 
> So think it's better to be on the safe side.

This is a false scenario. Your SSSD daemon may have been connected
from the start to the second server. (Replication assures operations
are replicated in the same order they are received anyway).

If replication is broken and LDAP servers are inconsistent you can
always have issues depending to which server the client connects to.
That's not something you can successfuly deal with at the client level.

Simo.

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



More information about the sssd-devel mailing list