Ok i will try.
It takes some time as I need to recompile and reconfigure test machine.
2011/2/24 Sumit Bose <sbose(a)redhat.com>:
On Thu, Feb 24, 2011 at 12:54:44PM +0300, Sergei V. Kovylov wrote:
> 2011/2/24 Sumit Bose <sbose(a)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(a)lists.fedorahosted.org
> >
https://fedorahosted.org/mailman/listinfo/sssd-devel
> >
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/sssd-devel
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel