I'm hoping to simply my users file, and I'm hoping someone can help. Right now I have something like the following. users file: --------- user01 Auth-Type:=Accept, Huntgroup-Name=="Office", Hint==Port-1812 Connect-Info="OFFICE_NET" user01 Huntgroup-Name=="Office", Hint==Port-1645, Proxy-To-Realm := PROXY_GW Connect-Info="OFFICE_NET" hints: ----- DEFAULT User-Name =~ "^(.*)$" Hint = "Port-%{request:Packet-Dst-Port}" proxy.conf: ---------- proxy server { synchronous = no retry_delay = 5 retry_count = 1 dead_time = 300 default_fallback = yes # enable post_proxy_authorize to get our local radius instance to # send back the connect-info on successful auth post_proxy_authorize = yes } realm PROXY_GW { type = radius authhost = 10.1.2.3:1812 secret = mys3kr1t } Basically, if "user01" connects on port 1812, all we do is the authorize step. If they're in the users file, they get access. If not, they don't. If "user01" connects on port 1645, we want to proxy their authentication to another radius server, and we want to do authorization locally against this file. So, right now, for every huntgroup/connect-info pair, I have *two* entries in the users file. One is for Port-1812, the other for Port-1645. So the question of the hour is: Is there something nifty I can do to eliminate the need for *two* nearly-identical entries for each user? Thanks!
Geoff Silver <geoff+freeradius@uslinux.net> wrote:
So, right now, for every huntgroup/connect-info pair, I have *two* entries in the users file. One is for Port-1812, the other for Port-1645. So the question of the hour is: Is there something nifty I can do to eliminate the need for *two* nearly-identical entries for each user?
Yes. Another layer of indirection should do it. From what you've said, it looks like the "users" file entries are all the same, except for the username. That should help you narrow down potential solutions. You appear to have two independent requirements: 1) port 1645 versus 1812 checks 2) allowing only known users The first can be solved by what you have. The second can be solved by putting all of the known users into a group (see rlm_passwd). Then, in the "users" file, do: DEFAULT My-Group != "known", Auth-Type := Reject DEFAULT Auth-Type:=Accept, Huntgroup-Name=="Office", Hint==Port-1812 Connect-Info="OFFICE_NET" DEFAULT Huntgroup-Name=="Office", Hint==Port-1645, Proxy-To-Realm := PROXY_GW Connect-Info="OFFICE_NET" Alan DeKok.
Alan DeKok wrote:
You appear to have two independent requirements:
1) port 1645 versus 1812 checks 2) allowing only known users
The first can be solved by what you have. The second can be solved by putting all of the known users into a group (see rlm_passwd). Then, in the "users" file, do:
DEFAULT My-Group != "known", Auth-Type := Reject
DEFAULT Auth-Type:=Accept, Huntgroup-Name=="Office", Hint==Port-1812 Connect-Info="OFFICE_NET" DEFAULT Huntgroup-Name=="Office", Hint==Port-1645, Proxy-To-Realm := PROXY_GW Connect-Info="OFFICE_NET"
That will work for the simple case I provided, but my users file is actually a bit more complicated. There are multiple NAS-IP-Address and/or Huntgroups available, and not all users have access to all of them. The only thing guaranteed is that any user who *has* an entry actually has two, one with a Hint==Port-1645 and the other with Hint--Port-1812. Perhaps a better users file example would be: user01 Auth-Type:=Accept, NAS-IP-Address==10.1.2.3, Hint==Port-1812 user01 Auth-Type:=Accept, NAS-IP-Address==10.1.2.4, Hint==Port-1812 user01 NAS-IP-Address==10.1.2.3, Hint==Port-1645, Proxy-To-Realm:=PROXY_GW user02 Auth-Type:=Accept, NAS-IP-Address==10.1.2.3, Hint==Port-1812 user03 NAS-IP-Address==10.1.2.4, Hint==Port-1645, Proxy-To-Realm:=PROXY_GW Additionally, none of these folks have (or can have) /etc/passwd accounts on this system, so I'm not sure that rlm_passwd will work for me necessarily (plus, we're back to the "not every user has access to every NAS/Huntgroup" problem).
Geoff Silver <geoff+freeradius@uslinux.net> wrote:
Additionally, none of these folks have (or can have) /etc/passwd accounts on this system, so I'm not sure that rlm_passwd will work for me necessarily
Please read the docs & man page for rlm_passwd. It does *not* read /etc/passwd.
That will work for the simple case I provided, but my users file is actually a bit more complicated. There are multiple NAS-IP-Address and/or Huntgroups available, and not all users have access to all of them. The only thing guaranteed is that any user who *has* an entry actually has two, one with a Hint==Port-1645 and the other with Hint--Port-1812.
I suggest writing down the specific situations involved. Include inputs and outputs. That will help drive the design. The FreeRADIUS configuration is powerful enugh that you should be able to map your requirements onto some combination of modules and config files. But *first* write down your requirements. Failure to do that means you'll be making endless random changes to the config in the hope that "maybe this works". Alan DeKok.
Alan DeKok wrote:
Please read the docs & man page for rlm_passwd. It does *not* read /etc/passwd.
I read the doc/rlm_passwd doc, but I'll go over it again and take a look at the code as well. Being called rlm_passwd, I may have assumed it used /etc/passwd before I even started reading it, thus tainting what I read.
I suggest writing down the specific situations involved. Include inputs and outputs. That will help drive the design.
So here is the specific requirement. * I need FreeRadius to listen on two different udp ports for auth requests. This is because we presently allow both password authentication with users file authorization *and* users file authorization only modes. The latter is used to support certificate-based authenticate via our Cisco 3000-series concentrators (the Cisco authenticates you against your certificate and radiusd decides whether you're actually authorized to use that NAS). * The port can't be shared because in the authorization-only method, the password that gets sent is your username, and because no VSAs or other identifying attributes get sent with that type of request. Therefore, if I shared the port, anyone could authenticate as user "bob" with password "bob". * In our case, I am using port 1645 for authentication + authorization and port 1812 for authorization only. * I need FreeRadius to proxy the authentication requests it receives on the authentication + authorization port, and do local users file authorization, and return any Connect-Info, Filter, Class, etc strings related to that user/nas pair back to the originating NAS. * The authorization-only requests just need to see if the user is in the users file for that NAS/Huntgroup, and return any related attributes (eg. Connect-Info, filter, Class, etc) to the originating NAS. * All users can use both auth methods (ie. nobody can do only certificate authentication but not have a corresponding password). * Users may have access for multiple NASes. * Not all users have access for all (or the same) NASes. * I "need" to have only one entry in the users file for each user. I already have this working with two entries, but it feels inefficient and just isn't pretty. I *think* this covers it appropriately.
Geoff Silver wrote:
DEFAULT My-Group != "known", Auth-Type := Reject
DEFAULT Auth-Type:=Accept, Huntgroup-Name=="Office", Hint==Port-1812 Connect-Info="OFFICE_NET" DEFAULT Huntgroup-Name=="Office", Hint==Port-1645, Proxy-To-Realm := PROXY_GW Connect-Info="OFFICE_NET"
That will work for the simple case I provided, but my users file is actually a bit more complicated. There are multiple NAS-IP-Address and/or Huntgroups available, and not all users have access to all of them. The only thing guaranteed is that any user who *has* an entry actually has two, one with a Hint==Port-1645 and the other with Hint--Port-1812.
Perhaps a better users file example would be:
user01 Auth-Type:=Accept, NAS-IP-Address==10.1.2.3, Hint==Port-1812 user01 Auth-Type:=Accept, NAS-IP-Address==10.1.2.4, Hint==Port-1812 user01 NAS-IP-Address==10.1.2.3, Hint==Port-1645, Proxy-To-Realm:=PROXY_GW user02 Auth-Type:=Accept, NAS-IP-Address==10.1.2.3, Hint==Port-1812 user03 NAS-IP-Address==10.1.2.4, Hint==Port-1645, Proxy-To-Realm:=PROXY_GW
Additionally, none of these folks have (or can have) /etc/passwd accounts on this system, so I'm not sure that rlm_passwd will work for me necessarily (plus, we're back to the "not every user has access to every NAS/Huntgroup" problem).
rlm_passwd would be better named "rlm_lookup" or "rlm_mapping" or "rlm_keyval". I use it very successfully after a hint from Alan to cut down combinatorial explosion: modules { passwd nas2kind { file = /etc/raddb/nas2kind format = "*NAS-IP-Address:~NasKind" } passwd user2group { file = /etc/raddb/user2group format = "*User-Name:~Group" } } authorize { preprocess nas2kind user2group users } /etc/nas2kind: 10.1.2.3:type1 10.1.2.4:type2 /etc/user2group: user01:nasgroup1-p1812 user01:nasgroup2-p1812 user01:nasgroup1 user02:nasgroup1-p1812 user03:nasgroup2-p1812 /etc/raddb/users: # Skip unknown users DEFAULT Group !* ANY, Auth-Type := Reject DEFAULT Group=="nasgroup1-p1812", NasKind=="type1", Hint==Port-1812, Auth-Type := Accept DEFAULT Group=="nasgroup2-p1812", NasKind=="type2", Hint==Port-1812, Auth-Type := Accept DEFAULT Group=="nasgroup1", NasKind=="type1", Hint==Port-1645, Proxy-To-Realm := PROXY_GW DEFAULT Group=="nasgroup2", NasKind=="type2", Hint==Port-1645, Proxy-To-Realm := PROXY_GW Hopefully that's clear. Note that the passwd instances are defined to add the values to the request (because it's hard to match on == for config/reply items in users) so you'll need to make sure those value names are in a local dictionary somewhere. Note also that the above is a literal translation of your most recent email - I believe in your original email you matched on Huntgroup-Name, in which case you can skip the NasKind mapping and simplify things somewhat.
participants (3)
-
Alan DeKok -
Geoff Silver -
Phil Mayers