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

Sergei V. Kovylov serejka at gmail.com
Thu Feb 24 10:51:29 UTC 2011


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

2011/2/24 Sumit Bose <sbose at redhat.com>:
> 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
> _______________________________________________
> 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