redundant-load-balance and Ldap-Group

[Elizabeth Steinke]

Since we have other applications that don't and probably never will preform
redundant LDAP lookups I'm thinking I will just an LDAP VIP to the LVS
server.
I am still willing to try an solutions in my lab for the sake of having it
in the list archives :)


2008/10/19 Elizabeth Steinke <liz at twistedpair.cc>

> Hi!
>
> I commented out the deny rule and it exhibits the same behavior. I am at a
> loss on this on.
>
>
> 2008/10/19 <tnt at kalik.net>
>
> Same huntgroup - different ldaps; you can't have DEFAULT lines rejecting
>> users then. Comment them out and see if it works.
>>
>> Ivan Kalik
>> Kalik Informatika ISP
>>
>>
>> Dana 19/10/2008, "Elizabeth Steinke" <liz at twistedpair.cc> piše:
>>
>> >Greetings!
>> >I'm having an odd problem trying to implement load balancing/redundancy.
>> I
>> >have added the following lines to my radiusd.conf
>> >
>> >authorize {...
>> >#
>> ># We want redundant ldap lookups
>> >##
>> >redundant-load-balance {
>> >        ldap1
>> >        ldap2
>> >}
>> >##
>> ># end redundancy
>> >##
>> > }
>> >
>> >modules (...
>> >
>> >  ldap ldap1 {
>> >        }
>> >
>> >  ldap ldap2 {
>> >        }
>> >
>> > }
>> >
>> >
>> >Scenarios:
>> >
>> >This occurs using freeradius 1.1.7 (built from source)  on a centos 5
>> box.
>> >If they both are specified correctly everything appears to work ok .
>> >
>> >When I purposely break ldap1 it works great and uses ldap2 for the LDAP
>> >lookup.
>> >
>> >When I break ldap2 and correct the IP address ldap1 is using to do
>> lookups I
>> >get an access-reject packet back.
>> >
>> >Here is the snippet of the log (I am posting it for brevity, I will be
>> more
>> >than happy to post all of radiusd -X)
>> >
>> >---log bits for when it rejects the attempt--
>> >
>> >lm_ldap:  ...some ldap server in ldap fairy land... failed: Can't contact
>> >LDAP server
>> >rlm_ldap: (re)connection attempt failed
>> >rlm_ldap::ldap_groupcmp: search failed
>> >rlm_ldap: ldap_release_conn: Release Id: 0
>> >    users: Matched entry DEFAULT at line 69
>> >
>> >here is rule 68-69:
>> >
>> >DEFAULT Huntgroup-Name =="some huntgroup", Auth-Type =
>> ntlm_auth_cleartext
>> >        Fall-Through = 1
>> >DEFAULT Huntgroup-Name == "some huntgroup",Ldap-Group != "someldapgroup",
>> >Auth-Type := Reject
>> >
>> >I can  then see rlm_ldap doing the lookup successfully on ldap1
>> >
>> >lm_ldap: ldap_get_conn: Checking Id: 0
>> >rlm_ldap: ldap_get_conn: Got Id: 0
>> >rlm_ldap: attempting LDAP reconnection
>> >rlm_ldap: (re)connect to ldap1:3268, authentication 0
>> >rlm_ldap: waiting for bind result ...
>> >rlm_ldap: Bind was successful
>> >rlm_ldap: performing search in dc=.....
>> >rlm_ldap: looking for check items in directory...
>> >rlm_ldap: Adding memberOf as Ldap-Group == "..."
>> >
>> >
>> >What I think is happening is since the LDAP lookup failed the user is
>> indeed
>> >not a user of the group (doesn't exist etc..)  so it matches on the
>> failure,
>> > since its first match it doesn't matter that is matches on the second
>> >lookup. It still gives me a failure. Is their a way keep it from
>> rejecting
>> >the attempt if ldap2 is down?
>> >
>> >
>>
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20081019/f997bacb/attachment.html>