Hello list,

sorry for top-posting: Outlook is a pain.

Anyway, more to the point: I’ve experimented at bit more with this, and it seems that mode=legacy for the backend at least does/tries the search operation on the respective meta backends for finding the concrete backend that allows identity assertion of the incoming user (with properly rewritten DN), but does not authenticate that connection, i.e. tries to anonymously search on the backends to find the user object. I’ve not found a combination of parameters to authenticate the connection for search in meta_search_dobind_init, but from what I can tell from the source, the connection used for the initial bind should actually be authenticated with the idassert binddn and credentials (for bindmethod=simple without proxyAuthz). Apparently, it isn’t. (again, the source isn’t the clearest, and as there’s no debugging information output by the actual functions called by meta_search_dobind_init, it’s rather hard to check the actual control flow for me).

I’m very hesitant to open the backends (which are active directory servers) up for anonymous accesses, which means that I’m still trying to get this to work (have two different active directory backends with different layouts unified under a single read-only proxy which allows authentication in both directories and delivers results from both). If there’s anybody who has this operating successfully, I’d very much love a heads up to any configuration errors and/or problems in understanding I have to fix this.

Have a pleasant day!

--- Heiko.

Von: openldap-technical <openldap-technical-bounces@openldap.org> Im Auftrag von Heiko Wundram
Gesendet: Donnerstag, 12. Dezember 2019 17:58
An: openldap-technical@openldap.org
Betreff: back-meta with overlapping DN spaces; bind operation does not find applicable target

Hello list,

I’m trying to get back-meta running with two backends who have distinct namespaces, but should be exposed in an overlapping DN space, and while search operations and result transformations work fine, I’m having trouble getting the bind operation to try both directories for the login (after bindDN rewrite rules have been applied). It seems that meta_search_dobind_init does not accept the DN as a candidate, unless the match is unique (either through the global URI namespace definition, or through subtree-exclude rules).

Both configurations have an idassert-bind set up with mode none, and also use the pseudo-root to bind when resolving. The configuration is as follows:

# Database binding to active directories

# --------------------------------------

database meta

suffix "<basesuffix>"

protocol-version 3

norefs yes

lastmod off

rebind-as-user yes

readonly yes

# Primary database in old LDAP structure

# --------------------------------------

uri "ldap://dc01/<basesuffix>"

chase-referrals no

default-target

idassert-bind bindmethod=simple

    binddn="<binddn1>"

    credentials="<bindpw1>"

    mode=none

subtree-exclude dn.subtree:"ou=subsubou,ou=subou,<basesuffix>"

# Secondary database in new LDAP structure

# ----------------------------------------

uri "ldap://dc02/ou=subou,<basesuffix>"

chase-referrals no

idassert-bind bindmethod=simple

    binddn="<binddn2>"

    credentials="<bindpw2>"

    mode=none

When binding as a user under <basesuffix> and not under ou=subou, this works fine and selects the first target to authenticate the user data. When binding as a user under ou=subsubou,ou=subou, this also works fine, and selects the second target to authenticate the user; both apply the corresponding baseDN transformations that are set up for the corresponding target. The problem starts when binding as user under ou=subou:

5df270ec conn=1000 op=0 meta_back_getconn: candidates=2 conn=ANON-TLS inserted

5df270ec conn=1000 op=0 >>> meta_back_search_start[0]

5df270ec conn=1000 op=0 >>> meta_search_dobind_init[0]

5df270ec conn=1000 op=0 <<< meta_search_dobind_init[0]=0

5df270ec conn=1000 op=0 <<< meta_back_search_start[0]=0

5df270ec conn=1000 op=0 >>> meta_back_search_start[1]

5df270ec conn=1000 op=0 >>> meta_search_dobind_init[1]

5df270ec conn=1000 op=0 <<< meta_search_dobind_init[1]=0

5df270ec conn=1000 op=0 <<< meta_back_search_start[1]=0

5df270ec conn=1000 op=0 meta_back_search: ncandidates=0 cnd="**"

5df270ec conn=1000 op=0 meta_back_search: base="cn=someuser,ou=subou,<basesuffix>" scope=0: no candidate could be selected

I’ve tried to follow meta_search_dobind_init as to which part of the code causes the candidate to be rejected, but I’ve not found any specific part which would cause this/make clear why both candidates aren’t applicable. Setting acl-authcDN and acl-passwd for the target also shows the same behaviour.

Is this a known restriction for back-meta, or am I missing some configuration?

Thank you for any hints!

--- Heiko.