Michael wrote: >> From: Frank.Swasey@uvm.edu >> Today at 10:51am, Michael wrote: >> > I've come across an issue where java developers using one of our LDAP > environments want to be able to do wildcard searches on non-standard LDAP > attributes. They are using a custom schema in the LDAP environment which > contains the following attributes for example. >> > retailerId:jurisdictionID: >> > They want to be able to perform the following search filter to pull all > entries with 21 as the jurisdictionID and any wildcard for the retailerID. >> > '(&(retailerId=*)(jurisdictionID=21))' works as expected but of course > this returns all objects with any retailerID. >> > They would like to narrow the search results using the filters below. Is > there something that needs to be added to the custom schema to allow this to > work like it does for the standard LDAP attributes like cn,sn,mail etc? >> > '(&(retailerId=177*)(jurisdictionID=21))' returns zero > results'(&(retailerId=*389)(jurisdictionID=21))' returns zero > results'(&(retailerId=1*389)(jurisdictionID=21))' returns zero results >> >> From your examples - I can guess. But nobody can know. >> >> How does this custom schema define retailerID? What are the matching >> rules? >> >> -- >> Frank Swasey | http://www.uvm.edu/~fcs >> Sr Systems Administrator | Always remember: You are UNIQUE, >> University of Vermont | just like everyone else. >> "I am not young enough to know everything." - Oscar Wilde (1854-1900) > > > Hi Frank. See below. > > attributetype ( 3.0.0.3 NAME 'retailerId' > DESC 'ID of the retailer a user is assigned to' > EQUALITY integerMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 > SINGLE-VALUE ) There is not SUBSTR matching rule available for LDAP syntax Integer. Depending on the attribute values you could try to use LDAP syntax Numeric String instead for which SUBSTR matching rule numericStringSubstringsMatch is available. Other solution would be to fix the client application. Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature