Grouper Users - Open Discussion List

[Shilen Patel <>]

I was looking at the second issue (the question mark).  I couldn’t find anything in the code that would do that.  Further, if I try to run a query with an attribute that starts with a question mark, ldaptive/jndi doesn’t even allow it to be sent to the ldap server.

 

groovy:000> try {LdapSessionUtils.ldapSession().list("personLdap", "ou=people,dc=unige,dc=ch", null, "(&(?swissEduPersonUniqueID=smith*)(objectClass=unigeChPerson))", new String[0], null); } catch (Exception e) { e.printStackTrace(); }

java.lang.RuntimeException: Problem with ldap conection: personLdap,

Error querying ldap server id: personLdap, searchDn: ou=people,dc=unige,dc=ch, filter: '(&(?swissEduPersonUniqueID=smith*)(objectClass=unigeChPerson))', returning attributes: 

…

Caused by: [org.ldaptive.LdapException@433545478::resultCode=INAPPROPRIATE_MATCHING, matchedDn=null, responseControls=null, referralURLs=null, messageId=-1, message=javax.naming.directory.InvalidSearchFilterException: invalid attribute description; remaining name 'ou=people,dc=unige,dc=ch', providerException=javax.naming.directory.InvalidSearchFilterException: invalid attribute description; remaining name 'ou=people,dc=unige,dc=ch']

 

 

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?

 

- Shilen

 

 

On 9/12/19, 4:53 PM, " on behalf of Dominique Petitpierre" < on behalf of > wrote:

 

    Hello,

    in the process of upgrading Grouper to version 2.4.0 I encounter some problems. Here are two:

   

    1)

    When doing an incremental search for a member in the "Add or remove members" interface, the following warning message occurs:

   

    2019-09-12 21:25:59,562: [ajp-nio-127.0.0.1-8009-exec-2] WARN  SubjectSourceCache.updateSubjectInCache(1112) -  - In subject source: peopletst the identifier: 'smith*' can find subject: '', but the attribute for that identifier is not configured in the subject source.  In order for caching to be effective, please list all identifier attributes in the subject source.  You can configure to suppress this log message in subject config.

    2019-09-12 21:25:59,562: [ajp-nio-127.0.0.1-8009-exec-2] DEBUG SubjectSourceCache.updateSubjectInCache(1169) -  - method: updateSubjectInCache, retrieved: true, accessed: true, subjectSourceCacheItemNull: true, subjectSourceCacheItemLookedUp: false, createdNewCacheItem: true, numberOfTimesRetrieved: 1, numberOfTimesAccessed: 1, sourceId: peopletst, identifier: , createSubjectKeyCache: true, existingSubjectCacheKeySize: 0, identifier_unigechemployeeuid: smithd, identifier_unigechstudentuid: null, identifierNotConfigured: smith*, : true, addOrReplace_smithd: true, took: 8248micros

   

    The relevant configuration in subject.properties are done according to https://urldefense.proofpoint.com/v2/url?u=https-3A__spaces.at.internet2.edu_display_Grouper_Grouper-2BSubject-2BAPI-2Bcaching-2Bimprovements-2Bin-2B2.4&d=DwICaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=sWqutME58phurE0oO57Icg&m=UhTaWj9EfKyFAFdd5InPV3fHxmUvdh78SZW10v0D_tQ&s=oT07fdT52H0ck0s5KoIVaEbJmod1pWQrMKKrEK3ecPQ&e=  :

   

    # subject identifier to store in grouper's member table.  this is used to increase speed of loader and perhaps for provisioning

    # you can have up to max 1 subject identifier

    subjectApi.source.peopletst.param.subjectIdentifierAttribute0.value = unigeChEmployeeUid

   

    # subject identifier to store in grouper's member table.  this is used to increase speed of loader and perhaps for provisioning

    # you can have up to max 1 subject identifier

    subjectApi.source.peopletst.param.subjectIdentifierAttribute1.value = unigeChStudentUid

   

    Which is correctly read by Grouper:

    gsh 1% SourceManager.getInstance().getSource("peopletst").getSubjectIdentifierAttributesAll();

    java.util.LinkedHashMap: {0=unigechemployeeuid, 1=unigechstudentuid}

   

    And the LDAP directory log shows the following corresponding searches:

   

    Sep 12 21:25:59 peopletst1 slapd[76546]: conn=1018 op=8 SRCH base="ou=people,dc=unige,dc=ch" scope=1 deref=0 filter="(&(?swissEduPersonUniqueID=smith*)(objectClass=unigeChPerson))"

    Sep 12 21:25:59 peopletst1 slapd[76546]: conn=1018 op=10 SRCH base="ou=people,dc=unige,dc=ch" scope=1 deref=0 filter="(&(uid=smith*)(objectClass=unigeChPerson))"

    Sep 12 21:25:59 peopletst1 slapd[76546]: conn=1018 op=12 SRCH base="ou=people,dc=unige,dc=ch" scope=1 deref=0 filter="(&(|(uid=smith)(cn=*smith*))(objectClass=unigeChPerson))"

   

    corresponding to the following configured filters:

   

    subjectApi.source.peopletst.search.searchSubject.param.filter.value = (&(swissEduPersonUniqueID=%TERM%)(objectclass=unigeChPerson))

    subjectApi.source.peopletst.search.searchSubjectByIdentifier.param.filter.value = (&(uid=%TERM%)(objectclass=unigeChPerson))

    subjectApi.source.peopletst.search.search.param.filter.value = (& (|(uid=%TERM%)(cn=*%TERM%*))(objectclass=unigeChPerson))

   

    

    The debug log entry shows that the subjectIdentifierAttribute0 and subjectIdentifierAttribute1 are correctly assigned,

    but somehow Grouper wants to find the value "smith*", which of course does not exist.

   

    Presumably the incremental search /completion code uses the searchSubjectByIdentifier filter and adds a "*" to the %TERM% (smith*),

    and that does not play well with the cache code which expects the %TERM% to be an exact match (smithd) for one of the subjectIdentifierAttributeN values.

   

    Is there a way to fix that problem or is this a bug?

   

    

    2)

    The second issue is that a question mark is inserted in the searchSubject filter (cf. LDAP log above).

    The search will never return any result. Strange!

    I double checked: there is no invisible character in the subject.properties file for the searchSubject filter property.

    In other context than incremental search that filter works properly with the correct value.

   

    Again: Is there a way to fix that problem or is this a bug?

   

    

    Note:

    I actually was surprised by the way the incremental search works:

    - it adds a "*" to query filters that were not supposed to have one (i.e. were meant for exact match),

      and in my case it caused problems because neither the swissEduPersonUniqueID (opaque identifier)

      nor the uid (very short) attribute were indexed for wildcard searches.

      (the Lite UI incremental search does not do that and uses only the search.search filter without adding wildcards)

    - it does three different searches when one should be enough, especially that it is quite expensive anyway.

    Suggestion:

    May be a search.incrementalSearch.param.filter.value could be defined to allow for fine tuning incremental searches?

   

    Thanks in advance for your help!

   

    Regards,

    --

    Mr Dominique Petitpierre, user=Dominique.Petitpierre domain=unige.ch

    IT Division, University of Geneva, Switzerland