On 22/04/19 10:07 PM, Alan DeKok wrote:
On Apr 22, 2019, at 12:10 PM, Sudheer S <sudheer@techchorus.net> wrote:
I am using Freeraidius and I want to restrict users to their own devices.
I have inserted the Mac addresses of the users in radcheck table with the attribute Calling-Station-Id. Here's an example:
SELECT * FROM radcheck; id | username | attribute | op | value -------+------------+--------------------+----+-------------- 23175 | testuser01 | Cleartext-Password | := | password 23177 | testuser01 | Calling-Station-Id | := | aabbccddeefa 23178 | testuser01 | Calling-Station-Id | := | aabbccddeeff
In this case, the user testuser01 has two devices. aabbccddeefa and aabbccddeeff are their respective mac addresses. No.
Read the Wiki for rlm_sql to see how it works. You're using the ":=" operator, which means you're *setting* the Calling-Station-Id, not *checking* it.
I read the wiki again. If I understand correctly, == operator should be used to check the mac address of the user. So, I modified the rows in the table: SELECT * FROM radcheck; id | username | attribute | op | value ----+------------+--------------------+----+-------------- 4 | testuser02 | Cleartext-Password | := | password 6 | testuser02 | Calling-Station-Id | == | 70bbe9363cbc (2 rows) 70bbe9363cbc is the mac address of the user's device. Here's an excerpt from the request: (286) Received Access-Request Id 240 from 192.168.3.5:56875 to 192.168.3.33:1812 length 209 (286) User-Name = "testuser02" (286) NAS-IP-Address = 192.168.3.5 (286) NAS-Port = 0 (286) NAS-Identifier = "192.168.3.10" (286) NAS-Port-Type = Wireless-802.11 (286) Calling-Station-Id = "70bbe9363cbc" I see that the Calling-Station-Id attribute is correctly set in the request. Excerpt from further processing of request: rlm_sql (sql): Reserved connection (49) (287) sql: EXPAND SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id (287) sql: --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'testuser02' ORDER BY id (287) sql: Executing select query: SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'testuser02' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 2 , fields = 5 (287) sql: User found in radcheck table (287) sql: Conditional check items matched, merging assignment check items (287) sql: Cleartext-Password := "password" I see that the attribute Cleartext-Password is set properly. (294) [sql] = ok (294) [expiration] = noop (294) [logintime] = noop (294) [pap] = noop (294) } # authorize = updated (294) Found Auth-Type = eap (294) # Executing group from file /etc/raddb/sites-enabled/inner-tunnel (294) authenticate { (294) eap: Expiring EAP session with state 0x38a15a8d38a840a4 (294) eap: Finished EAP session with state 0x38a15a8d38a840a4 (294) eap: Previous EAP request found for state 0x38a15a8d38a840a4, released from the list (294) eap: Peer sent packet with method EAP MSCHAPv2 (26) (294) eap: Calling submodule eap_mschapv2 to process data (294) eap_mschapv2: # Executing group from file /etc/raddb/sites-enabled/inner-tunnel (294) eap_mschapv2: authenticate { (294) mschap: WARNING: No Cleartext-Password configured. Cannot create NT-Password (294) mschap: WARNING: No Cleartext-Password configured. Cannot create LM-Password (294) mschap: Creating challenge hash with username: testuser02 (294) mschap: Client is using MS-CHAPv2 (294) mschap: ERROR: FAILED: No NT/LM-Password. Cannot perform authentication (294) mschap: ERROR: MS-CHAP2-Response is incorrect (294) [mschap] = reject (294) } # authenticate = reject (294) eap: Sending EAP Failure (code 4) ID 9 length 4 (294) eap: Freeing handler (294) [eap] = reject (294) } # authenticate = reject (294) Failed to authenticate the user (294) Using Post-Auth-Type Reject (294) # Executing group from file /etc/raddb/sites-enabled/inner-tunnel (294) Post-Auth-Type REJECT { (294) sql: EXPAND .query (294) sql: --> .query (294) sql: Using query template 'query' rlm_sql (sql): Reserved connection (50) (294) sql: EXPAND %{User-Name} (294) sql: --> testuser02 (294) sql: SQL-User-Name set to 'testuser02' (294) sql: EXPAND INSERT INTO radpostauth (username, pass, reply, authdate) VALUES('%{User-Name}', '%{%{User-Password}:-Chap-Password}', '%{reply:Packet-Type}', NOW()) (294) sql: --> INSERT INTO radpostauth (username, pass, reply, authdate) VALUES('testuser02', 'Chap-Password', 'Access-Reject', NOW()) (294) sql: EXPAND /var/log/radius/sqllog.sql (294) sql: --> /var/log/radius/sqllog.sql (294) sql: Executing query: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES('testuser02', 'Chap-Password', 'Access-Reject', NOW()) rlm_sql_postgresql: Status: PGRES_COMMAND_OK rlm_sql_postgresql: query affected rows = 1 (294) sql: SQL query returned: success (294) sql: 1 record(s) updated rlm_sql (sql): Released connection (50) (294) [sql] = ok (294) attr_filter.access_reject: EXPAND %{User-Name} (294) attr_filter.access_reject: --> testuser02 The access was rejected. I was expecting the accept response. I'm sure I missed something. But I don't know what.
In the authorize section, I have this snippet:
if (Calling-Station-Id != "%{sql: SELECT value FROM radcheck WHERE username='%{User-Name}' AND value='%{Calling-Station-Id}'}") { If you have custom queries, then you should use a custom schema. Using the standard schema to do non-standard things is just bad.
reject update reply { Reply-Message = "Unauthorized device" } }
This setup works.
I was wondering whether this is an acceptable way to restrict users to their own devices.
Initially, I assumed Freeradius would restrict the users based on Calling-Station-Id in radcheck table. But when I tested, my assumption was wrong.
Yes, the server works as documented. And this *is* documented.
Therefore, I put up the unlang. Please advise on best practices to handle such requirements. Create a custom table for custom queries.
Alan DeKok.
Thanks, Alan. That helps. I have removed the custom query and the non-standard check in authorize section.