clarify ldap schema calls

[cornelinux]

I also find that the schema queries are still remaining in most operations...
Would it be sensible in your opinion to have the ldap3.NONE as the default behavior for get_serverpool method instead? @quynh-axiadids (taken from #650)

ldap3 version 2.2.1

[fredreichbier]

I did some tests on the current master (070c4b3) with otppin=userstore and the /validate/check request, using the Flask integrated webserver. It seems to me that the schema queries are issued in refresh_server_info, so we should minimize the number of calls to that method.

• If we do not use STARTTLS, it seems like refresh_server_info is called 4 times in the first request, but only once in every subsequent request (EDIT: during the timeframe specified by CACHE_TIMEOUT, as it turns out)
• If we use STARTTLS, the method is called 12 times in the first request and 3 times in subsequent requests. In my understanding, we could pass read_server_info=False to both open() and start_tls() in create_connection to optimize this. Then, the method is called 4 times in the first request, but only once in subsequent requests (EDIT: during the CACHE_TIMEOUT timeframe). The ldap3 source code references Section 3.1.5 of RFC 4513, which states that clients should refresh the server capabilities after having established STARTTLS to mitigate MITM attacks. However, as the refresh_server_info call is performed in the bind (which happens with STARTTLS enabled), I think we should be good.

What do you think?

[quynh-axiadids]

I believe that the all the ldap schema query is made by ldap3.Server() call in our ldapresolver module get_server_pool method when the pass get_info is ldap3.SCHEMA. PrivacyIDEA has tried to optimize this with the ability to pass get_info with ldap3.NONE (no schema query). However, not all calls of get_server_pool pass get_info=ldap3.NONE, and the default value for get_info in get_server_pool is ldap3.SCHEMA, therefore the ldap schema queries are still made. For example in the _bind call etc. My request is to make ldap3.NONE be the default value if get_info for get_server_pool if that is also sensible for you and @cornelinux. In my environments, the ldap schema queries has zero effect, and sometimes even are not allowed by the ldap servers.

[fredreichbier]

I think we have multiple questions here:

• The number of calls to refresh_server_info influences how often the server information is fetched. If we are not using STARTTLS, this is once per connection (and we have four connections per authentication request (see Reduce number of LDAP connections per authentication request #664) if uncached, and only one if the user information are found in the cache). If we are using STARTTLS, this is three times per connection (open, start_tls, bind).
• The get_info option influences what is queried when the server information is fetched. If we set this to ldap3.NONE, refresh_server_info does not query schema information at all.

So, to reduce the number of schema queries, we should reduce the number of LDAP connections, for which I opened #664. For use cases that need schema information, I guess it makes sense to optimize the number of calls to refresh_server_info per connection in the case of STARTTLS. Finally, for the case that schema information are not needed at all, it may also be useful to make the value of get_info configurable. @cornelinux, what do you think?