force exit on instanciated ldap module

[Alan DeKok]

On Nov 2, 2016, at 1:31 PM, Ramon Escriba <escriba at cells.es> wrote:
> I'm running a Radius 3.0.10, the config it's working fine, I just ask for advice to do one step in a faster way.
> 
> I've declared multiple LDAP instances "vlan1,vlan2....vlanN" in /etc/raddb/mods-enabled/ldap . 
> Each one queries  just the ldap subtree assigned to a particular vlan.
> Each vlan subtree contains it's allowed mac's (uid=mac)
> Each mac (uid) has all needed radius attributes for the radius accept packet, that are populated from ldap. 

  OK.

> Actually, all ldap instancies are asked for every "uid=mac" in order sequence, so if there's a match, the attributes are updated from the ldap.

  The recommended approach is to figure out which LDAP server the user belongs to, and query just that one.  Querying all of them is inefficient, and wastes time.  It's also more complex.

> Unfortunately , If one "mac"  matches two ldap instances (ex: vlan1 & vlan2), the last matched instance(vlan2)  overwrites the previous populated attributes(vlan1).

  That's how the LDAP module works.

> My goal is somehow to stop ldap executing the next instances(vlan2,vlan3...N) if the actual one(vlan 1) got the jackpot, to avoid so many ldap queries.

  Why not figure out which LDAP server the user belongs to, and query just that one?

  i.e. have one mapping table of MAC to LDAP server, and the query just that one?

  Or, why do you need 4 LDAP servers in the first place?  Especially because they have overlapping data.  That's a nightmare to manage, and looks like you're just putting random MACs into random LDAP servers, which makes no sense.

> Right now I'm forced to use a inverse priority ( the last match got the jackpot), that is not the right solution. 
> Any clues, or advice?

  The config you posted should work.  If the information is found in ldap server 1, it returns, and doesn't check ldap server 2.

  Alan DeKok.