DataConnector Delay

[IAM David Bantz]

That's a good description of poor user experience needing to be addressed.
I'm sorry I don't have an equally good resolution.
"Normal AD/LDAP queries" are what LDAP has, historically, been optimized
for; traversing the directory structure (let alone recursively) isn't.

The example you cited from the Shibb wiki traverses the directory structure
for recursively to determine eduPersonAffilation based on various group
memberships, direct and implicit. The alternative to long searches would be
to use that logic to populate the eduPersonAffiliation attribute for person
directory entries, enabling the millisecond response time of "normal"
queries. Apologies if that alternative is incompatible with your
requirements or constraints.

David Bantz

On Wed, Dec 28, 2016 at 5:10 PM, Mr. Christopher Bland <chris at fdu.edu>
wrote:

> Hi David,
>
> 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 because we have front ended a few SPs
> locally with pages we control and then forward to the actual SP which does
> a second auth and attribute pull (for example we have a local Webmail SP
> which determines Student/Employee and then forwards you to Google or an
> on-premise mail application.  Both of which authenticate & pull
> attributes).  That 6-12 delay is just enough to cause my users to click the
> sign-in button again which results in an error.  Normal AD/LDAP queries
> come back in microseconds.  I am using the Global Catalog so there are no
> referrals and everything is in right there.
>
> So while it’s true that it may be an intensive search, the number of
> resulting failed logins make it a tough sell to management that the users
> are just impatient.
>
> -Chris
>
> On Dec 28, 2016, at 8:28 PM, IAM David Bantz <dabantz at alaska.edu> wrote:
>
> Isn't that a pretty intensive sweep of the entire Directory structure for
> recursive group memberships?
> "This rule is limited to filters that apply to the DN. This is a special
> "extended" match operator that walks the chain of ancestry in objects all
> the way to the root until it finds a match." https://msdn.
> microsoft.com/en-us/library/windows/desktop/aa746475
> How fast would you expect that to be?
>
> David Bantz
>
> On Wed, Dec 28, 2016 at 4:10 PM, Mr. Christopher Bland <chris at fdu.edu>
> wrote:
>
>>
>> HI All,
>>
>> I am experiencing a weird delay between 3 and 6 seconds when
>> using DataConnector shown below.  My DataConnector is pretty much the same
>> as Shibboleth Wiki "Generate eduPersonAffiliation based on recursive group
>> membership in Active Directory” example on Generate eduPersonAffiliation
>> based on recursive group membership in Active Directory
>> <https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverScriptAttributeDefinitionExamples#ResolverScriptAttributeDefinitionExamples-GenerateeduPersonAffiliationbasedonrecursivegroupmembershipinActiveDirectory>.
>> I am running IDP v2.4 (planning to upgrade soon)  I’ve tried cranking up
>> logging but am not seeing the issue.  Has anyone else had an issue like
>> this?
>>
>>
>> <resolver:DataConnector id="ADgroupLDAP" xsi:type="dc:LDAPDirectory"
>>         ldapURL="ldaps://adserver_1:3269 ldaps://adserver_2:3269
>> ldaps://adserver_3:3269 ldaps://adserver_4:3269 ldaps://adserver_5:3269
>> ldaps://adserver_6:3269"
>>         baseDN=“AD_BASE_DN"
>>         principal=“PRINCIPAL"
>>         principalCredential=“PASSWORD"
>> maxResultSize="1000"
>> mergeResults="true"
>> searchTimeLimit="PT30.000S"
>> connectionStrategy="RANDOM"
>> >
>>
>> <resolver:Dependency ref="scripted_distinguishedName" />
>> <dc:FilterTemplate>
>> <![CDATA[
>> (member:1.2.840.113556.1.4.1941:=${scripted_distinguishedName.get(0)})
>> ]]>
>> </dc:FilterTemplate>
>> <dc:ReturnAttributes>distinguishedName</dc:ReturnAttributes>
>> </resolver:DataConnector>
>>
>>
>> 2016-12-27 00:00:02.383 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:210]
>> - verifyDNS found hostname match: adserver_6
>> 2016-12-27 00:00:02.436 - DEBUG [edu.vt.middleware.ldap.Ldap:193] -
>> Search with the following parameters:
>> 2016-12-27 00:00:02.437 - DEBUG [edu.vt.middleware.ldap.Ldap:194] -   dn
>> = AD_BASE_DN
>> 2016-12-27 00:00:02.437 - DEBUG [edu.vt.middleware.ldap.Ldap:195] -
>> filter = (member:1.2.840.113556.1.4.1941:=USER_DN)
>> 2016-12-27 00:00:02.437 - DEBUG [edu.vt.middleware.ldap.Ldap:196] -
>> filterArgs = []
>> 2016-12-27 00:00:02.437 - DEBUG [edu.vt.middleware.ldap.Ldap:197] -
>> searchControls = javax.naming.directory.SearchControls at 12a0b94
>> 2016-12-27 00:00:02.438 - DEBUG [edu.vt.middleware.ldap.Ldap:198] -
>> handler = [edu.vt.middleware.ldap.handler.FqdnSearchResultHandler at 144f65b,
>> edu.vt.middleware.ldap.handler.EntryDnSearchResultHandler at 8a0a75,
>> edu.vt.middleware.ldap.handler.MergeSearchResultHandler at b4bbea,
>> edu.vt.middleware.ldap.handler.BinarySearchResultHandler at 19d3974]
>> 2016-12-27 00:00:06.922 - DEBUG [edu.internet2.middleware.shib
>> boleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:414]
>> - LDAP data connector ADgroupLDAP - Found the following attribute:
>> entryDN[CN=Desktop-
>>
>>
>>
>> 2016-12-28 00:03:54.382 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:210]
>> - verifyDNS found hostname match: adserver_5
>> 2016-12-28 00:03:54.440 - DEBUG [edu.vt.middleware.ldap.Ldap:193] -
>> Search with the following parameters:
>> 2016-12-28 00:03:54.440 - DEBUG [edu.vt.middleware.ldap.Ldap:194] -   dn
>> = AD_BASE_DN
>> 2016-12-28 00:03:54.440 - DEBUG [edu.vt.middleware.ldap.Ldap:195] -
>> filter = (member:1.2.840.113556.1.4.1941:=USER_DN)
>> 2016-12-28 00:03:54.441 - DEBUG [edu.vt.middleware.ldap.Ldap:196] -
>> filterArgs = []
>> 2016-12-28 00:03:54.441 - DEBUG [edu.vt.middleware.ldap.Ldap:197] -
>> searchControls = javax.naming.directory.SearchControls at 1a5793
>> 2016-12-28 00:03:54.441 - DEBUG [edu.vt.middleware.ldap.Ldap:198] -
>> handler = [edu.vt.middleware.ldap.handler.FqdnSearchResultHandler at 144f65b,
>> edu.vt.middleware.ldap.handler.EntryDnSearchResultHandler at 8a0a75,
>> edu.vt.middleware.ldap.handler.MergeSearchResultHandler at b4bbea,
>> edu.vt.middleware.ldap.handler.BinarySearchResultHandler at 19d3974]
>> 2016-12-28 00:03:59.432 - INFO [Shibboleth-Access:73] -
>> 20161228T050359Z|174.1.116.121|idp.fdu.edu:443|/profile/SAML
>> 2/Redirect/SSO|
>>
>>
>> 2016-12-28 00:06:44.514 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:210]
>> - verifyDNS found hostname match: adserver_3
>> 2016-12-28 00:06:44.576 - DEBUG [edu.vt.middleware.ldap.Ldap:193] -
>> Search with the following parameters:
>> 2016-12-28 00:06:44.576 - DEBUG [edu.vt.middleware.ldap.Ldap:194] -   dn
>> = AD_BASE_DN
>> 2016-12-28 00:06:44.577 - DEBUG [edu.vt.middleware.ldap.Ldap:195] -
>> filter = (member:1.2.840.113556.1.4.1941:=USER_DN)
>> 2016-12-28 00:06:44.577 - DEBUG [edu.vt.middleware.ldap.Ldap:196] -
>> filterArgs = []
>> 2016-12-28 00:06:44.577 - DEBUG [edu.vt.middleware.ldap.Ldap:197] -
>> searchControls = javax.naming.directory.SearchControls at f5e8c1
>> 2016-12-28 00:06:44.577 - DEBUG [edu.vt.middleware.ldap.Ldap:198] -
>> handler = [edu.vt.middleware.ldap.handler.FqdnSearchResultHandler at 144f65b,
>> edu.vt.middleware.ldap.handler.EntryDnSearchResultHandler at 8a0a75,
>> edu.vt.middleware.ldap.handler.MergeSearchResultHandler at b4bbea,
>> edu.vt.middleware.ldap.handler.BinarySearchResultHandler at 19d3974]
>> 2016-12-28 00:06:49.484 - DEBUG [edu.internet2.middleware.shib
>> boleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:414]
>> -
>>
>>
>>
>> Thank you in advance,
>>
>> -Chris
>>
>>
>> --
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161228/eec7611b/attachment-0001.html>