How to log Access-Accept reply attributes/values in radpostauth sql
Hi All FR 3.0.13. Everything working perfectly, including SQL (mysql) for auth/acct logging. When a user authenticates, I would like to log any Access-Accept reply attributes we've set to sql (radpostauth). For example, my typical Access-Accept looks like this: Access-Accept (2), id: 0x2f, Authenticator: 123 Session-Timeout Attribute (27), length: 6, Value: 86400 Idle-Timeout Attribute (28), length: 6, Value: 600 Acct-Interim-Interval Attribute (85), length: 6, Value: 300 Therefore, I would like to log anything that was sent back to the NAS to the DB, in this instance: "Session-Timeout=86400,Idle-Timeout=600,Acct-Interim-Interval=300" or some other format as long as the data is readable... Is that possible? I tried using something like the below in the queries file: post-auth { query = "\ INSERT INTO ${..postauth_table} \ (username, pass, reply, authdate, callingstationid, calledstationid, attributes) \ VALUES ( \ '%{SQL-User-Name}', \ '%{%{User-Password}:-%{Chap-Password}}', \ '%{reply:Packet-Type}', \ '%S', \ '%{Calling-Station-Id}', \ '%{Called-Station-Id}', \ '%{reply:[*]}')" But doesn't appar I can use %{reply[*]} in that way. Thanks James
On Aug 24, 2017, at 5:19 PM, James Wood <james.wood@purplewifi.com> wrote:
FR 3.0.13. Everything working perfectly, including SQL (mysql) for auth/acct logging.
It would be good to upgrade to 3.0.15, but that's fine..
When a user authenticates, I would like to log any Access-Accept reply attributes we've set to sql (radpostauth).
There really aren't provisions for that, unfortunately.
Is that possible? I tried using something like the below in the queries file:
post-auth { query = "\ INSERT INTO ${..postauth_table} \ (username, pass, reply, authdate, callingstationid, calledstationid, attributes) \ VALUES ( \ '%{SQL-User-Name}', \ '%{%{User-Password}:-%{Chap-Password}}', \ '%{reply:Packet-Type}', \ '%S', \ '%{Calling-Station-Id}', \ '%{Called-Station-Id}', \ '%{reply:[*]}')"
But doesn't appar I can use %{reply[*]} in that way.
Nope. I'm surprised that didn't give you parse errors. Alan DeKok.
On 25 Aug 2017, at 22:56, Alan DeKok <aland@deployingradius.com> wrote:
On Aug 24, 2017, at 5:19 PM, James Wood <james.wood@purplewifi.com> wrote:
FR 3.0.13. Everything working perfectly, including SQL (mysql) for auth/acct logging.
It would be good to upgrade to 3.0.15, but that's fine..
When a user authenticates, I would like to log any Access-Accept reply attributes we've set to sql (radpostauth).
%{pairs:&reply:} It’ll expand to <attribute> = <value>, for each pair in the list. We might be able to do something with %{reply:[*]} in v4.0.x but there’s nothing like that in 3.0.x. -Arran
Arran Cudbard-Bell wrote:
When a user authenticates, I would like to log any Access-Accept reply attributes we've set to sql (radpostauth).
%{pairs:&reply:}
It’ll expand to <attribute> = <value>, for each pair in the list.
We might be able to do something with %{reply:[*]} in v4.0.x but there’s nothing like that in 3.0.x.
In 4.0 there's a function fr_json_afrom_pair_list (used in rlm_rest). We could expose that via xlat so you could log the JSON representation in the database. Postgresql has a JSON(B) datatype these days. -- Herwin Weststrate
On Aug 26, 2017, at 4:54 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
We might be able to do something with %{reply:[*]} in v4.0.x but there’s nothing like that in 3.0.x.
I took a look, and it actually is in 3.0.x I pushed some fixes, tho. The functionality of the server is getting too big to for me to remember it all any more. :( update reply { Filter-Id := "%{request:[*]}" } ... Sent Access-Request Id 139 from 0.0.0.0:63328 to 127.0.0.1:1812 length 87 User-Name = "bob" User-Password = "bob" NAS-IP-Address = 127.0.0.1 Framed-IP-Address = 127.0.0.1 Called-Station-Id = "aabbcc000001" Message-Authenticator := 0x00 Received Access-Accept Id 139 from 127.0.0.1:1812 to 0.0.0.0:0 length 97 Filter-Id = "bob,bob,127.0.0.1,127.0.0.1,aabbcc000001,0x26ca3008fc50d3d1061e83c249ab10a0" The last hex blob is the Message-Authenticator. For v4, I'm inclined to skip decoding the Message-Authenticator entirely. No one bases policies on it, and it's already added automatically where necessary. Alan DeKok.
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Herwin Weststrate -
James Wood