--20cf307811d0eb756704d0342092 Content-Type: text/plain; charset=ISO-8859-1

Actualy I had this before and that did not change anything. I don't think this directive is used for this kind of "timeouts"...

I also tried :

*chase-referrals yes (this is default)* *rebind-as-user yes (as suggested here)**

*single-conn yes (default to NO)**

I also tried some combinings of idassert-bind options with no luck (as the backend does not support identity assertion).

By backend do you mean the remote server you're trying to proxy?

I see your problem. Indeed, when a connection is pruned (in your case because it timed out), information about client's credentials is lost. Back-ldap is working incorrectly, since it falls back to trying to rebind anonymously. However, the only other reasonable option could only be to return a meaningful error (or dropping the connection with the client).

Things work fine with identity assertion, because in that case the client's credentials are no longer needed, what counts is that the client's connection is alive and authenticated, so the client's identity can be asserted.

You'd need to do something like

idassert-bind bindmethod=simple binddn="<authorizing dn>" credentials="<authorizing credentials>" mode=self flags=override

(tested, works fine). However, I understood from what you wrote above that this is not an option.

I see one quick solution: bail out when the connection is lost and idassert is not going to take place. This requires a minimal patch.

An alternative could be to find a decent manner to store the client's credentials in the frontend's connection with the client (as much as we do for the client's identity in c_authz). This will live as long as the client's connection stays alive (something like what we do for paged results).

[disclaimer: I'll look into this time permitting; I can't commit to fixing it any soon]

p.