On Nov 3, 2016, at 7:24 AM, Ramon Escriba <escriba@cells.es> wrote:
We only use one Ldap server. Each vlan has one subtree with all macs allowed to connect there. So a Ldap query, "the instance", does a mac search in only this vlan subtree. Maybe is not the use 'ldap instances' were designed to.
The issue isn't design. The issue is you're doing 4 times the queries necessary.
So a kind off multi evaluated field, it makes sense, but, how can I extract/use each of those individual fields via ldap?
That's largely up to you. A good part of system design is *design*. Design the database schema so that you need one query to get the data you need.
The config you posted should work. If the information is found in ldap server 1, it returns, and doesn't check ldap server 2. It worked fine in old v 1.1, but not in v3.0. Now, with v3.0.10, all ldap subtrees are checked anyway.
Well... read the debug log.
rlm_ldap (BL01): Opening additional connection (5), 1 of 27 pending slots used rlm_ldap (BL01): Connecting to ldap://127.0.0.1:389 rlm_ldap (BL01): Waiting for bind result... rlm_ldap (BL01): Bind successful (0) [BL01] = updated
Change the configuration to return on "updated", instead of "ok". Alan DeKok.