Restricting users to their own devices

[Sudheer Satyanarayana]

On 22/04/19 10:07 PM, Alan DeKok wrote:
> On Apr 22, 2019, at 12:10 PM, Sudheer S <sudheer at 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.