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.