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