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
