Serving multiple groups of users

[Marcus Ng]

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 at lists.freeradius.org
[mailto:freeradius-users-bounces+marcus.ng=assuritz.com at 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