Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

To be consistent with grouper if you misspell a class in a config, or if it cant find it, it should throw an exception…  note, e.printStackTrace() and System.out or System.err shouldn’t be used, so if swallowing exception it needs to be logged with logger..

 

If its in the code its supported.  If you want to add to docs that would be great!

 

Thanks

Chris

 

From: Redman, Chad Eric [mailto:]
Sent: Thursday, January 26, 2017 10:12 AM
To: Hyzer, Chris <>; grouper-users <>
Subject: RE: LDAP Loader and AD ranged attributes

 

Thanks! Your change looks a lot cleaner, and I'll try it out when I can. I'll try how it handles an invalid class name in the field; it should be non-functional either way, but leaving the exception uncaught may be a harder stop.

 

In the ticket, I wondered if using the property readers directly from vt-ldap would be a better long-term fix, since it would allow all its properties to be set, instead of passing a partial set through Grouper translations of them. Right after that, I noticed there is an ldap.*.configFileFromClasspath property that can nearly do this already -- it's just the validator that would still need a custom handling. Is this something supported? I didn't see it documented in the wiki or mentioned on the mailing lists.

 

-Chad

 

 

From: Hyzer, Chris []
Sent: Thursday, January 26, 2017 2:38 AM
To: Redman, Chad Eric <>; grouper-users <>
Subject: RE: LDAP Loader and AD ranged attributes

 

Thanks for the contribution Chad.  I modified it slightly (please review), and put it in patch api 2.3.0 #50

 

Regards

Chris

 

From: [] On Behalf Of Hyzer, Chris
Sent: Tuesday, January 24, 2017 4:06 PM
To: Redman, Chad Eric <>; grouper-users <>
Subject: [grouper-users] RE: LDAP Loader and AD ranged attributes

 

Yes please for pull request

 

From: [] On Behalf Of Redman, Chad Eric
Sent: Tuesday, January 24, 2017 3:34 PM
To: grouper-users <>
Subject: [grouper-users] LDAP Loader and AD ranged attributes

 

Hi,

 

We have some LDAP loader jobs that query AD for subjects. An issue we found when going to production was that our AD source returns a ranged attribute for a membership fields when there are over 1500 members. What this means is that the attribute returned from the query is not "member" but "member;range=0-1499". The client is then expected to do further queries to get the rest of the members, e.g. "member;range=1500-*" and so on.

 

The closest mention I could find for this problem was a 2009 post mentioning a custom result handler for LDAPPC that could handle ranged results. We applied a similar solution to the LDAP Loader. We created a custom RangeSearchResultHandler class (based on the one from https://code.google.com/archive/p/vt-middleware/wikis/vtldapAD.wiki#Range_Attributes) to handle the non-standard attribute label and the loop to get the results. The vt-ldap config has an option (searchResultHandlers) for a multi-valued list of search result handler classes. However, we needed to patch the Grouper code so that it could handle a new ldap.*.searchResultHandlers property in the grouper-loader.properties file and pass it on the LDAP config.

 

Has anyone come across the same issue in getting large result sets from AD? Has this already been solved? I tried the other recommended methods of setting pagedResultsSize, referral, and/or batchSize, with no success. From a debug session, it looks like they all fail to account for "member;range=0-1499" really being the member field.

 

I can put a pull request together, if this is something useful outside of our own installation.

 

-Chad