[Date Prev][Date Next]
Re: Is ldap_bind() mandatory before each ldap_search() call?
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.
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 <firstname.lastname@example.org> wrote:
> On Tue, Nov 9, 2010 at 2:22 PM, Hallvard B Furuseth <email@example.com> wrote:
> Someone who knows Active Directory might give better answers, since
> your remaining questions relate to the server, not the client. Try
> your sysadmin, firstname.lastname@example.org, 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 <email@example.com>