LDAP redundant with LDAP-Group within users file

[Alexander Clouter]

Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> 
>> Not as easy as it sounds ;-) 12 radius pairs (singe server with the 
>> same config) at 10 locations, 3 ldap server at 3 different locations 
>> For countervail lost of one or two locations, loadbalancing will be 
>> very complex.
> 
If the three sites have an IGP running between them (OSPF, EIGRP, iBGP, 
ISIS, whatever) then you can anycast the ldap servers.  No single point 
of failure and cheap to do.

<self-promo>
http://www.digriz.org.uk/ha-ospf-anycast
</self-promo>

It does not have a LDAP example, but you can trivially take the RADIUS 
or DNS probe and modify it to use ldapsearch.

> Sure.
> 
> People are looking into better LDAP failover in "redundant {}" stanzas. 
> LDAP-Group is a bit harder though.
>
A quick hack would be to use rlm_exec if you do not have have a high 
RADIUS packet rate, the alternative would be rlm_perl/rlm_python.  I'm 
happy to put something like this together as we could benefit from it.

I envision it working by in the users file you fill up an attribute 
(say, 'Foobar-Ldap-Group') with the group checks you want to make and an 
Accept[1].  The module would check for the presence of the attribute, 
and Ldap-User-Dn (if not, be a noop) and flip the Accept to Reject if 
things do not work out.

Another ways would be to pass an LDAP filter from user/unlang in a 
similar manner (multi-value attribute that's concatinated).

It would at least take the presure off needing LDAP-Group to be 
redundant today.

Cheers

[1] for use, we have typically use the following type of thing (or it's 
		inverse with a follow through clause):
	Huntgroup == foo, Ldap-Group == cheesy, Auth-Type := Accept
	Huntgroup == foo, Ldap-Group == chips, Auth-Type := Accept
	Huntgroup == foo, Auth-Type := Reject

-- 
Alexander Clouter
.sigmonster says: Don't compare floating point numbers solely for equality.