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 | [email protected] | Calling-Station-Id | == | > 98-4B-4A-F5-BF-40 | > +----+----------------------------+--------------------+----+-------------------+ See the rlm_sql documentation. This entry says: for user "[email protected]", check that Calling-Station-Id is "98-4B-4A-F5-BF-40". It doesn't *do* anything with that information. > The problem is that [email protected] 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 > [email protected] > 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 = '[email protected]' 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 [email protected] 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
