redundant LDAP-Group

[Phil Mayers]

On 02/12/10 11:54, Alexander Clouter wrote:

> It would be really nice to fold those duplicate LDAP-Group lines into
> 'ldap_login-LDAP-Group', however alas FreeRADIUS does not love me:
> ----
> /etc/freeradius/LOCAL/users-login[1]: Parse error (check) for entry DEFAULT: Invalid octet string "it-switch-admin" for attribute name "ldap_login-LDAP-Group"
> Errors reading /etc/freeradius/LOCAL/users-login

AFAICT this doesn't really work because of the way the attributes 
comparisons are actually handled.

You probably know this, but: Basically when a copy of the "ldap" module 
is instantiated, it registers a "paircompare" handler for the global 
"LDAP-Group", then if the module is named:

  1. Registers a new attribute "modname-LDAP-Group"
  2. Registers a "paircompare" handler for that attribute

The "redundant" construct has no way to know about this; the "ldap" 
module(s) are instantiated (and the attribute/comparisons registered) 
completely separately from the redundant{} processing.

Similar problems hold for the %{modname:} xlat stuff; modules can 
potentially register any xlat they like, and the modgroup code doesn't 
know about that.

In addition, the "paircompare" handlers currently don't return an error 
status; they just return an integer, 0 meaning "equality", so a 
redundant paircompare would have no way of distinguishing a "LDAP OK, 
user not in group" from "LDAP down, try next module", and would end up 
querying both LDAP modules much of the time.