[Tickets #7694] LDAP objectclass lookups fail due to case sensitivity on objectclass match

bugs at horde.org bugs at horde.org
Mon Nov 17 13:51:37 UTC 2008


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7694
------------------------------------------------------------------------------
  Ticket             | 7694
  Created By         | mark.cave-ayland at siriusit.co.uk
  Summary            | LDAP objectclass lookups fail due to case sensitivity
                     | on objectclass match
  Queue              | Horde Groupware Webmail Edition
  Version            | 1.2
  Type               | Bug
  State              | Unconfirmed
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


mark.cave-ayland at siriusit.co.uk (2008-11-17 08:51) wrote:

Hi there,

I've just upgraded one of our customer installations from HGWE 1.1 to  
1.2, and have come across a bug releated to case-sensitivity which  
prevents users from even logging onto the new 1.2 edition.

What happens is that  _getObjectClasses() returns an associative array  
of the objectclasses related to a particular DN, and the LDAP server  
in question contains the specified objectclass but in lower-case  
rather than camel-case format. This means that the ldapsearch output  
looks something like this:


dn: uid=foo,dc=some,dc=domain
...
objectClass: kolabinetorgperson
...

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


The problem is related to this piece of code in  
lib/Horde/Kolab/Server/ldap.php within the _determineType() method:

if (!in_array('kolabInetOrgPerson', $oc)) {
...
}

It should be reasonably obvious that the reason the login fails is  
because the associative array stores the value returned from LDAP in  
lower case, while the current code is looking for the camel-case  
version. Temporarily changing the code so that it matches on  
'kolabinetorgperson', all in lower-case, allows the login to proceed  
correctly.

AFAICT objectclasses are by RFC definition aaply case-insensitive  
matching, so it may be that the simplest fix is to force all  
objectclasses for a given DN to lower case before putting them in the  
associative array, and then performing all comparisons in the code  
with lower case names. However, I am not sure whether or not this will  
have any further unexpected side-effects.


ATB,

Mark.






More information about the bugs mailing list