user groups may not contain user's entry

[Sergei V. Kovylov]

Hi all.
I've noticed that sssd has incorrect behavior with different versions of LDAP.
The issue is because of LDB store each entry in case sensitive format,
but there's no difference for LDAP, so if we have in LDB database:

user's entry:
dn: uid=user,ou=GROUP,dc=domain
...........

and user's group entry:
dn: cn=group,OU=GROUP,dc=domain
member: uid=user,OU=GROUP,dc=domain
.....

then user "user" will never be a part of group "group" as  entries
"uid=user,ou=GROUP,dc=domain" and "uid=user,OU=GROUP,dc=domain" are
not equal(in LDB logic).
I've noticed this when had migrated from FDS v.1.2.3 to FDS v.1.2.7.5
as last one converting DN attibutes to lower case, but provide value
of "uniquemember" as is.

You will find a patch to fix this on sssd side in attach.

[Sumit Bose]

Hi,

Thank you very much for your contribution. In my experience LDB searches
with DNs are pretty much case-insensitive, only the value of the RDN is
checked case sensitive. I would like to investigate a bit further why
you see this issue in sssd.

On Wed, Feb 23, 2011 at 05:40:49PM +0300, Sergei V. Kovylov wrote:
> Hi all.
> I've noticed that sssd has incorrect behavior with different versions of LDAP.
> The issue is because of LDB store each entry in case sensitive format,
> but there's no difference for LDAP, so if we have in LDB database:
>
> user's entry:
> dn: uid=user,ou=GROUP,dc=domain
> ...........
>
> and user's group entry:
> dn: cn=group,OU=GROUP,dc=domain
> member: uid=user,OU=GROUP,dc=domain
> .....

are these entries coming from the LDB cache of sssd or from your LDAP
server. For the cache of sssd I would expect DNs like

name=user,cn=users,cn=domain,cn=sysdb and
name=group,cn=groups,cn=domain,cn=sysdb
> then user "user" will never be a part of group "group" as  entries
> "uid=user,ou=GROUP,dc=domain" and "uid=user,OU=GROUP,dc=domain" are
> not equal(in LDB logic).
> I've noticed this when had migrated from FDS v.1.2.3 to FDS v.1.2.7.5
> as last one converting DN attibutes to lower case, but provide value
> of "uniquemember" as is.

How was the 'migration' done. Did you export the data on the old server
and load them into the new one?  Did you remove the sssd cache at some
point during the migration?
> You will find a patch to fix this on sssd side in attach.

bye,
Sumit

[Sergei V. Kovylov]

2011/2/24 Sumit Bose :
> Hi,
>
> Thank you very much for your contribution. In my experience LDB searches
> with DNs are pretty much case-insensitive, only the value of the RDN is
> checked case sensitive. I would like to investigate a bit further why
> you see this issue in sssd.

Hi Sumit.
It's very interesting, as I've seen the other behavior. Which version
of LDB are you using?
Well let me describe this a little more deeply, maybe we have misunderstanding:

SSSD stores all LDAP entries correctly, so we can see:
dn: name=skovylov,cn=users,cn=DOMAIN,cn=sysdb
...
name: skovylov
....
originalDN: uid=skovylov,ou=MCC,cn=compute,dc=domain

As you may see "originalDN" contains attributes in upper case.
Next step is to store group's entry, sssd gets such reply from ldap:
dn: cn=group,ou=group,dc=domain
......
uniqueMember: uid=skovylov,OU=MCC,cn=compute,dc=domain

After that sssd is trying to find through LDB cache entry with
originalDN "uid=skovylov,OU=MCC,cn=compute,dc=domain", and not able to
find (both error messages in log file with debug and manual search
through LDB cache). After changing search string to
"uid=skovylov,ou=MCC,cn=compute,dc=domain" - it works.
> How was the 'migration' done. Did you export the data on the old server
> and load them into the new one?  Did you remove the sssd cache at some
> point during the migration?

It's still in progress as we had found this issue. But the migration
proccess is not so difficult, as we are using FDS for windows AD sync,
so it's the main storage of information and migration is to add in new
FDS winsync agreement. Also I'm exploring, maybe, another issue to
find out where  is the problem. So until I solve this issues we will
not migrate from FDS 1.2.3.
> > You will find a patch to fix this on sssd side in attach.
>
> bye,
> Sumit
> _______________________________________________
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[Sumit Bose]

On Thu, Feb 24, 2011 at 12:54:44PM +0300, Sergei V. Kovylov wrote:
> 2011/2/24 Sumit Bose :
> > Hi,
> >
> > Thank you very much for your contribution. In my experience LDB searches
> > with DNs are pretty much case-insensitive, only the value of the RDN is
> > checked case sensitive. I would like to investigate a bit further why
> > you see this issue in sssd.
>
> Hi Sumit.
> It's very interesting, as I've seen the other behavior. Which version
> of LDB are you using?
> Well let me describe this a little more deeply, maybe we have misunderstanding:
>
> SSSD stores all LDAP entries correctly, so we can see:
> dn: name=skovylov,cn=users,cn=DOMAIN,cn=sysdb
> ...
> name: skovylov
> ....
> originalDN: uid=skovylov,ou=MCC,cn=compute,dc=domain
>
> As you may see "originalDN" contains attributes in upper case.
> Next step is to store group's entry, sssd gets such reply from ldap:
> dn: cn=group,ou=group,dc=domain
> ......
> uniqueMember: uid=skovylov,OU=MCC,cn=compute,dc=domain
>
> After that sssd is trying to find through LDB cache entry with
> originalDN "uid=skovylov,OU=MCC,cn=compute,dc=domain", and not able to
> find (both error messages in log file with debug and manual search
> through LDB cache). After changing search string to
> "uid=skovylov,ou=MCC,cn=compute,dc=domain" - it works.

ah, thank you for the explanation. Please try to add to following
modification to the cache of sssd:

cat << EOF_EOF | ldbmodify -H /var/lib/sss/db/cache_YOUR_DOMAIN.ldb
dn: @ATTRIBUTES
changetype: modify
add: originalDN
originalDN: CASE_INSENSITIVE

EOF_EOF

This should make all originalDN comparisons case-insensitive. Please
tell me if this fixes your issue. If yes, I will discuss with the other
sssd developers if it makes sense to include this change to the default
installation.

bye,
Sumit
> > How was the 'migration' done. Did you export the data on the old server
> > and load them into the new one?  Did you remove the sssd cache at some
> > point during the migration?
>
> It's still in progress as we had found this issue. But the migration
> proccess is not so difficult, as we are using FDS for windows AD sync,
> so it's the main storage of information and migration is to add in new
> FDS winsync agreement. Also I'm exploring, maybe, another issue to
> find out where  is the problem. So until I solve this issues we will
> not migrate from FDS 1.2.3.
> > > You will find a patch to fix this on sssd side in attach.
> >
> > bye,
> > Sumit
> > _______________________________________________
> > sssd-devel mailing list
> > [e-mail]
> > https://fedorahosted.org/mailman/listinfo/sssd-devel
>
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[Sergei V. Kovylov]

Ok i will try.
It takes some time as I need to recompile and reconfigure test machine.

