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