specifying back end to proxy on per-user basis
We have a freeradius instance that talks to the world, and proxies requests to a back end server that does token authentication via the "otp" module. This all works fine. What we need is something we can do when a user forgets or loses their card. We thought to use S/key for this. To that end, I have another back end server that does s/key authentication via a PAM module. This too works, but I have to find a way to specify in the front end proxy on a per-user basis which back end server should be used. The first step to doing this was to set up a realm for the s/key server. In the proxy.conf file for the front end proxy, the NULL realm has authhost and secret are set up for the otp back end server. I created an SKEY realm that sets authhost and secret for the s/key back end server. So far so good; I can run "radtest" against the front end proxy server, and if I specify "user@SKEY" as the username, it proxies to the s/key back end and everything works great. The problem is that I can't figure out the magic incantation for the proxy front end to tell it that certain users should be in the SKEY realm. Am I basically on the right track as to the correct way to accomplish what I want? If so, what is the magic incantation to specify which users should be in the SKEY realm? If somebody could just point me down the right path, I'll be happy to read the relevant documentation to come up with the correct syntax, but I haven't found it yet. Thanks, --Greg
Greg Woods wrote:
We have a freeradius instance that talks to the world, and proxies requests to a back end server that does token authentication via the "otp" module. This all works fine. What we need is something we can do when a user forgets or loses their card. We thought to use S/key for this. To that end, I have another back end server that does s/key authentication via a PAM module. This too works, but I have to find a way to specify in the front end proxy on a per-user basis which back end server should be used.
Use groups, or *something* else. What's in the request packet that make S/key different from the other authentication modules? How can you distinguish between the two kinds of requests? Where is that information stored? Alan DeKok.
On Fri, 2008-08-22 at 20:25 +0200, Alan DeKok wrote:
Greg Woods wrote: I have to find a
way to specify in the front end proxy on a per-user basis which back end server should be used.
Use groups, or *something* else.
I can't find any information on groups except for the "chroot" group and huntgroups, and neither of those appears to be related to what I'm trying to do. I grepped all the config files and there's no "man 5 groups". Can you point me to the documentation on groups?
What's in the request packet that make S/key different from the other authentication modules?
Since the requests are all generated by the same clients, nothing is different. What I need is to be able to have certain users proxied to the s/key back end server, and the rest of them proxied to the default otp back end server. So whatever I come up with has to be able to key on the User-Name attribute.
How can you distinguish between the two kinds of requests?
Only by what the User-Name is.
Where is that information stored?
That is what I am trying to figure out. Certainly, the User-Name attribute is coming in as part of the Access-Request packet. I want to be able to decide, based on the value of that attribute, which realm it should be proxied to (or if realms isn't the right way to do this, in some way based only on User-Name I have to be able to proxy to different back end servers). It appears from the comments in the preproxy_users file that this may be where I should be doing this. But it doesn't work because the authorize section has previously determined the realm. I also tried using the users file to set Realm, overwrite User-Name with user@SKEY, and none of this worked either. While the debug output shows that the users entry matched, it doesn't actually change the value of Realm or User-Name. I always get something like this: rad_recv: Access-Request packet from host 127.0.0.1 port 58207, id=208, length=7 3 User-Name = "woods" User-Password = "CURRENT SKEY PASSPHRASE" NAS-IP-Address = 127.0.0.1 NAS-Port = 0 +- entering group authorize users: Matched entry woods at line 1 ++[files] returns ok rlm_realm: No '@' in User-Name = "woods", looking up realm NULL This is even if I have in users: woods User-Name := woods@SKEY Apparently User-Name is immutable. But it doesn't look like I can set Realm either because that is always determined from User-Name. Catch-22. rlm_realm: Found realm "NULL" rlm_realm: Adding Stripped-User-Name = "woods" rlm_realm: Adding Realm = "NULL" rlm_realm: Proxying request from user woods to realm NULL rlm_realm: Preparing to proxy authentication request to realm "NULL" ++[NULL] returns updated +- entering group pre-proxy preproxy_users: Matched entry woods at line 32 ++[files] returns ok In any case I think I have figured out that doing it in users isn't the right approach, because the documentation says this only modifies the reply, and a proxied request isn't exactly a reply. That's probably why this method doesn't work. But doing it in pre-proxy is obviously too late, as the realm is already determined by the time pre-proxy is entered. It actually works here to change the User-Name value to "woods@SKEY", but it's still proxying that new username to the NULL realm server. --Greg
Greg Woods wrote:
I can't find any information on groups except for the "chroot" group and huntgroups, and neither of those appears to be related to what I'm trying to do. I grepped all the config files and there's no "man 5 groups". Can you point me to the documentation on groups?
Use *any* kind of groups. Unix groups, groups in SQL, or groups defined on the server. See "man rlm_passwd" for an example.
Since the requests are all generated by the same clients, nothing is different. What I need is to be able to have certain users proxied to the s/key back end server, and the rest of them proxied to the default otp back end server. So whatever I come up with has to be able to key on the User-Name attribute.
See "man rlm_passwd". You will need to put the s/key users int a group, and proxy based on membership in that group.
Where is that information stored?
That is what I am trying to figure out.
No... where do *you* want to store the information about which user belongs in which group.
Certainly, the User-Name attribute is coming in as part of the Access-Request packet. I want to be able to decide, based on the value of that attribute, which realm it should be proxied to (or if realms isn't the right way to do this, in some way based only on User-Name I have to be able to proxy to different back end servers).
And where do you want to store that information?
It appears from the comments in the preproxy_users file that this may be where I should be doing this. But it doesn't work because the authorize section has previously determined the realm.
pre-proxy is done *after* the decision has been made to proxy the request.
Apparently User-Name is immutable. But it doesn't look like I can set Realm either because that is always determined from User-Name. Catch-22.
No. If you don't need the "realms" module, then delete the references to it. That's why the configuration files are editable. You *can* edit them. Alan DeKok.
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
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
Greg Woods wrote:
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.
That's realms. A lot of people do that.
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.
Yes. Much better. Alan DeKok.
participants (3)
-
Alan DeKok -
Anders Holm -
Greg Woods