Redundant Ldap Configuration + More groups

nikitha sumi.techno at gmail.com
Wed Feb 28 06:42:03 CET 2007


Hi Alan,

Thanks for your information.

Regards,
Nikitha

On 2/17/07, Alan DeKok <aland at deployingradius.com> wrote:
>
> nikitha wrote:
>
> > When the request comes to the radius server, it goes one entry by entry
> > in "users" file, ie., It connects to ldap-server-1 with the Ldap-Group
> > tries from g1 till g20, and then connects to ldap-server-2 with
> > Ldap-Group from "g21' till g50. If the user is part of Ldap-group "g50"
> > it takes more time to return success, before itself the request times
> > out, and received eap start again from wireless client.
>
>   Yes.  The LDAP query results aren't cached.
>
> > If the "number of DEFAULT entry for ldap-server-1" is less than 10, then
> > it works fine. If the default entry increases, the server takes more
> > time to process.
>
>   Yes, the solution is to not configure so many queries that the server
> slows down.
>
> > I think redundant ldap server configuration is not correct or in some
> > otherway we can fix it. Is it possible to configure the radius server in
> > such a way that, try ldap-server-1 for the first policy, if its
> > reachable then check it against the next policy.
>
>   For LDAP-Group checking, no.
>
> > If its not reachable mark this server as dead or whatever and ignore
> > processing the next coming DEFAULT entries which matches with
> > ldap-server-1 and try to process  ldap-server-2 entries.
>
>   That may be possible with source code patches.  i.e. If an LDAP server
> is marked "dead", don't try to contact it for a few seconds.  That would
> help your configuration a lot.  But your configuration is an artificial
> one that highlights a problem.
>
>   Alan DeKok.
> --
>   http://deployingradius.com       - The web site of the book
>   http://deployingradius.com/blog/ - The blog
> -
> 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/20070228/54fcf7b7/attachment.html>


More information about the Freeradius-Users mailing list