dn: cn=userone,ou=Users,dc=corp,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: user
cn: User One
sn: One
mail: hari@gmail.com
objectCategory: person
userAccountControl: 514
I have attached the schema i'm using.
Server:
public class InMemoryTestLdapDirectoryServer {
dn: cn=userone,ou=Users,dc=corp,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: user
cn: User One
sn: One
mail: hari@gmail.com
objectCategory: person
userAccountControl: 514
The LDAP SDK does not currently support client-side evaluation for search filters with either approximate-match or extensible-match components, and this includes the in-memory directory server.
If you try to use the Filter.matchesEntry method with such a filter, the LDAP SDK will throw an exception. The in-memory directory server uses this method behind the scenes to identify matching entries when processing a search operation, but it swallows any errors encountered while evaluating a filter against an entry. Previously, this would have resulted in the search simply not returning any entries. However, I have just committed a change that updates the in-memory directory server so that it will reject any search request that contains a filter with an approximate-match or extensible-match filter component. Sorry for the inconvenience.
By the way, even if the LDAP SDK did support client-side evaluation for these types of filters, it doesn’t currently support the matching rule that you’re trying to use. And because a matching rule requires logic to perform its processing, it’s not sufficient to simply add the OID to the schema. You would also have to have written code to implement the necessary logic.
We can consider updating the in-memory directory server to add limited support for extensible matching, but it’s probably never going to provide full support for this capability. It’s also unlikely that we’ll add client-side support for approximate-match filters.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using unboundid-ldapsdk 4.0.9 as an inmemory server for integration testing.
I am using the below systax to retrive all inactive user accounts:
This brings zero results.
But other filters works well!
Enty in ldif file:
dn: cn=userone,ou=Users,dc=corp,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: user
cn: User One
sn: One
mail: hari@gmail.com
objectCategory: person
userAccountControl: 514
I have attached the schema i'm using.
Server:
public class InMemoryTestLdapDirectoryServer {
}
Can someone help me to findout the issue.
Thank you!
Last edit: Hari Tummala 2019-01-18
Did you check if your "inmemory server" supports "1.2.840.113556.1.4.803
https://ldapwiki.com/wiki/LDAP_MATCHING_RULE_BIT_AND"?
(As far as I know, ONLY Microsoft Active Directory supports it)
I assume you are looking to find if some group of user entries are
"Administratively
Disabled
https://ldapwiki.com/wiki/Active%20Directory%20User%20Related%20Searches#section-Active+Directory+User+Related+Searches-AllAdministrativelyDisabledUsersIeACCOUNTDISABLE2"
something like:
(userAccountControl:1.2.840.113556.1.4.803:=2)
Also, your filter should be more like:
Filter f = Filter.createExtensibleMatchFilter(
"userAccountControl",
"1.2.840.113556.1.4.803",
false,
"2");
See
https://sourceforge.net/p/ldap-sdk/discussion/1001257/thread/0d6810c4/#2246
--
-jim
Jim Willeke
On Fri, Jan 18, 2019 at 2:04 AM Hari Tummala haritummala@users.sourceforge.net wrote:
Thanks Jim!
I have configured the rule in the custom schema (attached the file in previous comment). Not sure if that will be sufficient or not :(
Regarding the filter, I am using the same syntax, i didn't noticed any change.
is my inmemory server setting are all good?
Hari
Last edit: Hari Tummala 2019-01-18
The LDAP SDK does not currently support client-side evaluation for search filters with either approximate-match or extensible-match components, and this includes the in-memory directory server.
If you try to use the Filter.matchesEntry method with such a filter, the LDAP SDK will throw an exception. The in-memory directory server uses this method behind the scenes to identify matching entries when processing a search operation, but it swallows any errors encountered while evaluating a filter against an entry. Previously, this would have resulted in the search simply not returning any entries. However, I have just committed a change that updates the in-memory directory server so that it will reject any search request that contains a filter with an approximate-match or extensible-match filter component. Sorry for the inconvenience.
By the way, even if the LDAP SDK did support client-side evaluation for these types of filters, it doesn’t currently support the matching rule that you’re trying to use. And because a matching rule requires logic to perform its processing, it’s not sufficient to simply add the OID to the schema. You would also have to have written code to implement the necessary logic.
We can consider updating the in-memory directory server to add limited support for extensible matching, but it’s probably never going to provide full support for this capability. It’s also unlikely that we’ll add client-side support for approximate-match filters.