2011/2/24 Sumit Bose :
> On Thu, Feb 24, 2011 at 12:54:44PM +0300, Sergei V. Kovylov wrote:
> > 2011/2/24 Sumit Bose :
> > > Hi,
> > >
> > > Thank you very much for your contribution. In my experience LDB searches
> > > with DNs are pretty much case-insensitive, only the value of the RDN is
> > > checked case sensitive. I would like to investigate a bit further why
> > > you see this issue in sssd.
> >
> > Hi Sumit.
> > It's very interesting, as I've seen the other behavior. Which version
> > of LDB are you using?
> > Well let me describe this a little more deeply, maybe we have misunderstanding:
> >
> > SSSD stores all LDAP entries correctly, so we can see:
> > dn: name=skovylov,cn=users,cn=DOMAIN,cn=sysdb
> > ...
> > name: skovylov
> > ....
> > originalDN: uid=skovylov,ou=MCC,cn=compute,dc=domain
> >
> > As you may see "originalDN" contains attributes in upper case.
> > Next step is to store group's entry, sssd gets such reply from ldap:
> > dn: cn=group,ou=group,dc=domain
> > ......
> > uniqueMember: uid=skovylov,OU=MCC,cn=compute,dc=domain
> >
> > After that sssd is trying to find through LDB cache entry with
> > originalDN "uid=skovylov,OU=MCC,cn=compute,dc=domain", and not able to
> > find (both error messages in log file with debug and manual search
> > through LDB cache). After changing search string to
> > "uid=skovylov,ou=MCC,cn=compute,dc=domain" - it works.
>
> ah, thank you for the explanation. Please try to add to following
> modification to the cache of sssd:
>
> cat << EOF_EOF | ldbmodify -H /var/lib/sss/db/cache_YOUR_DOMAIN.ldb
> dn: @ATTRIBUTES
> changetype: modify
> add: originalDN
> originalDN: CASE_INSENSITIVE
>
> EOF_EOF
>
> This should make all originalDN comparisons case-insensitive. Please
> tell me if this fixes your issue. If yes, I will discuss with the other
> sssd developers if it makes sense to include this change to the default
> installation.
>
> bye,
> Sumit
> > > How was the 'migration' done. Did you export the data on the old server
> > > and load them into the new one?  Did you remove the sssd cache at some
> > > point during the migration?
> >
> > It's still in progress as we had found this issue. But the migration
> > proccess is not so difficult, as we are using FDS for windows AD sync,
> > so it's the main storage of information and migration is to add in new
> > FDS winsync agreement. Also I'm exploring, maybe, another issue to
> > find out where  is the problem. So until I solve this issues we will
> > not migrate from FDS 1.2.3.
> > > > You will find a patch to fix this on sssd side in attach.
> > >
> > > bye,
> > > Sumit
> > > _______________________________________________
> > > sssd-devel mailing list
> > > [e-mail]
> > > https://fedorahosted.org/mailman/listinfo/sssd-devel
> >
> > sssd-devel mailing list
> > [e-mail]
> > https://fedorahosted.org/mailman/listinfo/sssd-devel
>
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[Sergei V. Kovylov]

Sumit,  I can confirm that it working.
> ah, thank you for the explanation. Please try to add to following
> modification to the cache of sssd:
>
> cat << EOF_EOF | ldbmodify -H /var/lib/sss/db/cache_YOUR_DOMAIN.ldb
> dn: @ATTRIBUTES
> changetype: modify
> add: originalDN
> originalDN: CASE_INSENSITIVE
>
> EOF_EOF
>
> This should make all originalDN comparisons case-insensitive. Please
> tell me if this fixes your issue. If yes, I will discuss with the other
> sssd developers if it makes sense to include this change to the default
> installation.
>
> bye,
> Sumit
> > > How was the 'migration' done. Did you export the data on the old server
> > > and load them into the new one?  Did you remove the sssd cache at some
> > > point during the migration?
> >
> > It's still in progress as we had found this issue. But the migration
> > proccess is not so difficult, as we are using FDS for windows AD sync,
> > so it's the main storage of information and migration is to add in new
> > FDS winsync agreement. Also I'm exploring, maybe, another issue to
> > find out where  is the problem. So until I solve this issues we will
> > not migrate from FDS 1.2.3.
> > > > You will find a patch to fix this on sssd side in attach.
> > >
> > > bye,
> > > Sumit
> > > _______________________________________________
> > > sssd-devel mailing list
> > > [e-mail]
> > > https://fedorahosted.org/mailman/listinfo/sssd-devel
> >
> > sssd-devel mailing list
> > [e-mail]
> > https://fedorahosted.org/mailman/listinfo/sssd-devel
>
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel

[Simo Sorce]

On Thu, 24 Feb 2011 11:46:24 +0100
Sumit Bose  wrote:
> This should make all originalDN comparisons case-insensitive. Please
> tell me if this fixes your issue. If yes, I will discuss with the
> other sssd developers if it makes sense to include this change to the
> default installation.

We definitely want to add this.

Simo.

[Sumit Bose]

On Thu, Feb 24, 2011 at 08:45:19AM -0500, Simo Sorce wrote:
> On Thu, 24 Feb 2011 11:46:24 +0100
> Sumit Bose  wrote:
> > This should make all originalDN comparisons case-insensitive. Please
> > tell me if this fixes your issue. If yes, I will discuss with the
> > other sssd developers if it makes sense to include this change to the
> > default installation.
>
> We definitely want to add this.

ok, I have opened https://fedorahosted.org/sssd/ticket/808 to track
this. If you can think of other attributes please add them to this
ticket.

bye,
Sumit
> Simo.
>
> -- 
> Simo Sorce * Red Hat, Inc * New York
> _______________________________________________
> sssd-devel mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/sssd-devel