On Mon, 2018-01-29 at 10:37 +0000, Tony Gottfridsson wrote:
9cebe82ae8eeCleartext-Password := "9cebe82ae8ee"
The "check" data.
Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID = 10
The "reply" data.
authorize_check_query string currently returns:
id,username,attribute,value,op 1,9c:eb:e8:2a:e8:ee,Cleartext-Password,9c:eb:e8:2a:e8:ee,:= 2,9c:eb:e8:2a:e8:ee,Tunnel-Type,VLAN,= 3,9c:eb:e8:2a:e8:ee,Tunnel-Medium-Type,IEEE-802,= 4,9c:eb:e8:2a:e8:ee,Tunnel-Private-Group-ID,99,=
Which isn't all "check" data.
To me this is almost exactly a "mirror of the users file content".
Yes, almost.
The query config files talks about ${authreply_table}. Well then it seems using sql it's not just to mirror the "users" file, there is something else needed that the "users" files doesn't need, what data do I need to have in authreply_table to enable the same functionality as the working poc
Put the check data in the check table and the reply data in the reply table. Colons in the MAC address do matter, too. "9c:eb:e8:2a:e8:ee" returned from the database won't match "9cebe82ae8ee" in the RADIUS packet. You need to make sure it's the same. -- Matthew