In the search window, for the sAMAccountName column, is there a way to filter by exactly 7 characters or is there a function in the search window that allows me to do that?
My coworker and I did try to do a search online but couldn't find anything.
The LDAP search operation requires at least a base object from which to start the search, the scope (or depth) of the search, and a filter which indicates by its truth, falsehood, or undefinedness whether an entry should be returned in the search result. Filters are defined in RFC4511. There is no way to specify the length of an attribute value in a filter. In order to return an attribute value that matches a length, you must store an attribute whose value is the length of the attribute value you desire. For example, if the attribute is cn, an attribute value cn-length could be stored whose value is length of the cn attribute. Modern, professional-quality directory servers will provide virtual attributes which are not stored in the directory database but generated dynamically. Such a virtual attribute hold be created to generate the length.
See Scott Lowe's blog post on using Log Parser to query AD for an example of how you could do this. You could also extract results from an AD query and then feed them into Excel or another tool that has more functions than built into LDAP.
Related
I am using an IBM wrapper solution around SPARQL to get information from our database. I set a triple variable to act as a filter but it doesnt return an exact match, only a 'contains' match.
More specifically, we are looking at requirements that live in a collection. The SPARQL query returns all requirement objects and the collection that they live in. Each collection has a unique identifier associated with it which is accessed via the predicate 'dcterms:identifier'. The exact line in the SPARQL code which does this is:
?oslc_rm_RequirementCollection1_uri dcterms:identifier ?oslc_rm_RequirementCollection1_identifier
This works as expected. In the output I get a table containing each collection with the list of requirements associated with each one.
The problem arises when I want to look at requirements in only a specific collection. To do this I set the variable oslc_rm_RequirementCollection1_identifier in IBM's wrapper, and it generally works. If I enter '18732' it only shows me requirements from the collection with id 18732. However, this is not an exact match only a contains. For example if I enter '867', I am shown two collections: 867 and 38674.
How can I modify this to exclude 38674 and only show the exact match? I cannot use a string literal because the wrapper does not allow this.
I want to retrieve a user DN as stored in the LDAP server, keeping the original characters case. For example, let's assume the DN in my server is "cn=Bob, o=MyOrg". I want to query the server using "cn=bob, o=myorg" and retrieve the original "cn=Bob, o=MyOrg", as a result.
The DirContext.getAttributes(dn) method can return a set of attributes but this does not include the DN itself. On the other hand, DirContext.search() returns a SearchResult that has this information using getNameInNamespace(). Unfortunately, search expressions do not seem to allow search on DN, which is what I have.
I understand that I might achieve this by first retrieving a unique attribute using getAttributes(), and then use this attribute value in search(). But this leads to 2 connections. Plus I need to make sure that I have a unique, not null, attribute I can search() on.
Let me reply to my question with the solution I found.
It involves the search() function, where the name parameter (search context) should be the DN, and the query filter is empty or like (objectClass=*). It then returns one row, corresponding to the DN being searched. The original DN is then available in the SearchResult.
Just do a lookup of the DN. The resulting DirContext should have its getNameInNamespace() in the correct case.
A search will also work but it's less efficient and more code.
How to create an Endeca query on combination of multiple fields [just like where clause in sql query]. Suppose we have three fields indexed are -
empId
empName
empGender
Now, I need a query like "where empName like 's%' AND empGender=male"
Thanks.
Firstly,
Checkout Record Filters in the Advanced Development Guide.
If you are trying to use a Record Filter on a property, you will need to enable it explicitly in Developer Studio for that property, while your Dimensions will automatically have the ability to apply a Record Filter. This will help when you have explicit values to filter on, for example empGender.
Your Record Filter can then look as follow:
Nr=AND(empGender:male)
You can further use the Ntk parameter to specify fields to search on so assuming your empName field is enabled for wildcard searching (configure this in Developer Studio) searching this field will look as follow:
Ntk=empName&Ntt=s*
So assuming your properties have been configured correctly, your example above will probably end up looking as follow:
Nr=AND(empGender:male)&Ntk=empName&Ntt=s*
To take this one step further, you can specify Search Filters (ie. Ntk + Ntt parameters) together. I haven't tried this for wildcards so you'll need to confirm that yourself but to combine Search Filters you delimit them with |
Ntk=empName|empId&Ntt=s*|1234*
I suggest you manually build up queries in the Reference Application to confirm you get your expected results and then start to code this up in your application.
radimbe, the problem with record filters for this use case is that they need to be precise. This means you don't get pelling correction, thesaurus expansion, case insensitivity or stemming. It's very unlikely that a user will input precise information like this.
Saraubh, you can do a boolean search to do OR text search queries. You can also use the Endeca Query Language to specify a complex set of boolean logic that goes beyond boolean search and which would incorporate spelling correction, stemming, etc.
In general though, I think for an application like this, you should move away from searching specific individual fields simultaneously and make use of the faceting capabilities of dimensions to guide the user. Additionally, a search box that searches many fields in combination simultaneously in order of importance is really the way to go for a simplified user interface for this sort of application.
I am having trouble performing a query in the LDAP system. Because I am able to query for a manager and receive the list of direct reports, I know the connection is correct.
I would like to search from the RootDSE for any item with a partial match in the managedBy field. Using * as wildcard, I want to search for *XX9XXX9*.
I receive the correct record when I perform the following search on the name field: (&(objectCategory=*)(name=XX9XXX99X99X9))
The managedBy field contains the following attributes:
CN=Lastname\, Firstname XX9XXX9
OU=Tiered Services
OU=Premium
OU=NCG
OU=Accounts
OU=BAND
DC=corp
DC=XXXXXXXXX
DC=com
When I attempt the same query as I did with the name field, no results are returned. Any help would be much appreciated.
You'll have to try an alternate method to get what you're after: managedBy contains a distinguished name, and DNs do not support the wildcard character in queries.
Edit: possible duplicate of Active Directory C# using ManagedBy attribute
Found out the issue that was causing the problem... the application i /was/ using was not doing the search in the correct manner - it was trying to do a string search, but in reality, the OU entry was not a string, it was a number (ID to the OU).... the application was trying to think for me.
Instead of showing the ID, it was performing a lookup by itself and presenting the results of the lookup, not the real value in the field.
Let's suppose that I want to search a number say 123 and LDAP has entries like 123# or 1-2-3. What should be the LDAP Search filter which needs to be provided? I tried *123* but it doesn't work in case of 1-2-3.
LDAP does not have "entries like 123#", it has entries identified by distinguished names that contain attributes. To search for an an entry that contains a value, you must provide the following parameters to a search request:
base object (distinguished name where the search should commence)
scope - base, one level subordinate to the base, or subtree (all entries subordinate to the base object
filter - an assertion that must evaluate to true in order for the entry to be returned to the client
attributes to return - a list of attributes that the LDAP client desires
If the attribute in question is named number and has a syntax of Integer and a matching rule of IntegerMatch, then the filter (number=123) will find an attribute named number with the integer value of 123. Which filter to use depends on the syntax and matching rule in the attribute type definition because the directory server performs the task of matching attribute values against provided filters with matching rules (as must applications, by the way). Programmers must not consider LDAP attribute values to be "strings", instead they must understand attribute syntaxes and matching rules. There is a DirectoryString syntax (with a very specific definition, though for many purposes it can be considered a garden-variety string) but not all attributes are defined with DirectoryString syntax. Nor do all attributes use the same matching rules and ordering rules.
see also
LDAP: ldapsearch
LDAP: Mastering search filters
LDAP: Programming Practices