Hi, Thanks for the suggestion but it may not solve my problems, which is to isolate the authentication of different groups of users. This is my use case. I have 2 dept: A & B. I want to provide WPA2-Enterprise to both dept A & B, who have different groups of end users. But I do not want them to mix, i.e. If a end user from dept A tries to connect to a Wifi AP that belongs to dept A, the authentication would be successful. If a end user from dept A tries to connect to a Wifi AP that belongs to dept B, the authentication would fail. I can create 2 virtual servers and point the group of Wifi AP from Dept A to virtual server 1 and dept B to Virtual Server 2. But how would the virtual server knows which authentication to allow and which to block? From what I understand, the 2 virtual servers will share the same sql module. That is my dilemma. I have tried to solve this through a number of ways but have not been very successful. Method 1. Taking advantage of the fact that all wifi AP of a dept will point to a particular virtual server, I modify the authorize_check_query to use the listening address/port of the virtual server as a selection criteria authorize_check_query = "SELECT id, UserName, Attribute, Value, Op \ FROM ${authcheck_table} \ WHERE Username = '%{SQL-User-Name}' \ and ORG =(Select org from radlisten where \ radius_ip='%{Packet-Dst-IP-Address}' and radius_port='%{Packet-Dst-Port}') ORDER BY id" (Note: Yes I add a column 'Org' to table radcheck and a new table radlisten to do this. See below). \d radcheck Table "public.radcheck" Column | Type | Modifiers -----------+------------------------+--------------------------------------- ---------------- id | integer | not null default nextval('radcheck_id_seq'::regclass) org | character varying(64) | not null default ''::character varying username | character varying(64) | not null default ''::character varying attribute | character varying(64) | not null default ''::character varying op | character(2) | not null default '=='::bpchar value | character varying(253) | not null default ''::character varying \d radlisten Table "public.radlisten" Column | Type | Modifiers -------------+-----------------------+-------------------------------------- ------------------ id | integer | not null default nextval('radlisten_id_seq'::regclass) org | character varying(64) | not null default ''::character varying radius_ip | cidr | not null radius_port | integer | not null This works for the outer layer. But when the auth-request is passed to the inner-tunnel, the runtime attributes %{Packet-Dst-Port} no longer holds the original value, so the authentication fails at inner-tunnel. Method 2. I thought I can capture the initial listening IP and port and pass that info to the inner-tunnel as attributes. So I add a section in policy.conf update request { Radius-IP = "%{Packet-Dst-IP-Address}" Radius-Port = "%{Packet-Dst-Port}" } The attributes are added successfully. But how do I pass them to the inner-tunnel?? Thanks! -Marcus -----Original Message----- From: freeradius-users-bounces+marcus.ng=assuritz.com@lists.freeradius.org [mailto:freeradius-users-bounces+marcus.ng=assuritz.com@lists.freeradius.org ] On Behalf Of Alan DeKok Sent: Sunday, August 17, 2014 5:09 PM To: FreeRadius users mailing list Subject: Re: Serving multiple groups of users Marcus Ng wrote:
I would like to configure freeradius2 to have multiple listening ports, with each port catering to a unique group of users.
I.e. if a user comes in through listening port 1, his credentials will be checked against a subset of the radcheck.
if a user comes in through listening port 2, his credentials will be checked against a different subset of the radcheck.
What is the easiest way to do that?
Read raddb/sites-available/README. You can use a virtual server. Copy the default server, and then change the port numbers in the copy. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html