Multiple incoming requests from unknown clients

[Diego Matute]

"different authentication methods" I really mean different user data stores
and different methods like an optional second factor. I can wrap everything
is a custom auth module, however I will still need a way to know which data
store to use.

I could use NAS, but that would require the client to declare their IP
address. I was hoping for a solution where the client IP is not known and
the right thing is done based on some attributes not cumbersome for a
client to supply.

On Tue, Aug 14, 2012 at 9:58 AM, Fajar A. Nugraha <list at fajar.net> wrote:

> On Tue, Aug 14, 2012 at 8:40 PM, Diego Matute <dmatute at cyphercor.com>
> wrote:
> > The use case is configuring FreeRADIUS to accept requests from unknown
> > clients with different policies. By different policies I mean different
> > authentication methods. I thought the secret key could be used to
> > differentiate the calls and apply the correct policy. Have I missed
> > something here?
>
> what "different authentication methods"? Did you mean something like
> PAP vs EAP? If yes, FR does that automatically.
>
> >
> > The domain names and potentially IP addresses clients use to configure
> the
> > target RADIUS server could differ. However, in the backend there would
> be a
> > single server servicing requests. Not a big fan of this approach. Another
> > way would be requiring the client to configure additional attributes to
> be
> > passed down in the request.
>
> realms and NAS IP address are also attributes. You can (for example)
> select which backend to use (e.g. which sql server, or whether to use
> LDAP vs perl) based on certain attributes (including realm and NAS IP
> address) using unlang: http://freeradius.org/radiusd/man/unlang.html
>
> --
> Fajar
> -
> 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/20120814/dcf1df75/attachment.html>