[389-users] Re: notes=A for filter with undefined attribute

Ideally, fix the client to change the filter to remove that.

If that's not possible, the other alternative is to fix it on the server side by forcing the DS to process this filter efficiently.

Something I found that seems to work is this:

- Define samaccountname in your schema
- index it as appropriate for the search your printer is doing (eq, substring, etc)

This should basically result in an empty index for samaccountname, and since you have nothing with this attribute, it will allow it to quickly process the fact that there are no results for that part of the filter and focus on the uid=someone part of the filter. If you never populate anything with that attribute, I can't imagine it will add much/any work to the server to maintain that index or take much memory to cache it.

Bit of a hack, but I had a similar problem with outlook searching on Displayname and this worked for that (displayname was already defined but I didn't populate it, just had to index it).





-----Original Message-----
From: albert.luo@uwindsor.ca [mailto:albert.luo@uwindsor.ca]
Sent: Friday, June 9, 2017 9:28 AM
To: 389-users@lists.fedoraproject.org
Subject: [EXTERNAL] [389-users] notes=A for filter with undefined attribute

Hi,

Xerox printer's LDAP connectivity's default search filter is (|(uid=someone)(samaccountname=someone)). samaccountname is not a defined attribute. This search filter will result notes=A, causing performance issue.

Is there a way to avoid searching samaccountname=someone, since samaccountname is not a defined attribute. Thank you!
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org