specifying back end to proxy on per-user basis

[Anders Holm]

An SQL server isn't too hard to set up and get going. Plus any decent  
scripting language has modules making it dirt simple to manage the  
user base ... Try it...

//Anders

Sent from my iPhone

On 22 Aug 2008, at 22:23, Greg Woods <woods at ucar.edu> wrote:

> On Fri, 2008-08-22 at 22:48 +0200, Alan DeKok wrote:
>> See "man rlm_passwd" for an example.
>
> Thank you. That was the pointer I needed.
>
>>  No... where do *you* want to store the information about which user
>> belongs in which group.
>
> Anywhere that works. In other words, I'll write scripts to modify  
> config
> files. I understand that this is not the cleanest way to set something
> like this up. Using LDAP or SQL would be cleaner, but I really don't
> want to have to set up an LDAP or SQL server which might require
> expertise that I don't have as yet. This is something that will only  
> be
> used for a small number of users on a temporary basis only (when they
> forget or lose their token).
>
>
>>  pre-proxy is done *after* the decision has been made to proxy the  
>> request.
>
> Yes, I figured that out by trial and error and reading the debugging
> output.
>
>> You
>> *can* edit them.
>
> No kidding. But you have to know what to edit first.
>
> At any rate, I think that, for my purposes, it ends up working just as
> well to use the users file on the back end server instead, so that it
> can do multiple Auth-Types. That seems to work; I can make an entry  
> like
>
> woods Auth-Type := pam
>
> and that works right off the bat. There were other reasons why it  
> might
> have been nice to set the realm based on the user name; we're a  
> research
> institution, meaning that the groups here have a relatively high  
> degree
> of autonomy with little central control. It might have been nice to
> allow the various groups to run their own backend servers, and  
> choosing
> a back end based on the username would be a handy thing to be able to
> do. But just for the purpose at hand (being able to authenticate a few
> users with pam instead of otp), it works to just use the users file on
> the back end server to accomplish that. If I do try to do something
> organization-wide, it will probably be better to have some kind of
> database (LDAP or SQL) involved.
>
> --Greg
>
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html