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 <[EMAIL PROTECTED]> 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
