- UNIFYBroker Forum
-
Ideas
0
Completed
LDAP Searches with a wildcard character return all objects, regardless of other characters placement
It appears that as soon as a wildcard character is used in an LDAP query, any object that has a value populated for the specific field will be returned irrespective of where that wildcard is placed in the query. Unless I've overlooked something, this means you can't do a 'starts with' search.
For example, here is a query of all Users in one of my connectors:
Here is a search for USNAME=TUNA which gives the expected single result
Here is a search for USNAME=TUNA*. This gives unexpected results (USNAMES starting with words other than TUNA are listed)
As a reference, here is how a search on AD Looks for all users
And then doing a search for CN starts with 'c'
ss1.png
ss2.png
ss3.png
ss4.png
ss5.png
Customer support service by UserEcho
Hi Richard Courtenay, a starts with filter hasn't yet been implemented. Is there a particular use case you had in mind?
I was planning to use it as a work around for https://unifysolutions.jira.com/browse/IDB-1232 so that I could do something like the following to narrow down the search results prior to iterating through them in C# and performing a non case sensitive comparison against the results (e.g., check if the USNAME 'TUNA' is already taken, and if so recheck whether 'TUNA1', 'TUNA2' etc is free)
The aim was to minimise the number of objects I'd need to fetch and compare against by filtering the result set.
Migrated to VSO.
I have now run into this issue - what is the status?
The following are querying against the IdB 5.1 adapter - I would have expected both filters to return the same number of objects.
PS C:\WINDOWS\system32> $Filter = "(&(objectClass=person)(|(Surname=Wapshere)(PreferredSurname=Wapshere)))"
PS C:\WINDOWS\system32> $Searcher = New-Object DirectoryServices.DirectorySearcher
$Searcher.Filter = $Filter
$Searcher.SearchRoot = $DirectoryEntry
$Searcher.PageSize = 1000
$objs = $Searcher.FindAll()
write-host ("Found {0} records" -f $objs.count)
Found 2 records
PS C:\WINDOWS\system32> $Filter = "(&(objectClass=person)(|(Surname=*Wapshere*)(PreferredSurname=*Wapshere*)))"
PS C:\WINDOWS\system32> $Searcher = New-Object DirectoryServices.DirectorySearcher
$Searcher.Filter = $Filter
$Searcher.SearchRoot = $DirectoryEntry
$Searcher.PageSize = 1000
$objs = $Searcher.FindAll()
write-host ("Found {0} records" -f $objs.count)
Found 22427 records
Work hasn't started on this feature. Is your use case the same as Richard Courtenay?
Similar. I want to use IdB as a "search proxy" for Aurion, to assist in both manual and scripted process that need to do lookups in Aurion before taking an action. This is a significant value-add for IdB providing something that Aurion itself does not, particularly when looking at cloud-hosted Aurion (so no DB access). Either way IdB is a data source and being able to query using standard LDAP filters is a valuable proposition for all sorts of use cases.
It isn't the easiest operation to support due to the possible complexity (asterisk could appear anywhere in the string) as well as our requirement to support other data stores (all behave differently with regards to searching).
Nonetheless it is standard LDAP and I would expect it to be supported. The data store in this case is the IdB Adapter, so I'm not understanding the comment about other data stores.
The standard is massive. It's certainly part of the spec, but it's by no means required.
OK well keep it on the backlog and increase the priority please. Even just a starts-with and ends-with would help me - doesn't have to be in the middle of the string. The LDAP searchability of IdB is something a couple of my customers have been very interested in, but this restriction really limits what I can do. Exporting out all 20k+ objects and then looping through them in powershell is too slow.
Thanks, will do.