Highlighted
Knowledge Partner
Knowledge Partner
174 views

Using the ou:dn=Admin syntax, is there an index that helps?

LDAP supports a syntax, whose name I forget in queries where the filter can look like:

 

(&(objectClass=user)(ou:dn=Acme))

That means, any part of the DN, has an ou=acme, then return the user. 

I have a customer where an LDAP query using that is not responding fast enough for the apps timeout (Fix the app timeout,, but you know how that is...) I was wondering if there is an index that helps this sort of query.

entryDN is technically a valid attribute but of course that is not really indexable.  I suppose, ancestorID would be helpful.  But in what?  Usually ancestorID is helpful on attribute + ancestorId.

This one has me a bit stumped.  Maybe it is built in indexed? 

What is the real underlying structure of a DN?

I suspect it is the objectID of this guy rendered to a cn=value, then the ancestorId objectID rendered into an ou=string, then ancestorID's objectID and so on...  

Not sure how that would all work together to try and speed it up. 

Labels (1)
0 Likes
4 Replies
Highlighted
Knowledge Partner
Knowledge Partner

Re: Using the ou:dn=Admin syntax, is there an index that helps?

And I think the name is Extensible match.  I was totally blanking on it. 

 

In trace it looks like this:

10:21:45 472F9700 LDAP: DoSearch on connection 0x105b4a80
10:21:45 472F9700 LDAP: get_filter: EXTENSIBLE
10:21:45 472F9700 LDAP: get_filter: EXTENSIBLE
10:21:45 472F9700 LDAP: get_filter: EXTENSIBLE
10:21:45 472F9700 LDAP: get_filter: EXTENSIBLE
10:21:45 472F9700 LDAP: get_filter: EXTENSIBLE
10:21:45 472F9700 LDAP: get_filter: EXTENSIBLE
10:21:45 472F9700 LDAP: get_filter: EXTENSIBLE
10:21:45 472F9700 LDAP: get_filter: EXTENSIBLE
10:21:45 472F9700 LDAP: Search request:
   base: "o=acme"
   scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
   filter: "(&(objectClass=person)(|(ou:dn:=DisabledIDs)(ou:dn:=WM)(ou:dn:=CS)(ou:dn:=MM)(ou:dn:=admin)(ou:dn:=a2)(ou:dn:=csc)(ou:dn:=s1)))"
   attribute: "businessCategory"

 

(That is a stupid LDAP query, but the product using it has an immature LDAP interfaace and cannot handle multiple base DN's so this is their workarouond. One search base at the top, then extensible match to control subcontainers. Icky, but whatever.

I am an LDAP snob.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: Using the ou:dn=Admin syntax, is there an index that helps?

Hi Geoff,

currently there is no index. See Bug 1087757 - Searches using Extensible Match Search Filter for DN have poor performance.

 

 

--
Norbert
Highlighted
Knowledge Partner
Knowledge Partner

Re: Using the ou:dn=Admin syntax, is there an index that helps?

Well rats, that is not entirely what I was hoping to hear.

Glad Holger identified it. Alas it does not look like has  been touched since 2018 in that bug. 

Thanks for the response.

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: Using the ou:dn=Admin syntax, is there an index that helps?

I'd like to add a second vote of support for getting this fixed. I use this type of Extensible Match Search Filters on a semi-regular basis and would really love for them to have level/equal treatment with regular searches performance wise.

Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.