Greetings, I am configuring a general purpose RADIUS server that any number of clients can connect to for authn - it uses a PostgreSQL DB as the backend datastore. I would also like to setup a secondary RADIUS server listening on a different port (ie. 1814) and use the same Pg DB as a backend, but use a "restricted" view as the "users" table, then configure devices (certain network gear) that wish to only allow users in the "restricted" view to use that secondary RADIUS server and corresponding port. I am currently using Debian 6.0 with corresponding FR 2.1.10+dfsg-2+squeeze1. My questions are these: Has anyone here setup a second instance of FR running on the same system as their primary instance, but with different configs? Do you have any suggestions for layout or keeping configs/logs straight? Or said another way, how much confusion will there be in /etc/freeradius (default Debian config dir) due to the second instance? Is it worth it, just to have a single system have all of your RADIUS servers or should I just stand up another virtual server and use that instead? Thanks for any help or hints! -matt zagrabelny
On 04.03.2013 21:56, Matt Zagrabelny wrote:
Greetings,
I am configuring a general purpose RADIUS server that any number of clients can connect to for authn - it uses a PostgreSQL DB as the backend datastore. I would also like to setup a secondary RADIUS server listening on a different port (ie. 1814) and use the same Pg DB as a backend, but use a "restricted" view as the "users" table, then configure devices (certain network gear) that wish to only allow users in the "restricted" view to use that secondary RADIUS server and corresponding port.
You can use the same listen ports, but group clients (which mean NAS) in two groups, and assign a specific virtual server for each groups, with different policy, database lookup and such.
I am currently using Debian 6.0 with corresponding FR 2.1.10+dfsg-2+squeeze1.
Beware that there are some known bugs in 2.1.10 as well as some security flaws. you should go with the latest 2.2.X git branch Olivier -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org
On 04.03.2013 22:17, Olivier Beytrison wrote:
On 04.03.2013 21:56, Matt Zagrabelny wrote:
Greetings,
I am configuring a general purpose RADIUS server that any number of clients can connect to for authn - it uses a PostgreSQL DB as the backend datastore. I would also like to setup a secondary RADIUS server listening on a different port (ie. 1814) and use the same Pg DB as a backend, but use a "restricted" view as the "users" table, then configure devices (certain network gear) that wish to only allow users in the "restricted" view to use that secondary RADIUS server and corresponding port.
You can use the same listen ports, but group clients (which mean NAS) in two groups, and assign a specific virtual server for each groups, with different policy, database lookup and such.
Just to add, I think you should define a virtual server with a default virtual_server in the listen {} section, then for your specific NAS that needs special policy/authn, simply specify a different virtual_server in the client {} section I also wanted to add that you'll find all the information you need here http://wiki.freeradius.org/config/Virtual-server (but my @#°@¦§¬ mail client sent the mail instead of pasting the link) :) Olivier
On Mon, Mar 4, 2013 at 3:27 PM, Olivier Beytrison <olivier@heliosnet.org> wrote:
On 04.03.2013 22:17, Olivier Beytrison wrote:
On 04.03.2013 21:56, Matt Zagrabelny wrote:
Greetings,
I am configuring a general purpose RADIUS server that any number of clients can connect to for authn - it uses a PostgreSQL DB as the backend datastore. I would also like to setup a secondary RADIUS server listening on a different port (ie. 1814) and use the same Pg DB as a backend, but use a "restricted" view as the "users" table, then configure devices (certain network gear) that wish to only allow users in the "restricted" view to use that secondary RADIUS server and corresponding port.
You can use the same listen ports, but group clients (which mean NAS) in two groups, and assign a specific virtual server for each groups, with different policy, database lookup and such.
Just to add, I think you should define a virtual server with a default virtual_server in the listen {} section, then for your specific NAS that needs special policy/authn, simply specify a different virtual_server in the client {} section
I also wanted to add that you'll find all the information you need here http://wiki.freeradius.org/config/Virtual-server (but my @#°@¦§¬ mail client sent the mail instead of pasting the link) :)
Hi Olivier, Thanks for the replies. I'll start digesting that wiki page soon*. I'm not sure if Debian patched the 2.1.10 line to take care of any grievous bugs, but if we start hitting them, we may need to upgrade. FWIW, we were/are running 1.1.0 on Solaris, so we'll be excited to have the new bugs to deal with. :) Cheers, -mz
On 4 Mar 2013, at 15:56, Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
Greetings,
I am configuring a general purpose RADIUS server that any number of clients can connect to for authn - it uses a PostgreSQL DB as the backend datastore. I would also like to setup a secondary RADIUS server listening on a different port (ie. 1814) and use the same Pg DB as a backend, but use a "restricted" view as the "users" table, then configure devices (certain network gear) that wish to only allow users in the "restricted" view to use that secondary RADIUS server and corresponding port.
Um, ok, why? You know SQL supports groups right? and that a group matching can be conditional on attributes in the request? and that you can add aditional config items to client definitions to mark them as a special devices? -Arran
On Mon, Mar 4, 2013 at 4:28 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
You know SQL supports groups right? and that a group matching can be conditional on attributes in the request? and that you can add aditional config items to client definitions to mark them as a special devices?
Hi Arran, Thanks for the reply. I've grepped the wiki and mailing list archives and could not answer the following: What do I change in the nas table (in the database) to mark the network boxes as "special devices"? I see the schema as: CREATE TABLE nas ( id SERIAL PRIMARY KEY, nasname VARCHAR(128) NOT NULL, shortname VARCHAR(32) NOT NULL, type VARCHAR(30) NOT NULL DEFAULT 'other', ports int4, secret VARCHAR(60) NOT NULL, server VARCHAR(64), community VARCHAR(50), description VARCHAR(200) ); Is it the "server" field? If so, could you also briefly explain how to apply that to group matching? (I have added users to groups using the usergroup table, but haven't touched the radgroupcheck/reply yet.) Thanks for any help! -mz
On 5 Mar 2013, at 18:03, Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
On Mon, Mar 4, 2013 at 4:28 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
You know SQL supports groups right? and that a group matching can be conditional on attributes in the request? and that you can add aditional config items to client definitions to mark them as a special devices?
Hi Arran,
Thanks for the reply. I've grepped the wiki and mailing list archives and could not answer the following:
What do I change in the nas table (in the database) to mark the network boxes as "special devices"? I see the schema as:
CREATE TABLE nas ( id SERIAL PRIMARY KEY, nasname VARCHAR(128) NOT NULL, shortname VARCHAR(32) NOT NULL, type VARCHAR(30) NOT NULL DEFAULT 'other', ports int4, secret VARCHAR(60) NOT NULL, server VARCHAR(64), community VARCHAR(50), description VARCHAR(200) );
Is it the "server" field? If so, could you also briefly explain how to apply that to group matching? (I have added users to groups using the usergroup table, but haven't touched the radgroupcheck/reply yet.)
So long as you're using static devices in clients.conf you can use the xlat expansion "%{client:<config item>}". Add an extra string attribute to raddb/dictionary, something like Client-Group, then populate it before calling the sql module. authorize { update request { Client-Group := "%{client:group}" } sql } Then add a 'group' config item in the client {} definition. You can then use Client-Group as a check item. -Arran
Thanks for any help!
-mz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Tue, Mar 5, 2013 at 9:17 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 5 Mar 2013, at 18:03, Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
On Mon, Mar 4, 2013 at 4:28 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
You know SQL supports groups right? and that a group matching can be conditional on attributes in the request? and that you can add aditional config items to client definitions to mark them as a special devices?
Hi Arran,
Thanks for the reply. I've grepped the wiki and mailing list archives and could not answer the following:
What do I change in the nas table (in the database) to mark the network boxes as "special devices"? I see the schema as:
CREATE TABLE nas ( id SERIAL PRIMARY KEY, nasname VARCHAR(128) NOT NULL, shortname VARCHAR(32) NOT NULL, type VARCHAR(30) NOT NULL DEFAULT 'other', ports int4, secret VARCHAR(60) NOT NULL, server VARCHAR(64), community VARCHAR(50), description VARCHAR(200) );
Is it the "server" field? If so, could you also briefly explain how to apply that to group matching? (I have added users to groups using the usergroup table, but haven't touched the radgroupcheck/reply yet.)
So long as you're using static devices in clients.conf you can use the xlat expansion "%{client:<config item>}".
I am using static devices, but I am using a nas table in a PG database. Does that affect the xlat expansion? I already had a 'shortname' (but not a group field) in the table schema and tried: authorize { update request { Client-Group := "%{client:shortname}" } sql } Here is a snippet of the 'freeradius -X' output: ++[files] returns noop expand: %{client:shortname} -> ++[request] returns noop [sql] expand: %{Stripped-User-Name} -> [sql] ... expanding second conditional You can see that the expand didn't work as expected. Data in the table looks like: atlas=> SELECT * from radius_nas limit 1; id | nasname | shortname | type | secret | server ----+---------+-----------+------+-----------------+-------- 72 | ups | ups | | sUperS3cret | (1 row) And also the configuration in dialup.conf: nas_query = "SELECT id, nasname, shortname, type, secret, server FROM ${nas_table}" Any ideas? Thanks, -mz
participants (3)
-
Arran Cudbard-Bell -
Matt Zagrabelny -
Olivier Beytrison