[SSSD] user groups may not contain user's entry

Sumit Bose sbose at redhat.com
Thu Feb 24 10:46:24 UTC 2011


On Thu, Feb 24, 2011 at 12:54:44PM +0300, Sergei V. Kovylov wrote:
> 2011/2/24 Sumit Bose <sbose at redhat.com>:
> > 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
> > sssd-devel at lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/sssd-devel
> >
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list