DataConnector Delay

[Mr. Christopher Bland]

Hi Michael,

Thanks for the great feedback.  I actually noticed a number of your points responding to David and Scott.  You were right about my Base DN. I took Scott’s suggestion of enabling caching and fixed my Base DN since all of the groups I am concerned with are in a single OU.  You mention direct membership, which I am doing.  I took this approach because it flattens out all of the memberOf attributes into one.  Are you querying memberOf differently?

-Chris

> On Dec 28, 2016, at 9:35 PM, Michael A Grady <mgrady at unicon.net> wrote:
> 
> 
>> 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.
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net