I need to filter the AD description field, such that LDAP should exclude all the records which description length is more than 500 characters.
Could somebody help me to in this?
There is no way with LDAP to set a filter on the length of values, as there is no standard LDAP matching rule for this.
Related
In Azure Search you can boost a query by using first term || secondterm^2 to give more weight to a particular part of the query.
You can also filter for documents that belong to a particular group using search.in(): https://learn.microsoft.com/en-us/azure/search/search-query-odata-search-in-function
$filter=group_ids/any(g: search.in(g, '123, 456, 789'))
What I would like to do is boost a document if it belongs to a group but not restrict to only documents that belong to that group.
Something like:
search=mysearchterm^3&$filter=group_ids/any(g: search.in(g, '123, 456, 789'))^2
But (1) boosting on the filter doesn't seem to work and (2) this would restrict to only documents that belong to group 123,456,789. I would like it to only boost if it belongs, but not restrict to only those groups.
Is this possible?
I've had a look at "Tag Boosting": https://azure.microsoft.com/en-au/blog/personalizing-search-results-announcing-tag-boosting-in-azure-search/
But it doesn't seem relevant, it only seems possible to tag boost a top level string field, not a string or int field within a collection.
UPDATE:
I think i've figured it out as:
search=mysearchterm AND (group_id:123)^2
If you're using a complex collection it might be:
search=mysearchterm AND (groups/id:123)^2
Filters are designed to constrain your result set by filtering out documents that don't match the filter criteria. This process happens before term matching and scoring. Given that this is not what you are trying to do, I don't think filters are the right tools for the job.
You can try to instead craft a Lucene query that includes the logic you described:
mysearchterm OR (mysearchterm AND group_ids:(123 OR 456 OR 789))^2
I am doing an LDAP search with groovyldap, the search returns the group that I am looking for but only returns 5000 members of the group:
def getGroupMembers() {
def ldap = LDAP.newInstance(connectionInformation.hostname, connectionInformation.user, connectionInformation.password)
def result = connection.search("CN=mygroup", "OU=foo,DC=bar,DC=blech", SearchScope.SUB)
def members = result["member;range=0-4999"]
members = members[0]
}
Yes, there is actually a field returned with the key "member;range=0-4999", and the "members" array has 5000 elements in it. I couldn't find any setting in the LDAP code to enable returning all members, but it seems logical to think that I should be able to fetch all of the results.
Microsoft Active Directory implements LDAP policies are implemented using objects of the queryPolicy class.
Appears the one which you are encountering is the MaxValRange which the number of values that are returned in the retrieval of multi-valued attributes of an entry.
In Microsoft Active Directory 2008 (and I assume later, this is hardcoded and although it can be modified, it is not effective).
If an attribute has more than the number of values that are specified by the MaxValRange value, from LDAP, you may use LDAP_SERVER_RANGE_OPTION_OID "Control" to retrieve values that exceed the MaxValRange value.
I have two possible answers for you. (Sorry, it's been a while since I've played with LDAP / ActiveDirectory).
You may be hitting AD page size limits. Learn more about page size limits, and the easiest way here is to implement paging in your ldap queries.
How exactly to do that in groovyldap is (unfortunately an exercise for the reader, but I've done it with nodeldap. I think it emits a page event(?) it's been a while since I've done this.
You may have a range query. I don't know much about these, but there's some thoughts on that in another StackOverflow Answer.
I am using Solr 6.0.0
I am using data-driven-configuration for my configuration related purpose. Most of the configuration is standard.
I have a document in Solr with
name:"aquickbrownfox"
Now if I do a fuzzy search like:
name:aquickbrownfo~0.7
OR
name:aquickbrownf~0.7
It lists out the record in the results.
But if I do a search like:
name:aquickbrown~0.7
It does not list the record.
Does it have to do something with the maxEdits in solrconfig.xml which is set to 2 ?
I tried increasing it. But I could not create a collection with this configuration. It gave an error:
ERROR: Error CREATEing SolrCore 'my-search': Unable to create core
[my-search] Caused by: Invalid maxEdits
Max 2 Edits seems to be a serious limitation. I wonder what is the use of passing the fractional value after the ~ operator.
My Usecase:
I have a contact database. I am supposed to detect the duplicates based on three parameters : Name, Email and Phone. So I rely on Solr for Fuzzy search. Email and Phone are relatively easy to work with simple assumptions. Name seems to be a bit tricky. For each word in the Name, I plan to do a fuzzy search. I expected the optional parameter after ~ to work without the maxEdit distance limitation.
The documentation no longer suggests using a fractional value after the tilde - see http://lucene.apache.org/core/4_6_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Fuzzy_Searches for more information.
However, you are correct that only 2 changes are allowed to be made to the search string in order to carry out a fuzzy search. I would guess this limitation strikes a balance between efficiency and usefulness.
The maxEdits parameter in solrconfig.xml applies to the DirectSpellChecker configuration, and doesn't affect your searching, unless you're using the spell checker.
For your use case, your best approach may be to index the name field twice, using different field configurations: one using a simple set of analyzers and filters (ie. StandardTokenizerFactory, StandardFilterFactory, LowerCaseFilterFactory), and the other using a phonetic matcher such as the Beider-Morse filter. You can use the first field to carry out fuzzy searches, and the second version to look for names which may be spelled differently but sound the same as the name being checked.
I have an OpenLDAP installation and I need to find an entry, from my custom schema extension, based on a DN value.
To be more specific I have an attribute (certSubjectDN) added to one of my custom classes that contains a DN which is used for certificate based authentication on a web server using smart cards (PKI auth). From what I understand a filtered search with substring matching against Active Directory, e.g. (certSubjectDN=CN=lastname.firstname*), will match against any entry where the value of certSubjectDN begins with 'CN=lastname.firstname'. This does not work with OpenLDAP.
I have attempted to add a matching rule to the attribute, SUBSTR caseIgnoreSubstringsMatch, but OpenLDAP refuses to accept that change, presumably because it is strictly following the LDAP specifications.
Can someone think of a way that I can perform such a substring match against an attribute of the DN type within OpenLDAP? Or should I just change that attribute to be a Directory String?
Thanks,
Chris
I am not an OpenLDAP expert, but I think you are on the right path. The DN syntax does not allow substring matching. The string syntax does.
If this fails, I would try to define a custom attribute with string syntax and the appropriate substring matching rule.
I hope this helps.
I use ELK to arrange my logs, logs goes from many places and some records might not contain several fields and the question is what is the best way to find such records? Can I find logs which not contains several fields?
Kibana uses the query string query syntax of Elasticsearch in its filters. The syntax to find a document that does not have a given field is _missing_:FIELD_NAME. The + operator is the preferred way to ensure that a particular search term must be present in the matched documents. Combining these two will allow you to search for documents that are missing multiple fields:
+_missing_:foo +_missing_:bar +_missing_:baz