Help mixing proxied and non-proxied auth mechanisms
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!
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help mixing proxied and non-proxied auth mechanisms
Geoff Silver <[EMAIL PROTECTED]> 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help mixing proxied and non-proxied auth mechanisms
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). - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help mixing proxied and non-proxied auth mechanisms
Geoff Silver <[EMAIL PROTECTED]> 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help mixing proxied and non-proxied auth mechanisms
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help mixing proxied and non-proxied auth mechanisms
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
