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

Reply via email to