redundant-load-balance and Ldap-Group

[tnt at kalik.net]

You don't want to post the debug and users file entries so that we can
help?

Ivan Kalik
Kalik Informatika ISP


Dana 20/10/2008, "Elizabeth Steinke" <liz at twistedpair.cc> piše:

>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
>>>
>>
>>
>