LDAP timeout errors

[Cantor, Scott]

> How would we determine where the issue was? 

Nobody else can tell you why an LDAP server didn't respond quickly enough. You certainly can't ever assume any remote source of data won't fail at times no matter what you do. That's why I avoid using them wherever I can, YMMV, as does the reliability of the LDAP server.

There are also issues with pooling, like connections going stale and not being terminated by a load balancer properly or at the proper time so the IdP doesn't know they're gone before trying them. Lots of factors, most of them greek to me.

My personal opinion is it's a bad use of time to deal with it all, and if you have to care, the deployment should be adjusted so you don't have to care very much. Slightly stale data provided reliably via local caching trumps up to date information that fails even 0.1% of the time. Again, YMMV.

> The second part of the question: if the search timed out, why
> did the assertion go across? It appears that with the double
> pipe, no attributes were sent? Should this be a fatal error? 

That's up to you, but not by default, no. If a connector is configured to propagate its errors and has no failover defined, it will blow up the resolver attempt, but if the property to "mask" attribute resolution exceptions to the rest of the IdP is enabled (which is the default), then it won't fail the request outright.

It's all documented, and under your control to meet whatever your expectations are for dealing with outcomes, but there are no defaults that can meet everybody's expectations.

(I disagree with a number of the defaults in that area in fact, but stability/consistency sort of demanded I didn't just impose my will on it given how long it's been like that.)

-- Scott