Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] subject cache warning: "the attribute for that identifier is not configured" + question mark added to LDAP search filter

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] subject cache warning: "the attribute for that identifier is not configured" + question mark added to LDAP search filter

Chronological Thread 
  • From: Shilen Patel <>
  • To: Dominique Petitpierre <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] subject cache warning: "the attribute for that identifier is not configured" + question mark added to LDAP search filter
  • Date: Sat, 14 Sep 2019 10:10:44 +0000
  • Arc-authentication-results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EqpbQDJIwbJi36rof00IoAWPirrg9QowWcGMUgSs/wo=; b=LQoflydA1oNo38J6vBoqvBbltqmC07GgOjjrEZxRzsxphl0bSamLft1nE7O38BbNSjYkto7lFcHu+7zqZCZKURKKT7+A8ccrSSLFkGzn53KJ9YMUKd/bxKKS0RuR5OS9yYkH9xriXPpudyO/ae5ZTVv43GlC40JOogcf6T+pfPW8PA671WHmAeqYPQV+fo1NQDotD4YqRVKbC8eaznZjRV7DdMVqdTwhiGm4vssUcYg5z3+NEqeFHket+8q8q/hRT1SnM0bLCBnQXqZ1PPUMfomWJFyiUkf/Qw6CnPkDauwh2MMFE4sFvkD9Rze8YuC3EnrPai20T5wdDuNiZXyTmg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=dV6wrjri47jXBjCRkPmgo9B+XUcHilMe/J7lqD2VlxGI7Sedovati9iEXwPKiCgA8oe/6WunDcST4OZAnT4eGHxjXAwF2Br9MQ2e77/j5DjkQdMTbDvRyHMphsa+JstQHds1f8/36A0ma01oSL5FaC+yt9KRZvOsTALBp6/BEzNauuaKuSWfXaaoIcHa6JxBVQ8ZivQuglwDoSnI9moiF/1KvxzdyQbA2jLV7evTQtisxDTEAJ1QFa8motgbSf69htL8haEI0q8wHkMTUx91EmW4O47O6hxABC7cP4xDXJUZShOq7bXd/qpXDO87AWK6IPY+spYGqS3eMMTL0BhdHA==

Great, I’m glad that clears that up. Now to the other issue, I’m wondering
if it could be solved by simply having a config option to prevent adding the
wildcard at the end of the query?

I could see there being cases where somebody doesn’t want that wildcard (like
your case) but still wants multiple queries to run. For example, if my
maxPage/maxResults are set to 100 and I’m searching for “smith” which has 1
exact match on NetID and 1000 matches on name, I would want the
findByIdOrIdentifier query to run to make sure the result that matches
exactly on NetID is displayed since it wouldn’t be guaranteed that the other
query will return it due to the maxPage/maxResults.

Would that work? It would still mean 3 queries, but the first 2 would run as
expected and would be indexed/fast. Or is there some reason I’m not thinking
of that might make having a separate query for typeahead more useful?


- Shilen

On 9/13/19, 11:45 PM, "Dominique Petitpierre"
<> wrote:


thanks for your reply:

On 9/13/19 8:51 PM, Shilen Patel wrote:

> That made me wonder that either the question mark isn’t really a
question mark (but rather some other non-ascii character that’s just logged
as a question mark) or your ldap system is logging that as having some
special meaning.
> Just doing some google searches, it seems like OpenLDAP (is that what
you’re running?) may include a question mark in the logs if the attribute is
not in the schema. But in your case, I wonder if it’s being logged with a
question mark because it’s doing a wildcard search on an attribute that’s not
meant to be searched that way? Are you able to manually reproduce that log
via ldapsearch command line?
> ldapsearch -x -b ou=people,dc=unige,dc=ch -h yourhost
> What does the above end up logging on your ldap server?

You are right: that request causes the same log entry with a question


while the same request but without the wildcard is logged as expected:


The attribute swissEduPersonUniqueID is not indexed for wildcard searches:

olcDbIndex: swissedupersonuniqueid eq,pres

It is an OpenLDAP annotation to indicate which attribute test cannot be
calculated with an index.
So it is not a Grouper issue!
Relatively new to OpenLDAP I had never noticed these question marks, and
was too deep in Grouper upgrade issues to even lift my head above.
Strange enough the filter is not even applied sequentially (a request
that could match returns immediately, empty),
even though the Grouper LDAP agent currently has no administrative limits:

size.soft=unlimited size.hard=unlimited size.unchecked=unlimited

So I could create a wildcard search index for that attribute, but I would
prefer not to:
In Grouper UI, since the values of swissEduPersonUniqueID are opaque, it
does not really make sense to do a wildcard search.
hence my surprise that the new UI does not seem to let you configure
incremental searches specifically
and in this case will use a filter meant originally to search for
SubjectID with exact match to do requests
that will mostly fail without or with a heavy cost (for directories that
do sequential searches)
or force one to create a wildcard search index uselessly.

Thanks again!

Mr Dominique Petitpierre, user=Dominique.Petitpierre
IT Division, University of Geneva, Switzerland

Archive powered by MHonArc 2.6.19.

Top of Page