Michael Ströder wrote:
If there is no matching rule, it just goes by the most appropriate internal matching rule that corresponds to the SYNTAX.Mike C wrote:Object o = ctx.lookup("memberUid=steves,ou=People");Attribute 'memberUid' was never meant to be used within a user entry.So general advice is to define a better schema and sanitize your data. You probably already know that. ;-)I've even tried changing the definition of memberUid in config/schema/10rfc2307.ldif to use attributeTypes: ( 1.3.6.1.1.1.1.12 NAME 'memberUid' DESC 'Standard LDAP attribute type' EQUALITY caseExactIA5Match SUBSTRINGS caseExactIA5SubstringsMatch SYNTAX 'IA5String' ) Ideas?Well, looking at the schema in FDS there's no such matching rule named 'caseExactIA5Match' (IMO the server shouldn't even start with such a mis-defined schema element declaration). The only caseExact* matching rules listed in the subschema are 'caseExactOrderingMatch-en' and 'caseExactSubstringMatch-en' which both does not look suitable to me.Strange enough there's not even an EQUALITY matching rule defined for attribute type 'memberUid' at all...I really wonder whether default matching rules are applied for certain LDAP syntaxes and how to find out which these are.
Ciao, Michael. -- Fedora-directory-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-directory-users
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-directory-users
