On Tue, Nov 9, 2010 at 8:10 PM, Mark J. Reed markjreed@gmail.com wrote:
To be clear, whether you have to bind at all is up to the server, but you only ever have to bind once per connection, not once per search request or other operation.
Thanks for the explanation.
My question is how long does the connection stay valid? If this is a configurable parameter of the server, how does the client know if the connection is still valid before trying the next operation? Is failure of the operation the only way for the client to know that the connection has expired? Or can there be a more graceful way by which the client can detect that the connection is about to expire (or just expired) and can reconnect before trying the next LDAP operation?
There is no way to present credentials without a bind; that's what binding is for. But an implementation may allow the bind to be skipped entirely and assume anonymous access. To be maximally portable, though, even if using anonymous access, you should do an explicit bind (a simple bind with an empty password is anonymous - even if a username is specified).
On Tuesday, November 9, 2010, Shankar Anand R shankaranand@gmail.com wrote:
On Tue, Nov 9, 2010 at 2:22 PM, Hallvard B Furuseth <
h.b.furuseth@usit.uio.no> wrote:
Someone who knows Active Directory might give better answers, since your remaining questions relate to the server, not the client. Try your sysadmin, ldap@umich.edu, or some AD-specific group.
Shankar Anand R writes:
If the client does a ldap_search() without doing a ldap_bind() how /
where
does it present its credentials to the server? When I tried a
ldap_search()
without doing a ldap_bind() I got an error that said "A successful bind should have been done before this operation". This was with an OpenLDAP client and Active directory 2008 server.
Ah, OK. In that case you just have to do what the server says. The LDAP spec doesn't require it but the server may, as you see.
Can you kindly tell me the minimum, default and maximum timeout values?
Or
point me to documentation that talks about them?
As far as the LDAP spec is concerned there aren't any. Check with your server's sysadmin, these may be per-server settings (if they are set).
You should be prepared for losing the connection (LDAP_SERVER_DOWN), e.g. due to an idletimeout set in the server. If so, to ldap_unbind, connect and Bind again, and proceed.
Is there any way (for example, a part of bind reply) for the LDAP client
to
get to know about the session timeout so that the client can try to
unbind
and bind again before session expiry? Or does the client know about
session
expiry only after one of its LDAP operations fail with LDAP_SERVER_DOWN?
The latter. Well, the client cal poll for results asynchronously even if it isn't expecting any, and check for LDAP_SERVER_DOWN.
I tried making a call to ldap_result() even though I was not expecting
any results. I made this call just before doing an ldap_bind() and also just after calling the ldap_result() that fetched the bind result. Both the times ldap_result() returned 0 and the LDAP_OPT_RESULT_CODE gave me LDAP_TIMEOUT (-5).
The first call to ldap_result() was before binding. Here the session was
not yet established. The second call was after a successful ldap_bind(). I don't understand why I was getting the result mentioned above in both the cases.
What is the expected reply from ldap_result() when there is no operation
result currently expected but the session is still valid? Is it the right / only way for a client to poll a server to check if the session has expired its time to do a ldap_bind() again? Is there any other way out?
- Shankar
-- Mark J. Reed markjreed@gmail.com