I'm looking to better understand the relationship in packet ordering when it comes to bind requests. As far as I've learned so far I can send a few ldap requests and potentially get responses in an order that doesn't match what i've sent.
When it comes to, for example, sending a bind, a search, a bind (different user), and a search, when I send those serially without waiting for a response, are there any guarantees around getting successful bind responses before search results? Is it guaranteed that I would get a bind result from the second bind before search results from the second search? Is it guaranteed the second bind result would come after the end of the first search results, or might I receive the second bind result before the end of the first set of search results (or even in the middle of the second set of search results)?
Then when it comes to server side processing, is it guaranteed that the first search is executed with the authorization of the first bind, and second search executed with the authorization of the second bind? Or is there a way the second search is processed before the second bind?
How does openldap manage changing authorization in the middle of an executing search? If the first search is in flight and the second bind request comes in, does the first search continue to execute and finish with the authorization of the first bind?
Are you aware of clients or tools that leverage that multi request (without waiting for a response) capacity of ldap? In what types of applications might a client send many requests without waiting for any responses?
Thanks for the consideration Tom
thomaswilliampritchard@gmail.com wrote:
I'm looking to better understand the relationship in packet ordering when it comes to bind requests. As far as I've learned so far I can send a few ldap requests and potentially get responses in an order that doesn't match what i've sent.
When it comes to, for example, sending a bind, a search, a bind (different user), and a search, when I send those serially without waiting for a response, are there any guarantees around getting successful bind responses before search results? Is it guaranteed that I would get a bind result from the second bind before search results from the second search? Is it guaranteed the second bind result would come after the end of the first search results, or might I receive the second bind result before the end of the first set of search results (or even in the middle of the second set of search results)?
Then when it comes to server side processing, is it guaranteed that the first search is executed with the authorization of the first bind, and second search executed with the authorization of the second bind? Or is there a way the second search is processed before the second bind?
How does openldap manage changing authorization in the middle of an executing search? If the first search is in flight and the second bind request comes in, does the first search continue to execute and finish with the authorization of the first bind?
No. RFC 4511 section 4.2 is explicit about this.
Are you aware of clients or tools that leverage that multi request (without waiting for a response) capacity of ldap? In what types of applications might a client send many requests without waiting for any responses?
Badly written applications that ignore the RFCs.
Thanks for the consideration Tom
On 3/25/22 15:40, thomaswilliampritchard@gmail.com wrote:
When it comes to, for example, sending a bind, a search, a bind (different user), and a search, when I send those serially without waiting for a response, are there any guarantees around getting successful bind responses before search results?
No. This does not work.
You could use two separate LDAP connections: 1. for identifying the user with an asynchronous search operation and 2. for sending bind operations synchronously waiting for the bind response. This might save some round-trips at lower level.
Or you're verifying the password hash and password policy yourself. This would require that the LDAP client has read access to password hashes.
Or in case the server is a recent OpenLDAP slapd then you might want to look into using the Verify Credentials extended operation.
Ciao, Michael.
On Fri, Mar 25, 2022 at 06:25:23PM +0100, Michael Ströder wrote:
Or you're verifying the password hash and password policy yourself. This would require that the LDAP client has read access to password hashes.
Or in case the server is a recent OpenLDAP slapd then you might want to look into using the Verify Credentials extended operation.
AFAIK you don't even need to do that, the behera ppolicy draft suggests[0] Compares should be processed in a very similar way without destroying connection state and ppolicy implements that. Not sure about the ACL requirements but that should be easy to figure out.
[0]. https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy-11#s...
On 3/28/22 10:55, Ondřej Kuzník wrote:
On Fri, Mar 25, 2022 at 06:25:23PM +0100, Michael Ströder wrote:
Or you're verifying the password hash and password policy yourself. This would require that the LDAP client has read access to password hashes.
Or in case the server is a recent OpenLDAP slapd then you might want to look into using the Verify Credentials extended operation.
AFAIK you don't even need to do that, the behera ppolicy draft suggests[0] Compares should be processed in a very similar way without destroying connection state and ppolicy implements that.
I'd very much appreciate if that would work.
But it doesn't:
https://bugs.openldap.org/show_bug.cgi?id=4366
Any chance to see this implemented in 2.6.x?
Not sure about the ACL requirements but that should be easy to figure out.
The argument against using COMPARE operation was always that it violates the X.500 model. But I disagree because userPassword should not be readable (by ACL) and there's ppolicy_hash_cleartext anyway.
Ciao, Michael.
openldap-technical@openldap.org
-
Howard Chu -
Michael Ströder -
Ondřej Kuzník -
thomaswilliampritchard＠gmail.com