Howard Chu wrote:

Matteo Perego wrote:

...

Hi, I know that openldap usage behaviour is case insensitive.

False. OpenLDAP conforms to the schema. If an attribute is defined to be case-insensitive in the schema, then it will be treated as such. If it is defined to be case-sensitive, that will also be done.

...

In my case a client use ldap attribute values in a case sensitive way.

Your client should use attributes that are actually defined as case sensitive then. Fix your schema or fix your clients.

The case-sensitive vs. case-insensitive discussions are often very misleading: In general one has to distinguish matching/comparing (when searching) from storing (add/modify/modrdn).

For the original poster:

Even if the attribute type description declares case-insensitive matching rules for matching/comparing OpenLDAP always behaves case-preserving when storing attribute values. Actually this is a good thing: You can correct "matteo" to "Matteo" even though both will result in the same match during searching.

In case of DNs matching is a bit more complex. The matching is done component by component as defined here:

http://tools.ietf.org/html/rfc4517#section-4.2.15

LDAP applications have to be prepared to handle case-sensitive vs. case-sensitive matching but should also support case-preserving when sending data. Furthermore applications should handle DNs as opaque and avoid matching them at the client-side if not capable to do it fully right with complete schema knowledge.

To Howard:

If I understand the original posting correctly in this particular case slapo-memberof uses the DN value of the modify request instead of the DN value of the real entry in the database as attribute value for 'memberOf'.

Indeed this raises an interesting question regarding *which* case to preserve when storing the 'memberOf' attribute value. It's not necessarily right to take it from the modify request because values in 'memberOf' and the real DN can differ.

Ciao, Michael.