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