@@ -270,6 +270,30 @@ For example, if your users have DN strings in the form
270270``uid=einstein,dc=example,dc=com ``, then the ``dn_string `` will be
271271``uid={username},dc=example,dc=com ``.
272272
273+ query_string
274+ ............
275+
276+ **type **: ``string ``
277+
278+ This (optional) key enables the user provider to search for a user and
279+ then use the DN found for the bind process. This is useful in environments
280+ with multiple LDAP user providers with a different ``base_dn ``. As value
281+ a valid search string for should be used, e.g. ``uid="{username}" ``. The
282+ placeholder value will be replaced by the actual username.
283+
284+ When this key is used, ``dn_string `` has to be adjusted accordingly and
285+ should reflect a common denominator as base DN.
286+
287+ Extending the previous example: If Your users have two different DN in the
288+ form of ``dc=companyA,dc=example,dc=com `` and ``dc=companyB,dc=example,dc=com ``,
289+ then ``dn_string `` should be ``dc=example,dc=com ``. In conjunction with
290+ ``uid="{username}" `` as ``query_string `` the authentication provider can
291+ authenticate user from both DN.
292+
293+ Please bear in mind, that the usernames themselves have to be unique
294+ across both DN, as the authentication provider won't determine the
295+ correct user for the bind process if more than one are found.
296+
273297Examples are provided below, for both ``form_login_ldap `` and
274298``http_basic_ldap ``.
275299
0 commit comments