DataConnector Delay

[Michael A Grady]

> On Dec 28, 2016, at 8:26 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> On 12/28/16, 9:10 PM, "users on behalf of Mr. Christopher Bland" <users-bounces at shibboleth.net on behalf of chris at fdu.edu> wrote:
> 
>> I think I need to give you a little more detail on why this is important to me, perhaps there’s another way to skin this cat.  I
>> have spent a lot of time recently tuning our system because response times were horrible.  This 3-6 second delay is
>> often doubled
> 
> Even allowing that the IdP has little or nothing to do with the LDAP search response time (which is true), if you're doubling that, then you're obviously not caching the results.
> 
>> Normal AD/LDAP queries come back in microseconds.
> 
> Not the one you're asking it to do, apparently. The IdP doesn't have any control over what search you ask it to do, and the search takes what it takes.
> 
> -- Scott
> 

As  the underlying Microsoft article referenced says:
   "Note that when using LDAP_MATCHING_RULE_IN_CHAIN, scope is not limited—it can be base, one-level, or subtree. Some such queries on subtrees may be more processor intensive, such as chasing links with a high fan-out; that is, listing all the groups that a user is a member of. Inefficient searches will log appropriate event log messages, as with any other type of query."

And trying to list all the groups a user is a member of is exactly what you are trying to do. The better choice is to manage your groups better in the first place, so direct membership alone will give you affiliation, or update your provisioning logic to populate an affiliation attribute in the first place. if you are going to need to fall back on recursive search, you are going to have to bear the cost of that search over and over again. Calculate it ahead of time, and you don't need to do that.

The other thing which you don't appear to be doing, and that both the example in the Shib wiki and that the Microsoft article suggest, is to use a Base DN of the Groups container in AD, not start with the Base DN for the entire directory (which your sample connector looks like it might be doing.)

--
Michael A. Grady
IAM Architect, Unicon, Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://shibboleth.net/pipermail/users/attachments/20161228/33b4ad47/attachment.sig>