Grouper Users - Open Discussion List

[Dominique Petitpierre <>]

Hello,

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 
> '(&(swissEduPersonUniqueID=smith*)(objectclass=unigeChPerson))'
> 
> What does the above end up logging on your ldap server?

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

 filter="(&(?swissEduPersonUniqueID=smith*)(objectClass=unigeChPerson))"

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

 filter="(&(swissEduPersonUniqueID=smith)(objectClass=unigeChPerson))"

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:

 olcLimits: 
{0}group/groupOfNames/member="cn=nolimits,ou=config,ou=groups,dc=unige,dc=ch" 
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 domain=unige.ch
IT Division, University of Geneva, Switzerland