MAC authorization with rlm_sql not working

[Alan DeKok]

Stefano Zanmarchi wrote:
> Hi,
> our Freeradius is working fine with PEAP (NT hash passwords stored in Openldap).
> We'd like to add MAC authorization using Mysql: only people with MAC
> contained in
> radcheck should have access (provided they also type in the right password!).

  So you need to check passwords, and allow only known MACs.

> Radcheck has only one entry:
> +----+----------------------------+--------------------+----+-------------------+
> | id | username                   | attribute          | op | value
>          |
> +----+----------------------------+--------------------+----+-------------------+
> |  1 | uto.ughi at studenti.unipd.it | Calling-Station-Id | == |
> 98-4B-4A-F5-BF-40 |
> +----+----------------------------+--------------------+----+-------------------+

  See the rlm_sql documentation.  This entry says:

for user "uto.ughi at studenti.unipd.it", check that Calling-Station-Id is
"98-4B-4A-F5-BF-40".

  It doesn't *do* anything with that information.

> The problem is that uto.ughi at studenti.unipd.it gets an AccessAccept packet,
> regardless of his Calling-Station-Id.

  Yes.  Because you're probably also checking passwords, and allowing
good passwords with bad MACs.

> Don't know if it's related but strangely (to me) when uto.ughi at studenti.unipd.it
> has Calling-Station-Id 98-4B-4A-F5-BF-40 (the one in radcheck) radiusd performs
> this sql query:
>    SELECT id, username, attribute, value, op
>    FROM radcheck WHERE username = 'uto.ughi at studenti.unipd.it' ORDER BY id
> and the radiusd -X output shows "[sql] User found in radcheck table"
> Same user, different Calling-Station-Id (73-1C-5C-B4-E0-55, not the
> one in radcheck),
> shows "[sql] User uto.ughi at studenti.unipd.it not found."

  Exactly.  The "user and MAC" entry is found when it matches.  It's not
found when it doesn't match.

> I enclose these files:

  Please don't.

  You can fix the issue by doing:

authorize {
	...
	sql
	if (notfound) {
		reject
	}
	...
}

  Alan DeKok.