Your reference is wrong/unknown which means that there's a noop. This means no operation which means no fticks output alan
On 28 August 2013 18:49, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote: Thanks Alan,
Your reference is wrong/unknown which means that there's a noop. This means no operation which means no fticks output
This brings me back to my earlier question: what values are available where, and when, via which mechanism? I think I still don't fully understand how modules hang together, how I pass information from e.g. an EAP request into line-log, or, looking at sites-enabled/eap-inner-tunnel, how I tell f_ticks (or linelog, or any other modules for that matter) which values I'd like to work with. I would like f_ticks to write out a single line into syslog that contains the inner and outer identity of an authentication request, the station ID and MAC address. In case of a successful authentication or rejection I'd like to have the inner identity and a status on a line, Can anyone point me at a walk-through or how-to? I've now spent days flicking from one wiki-page to the next, and reading mailing list archives w/o find anything that helps me understand.
On Thu, Aug 29, 2013 at 10:39:50AM +1200, Andrej wrote:
On 28 August 2013 18:49, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote: Thanks Alan,
Your reference is wrong/unknown which means that there's a noop. This means no operation which means no fticks output
This brings me back to my earlier question: what values are available where, and when, via which mechanism?
I think I still don't fully understand how modules hang together, how I pass information from e.g. an EAP request into line-log, or, looking at sites-enabled/eap-inner-tunnel, how I tell f_ticks (or linelog, or any other modules for that matter) which values I'd like to work with.
Everything becomes an attribute or a variable and the definitions are mostly at /usr/share/freeradius/dictionary.freeradius.internal and you can also define your own attributes in /etc/freeradius/dictionary. I use this to get time in a format similar to syslog by having a variable My-Local-Time and calling an exec module with date command and assigning the result to this variable which I can then reference in my linelog. the only way I found how to get what I need is to define a linelog, write there the variables I hope will have what I'm looking for and call that linelog from some part of the server configuration and just run my clients against it and see what happens. for the username you can use outer.request:User-Name in the inner-tunnel which should reference the outer tunnel User-Name. User-Name in the inner-tunnel should be the inner EAP username. Also the attribute named Inner-Tunnel-User-Name might have the inner EAP username but that might be defined only in the post-auth section of the default server. mk
On 28 Aug 2013, at 23:39, Andrej <andrej.groups@gmail.com> wrote:
I would like f_ticks to write out a single line into syslog that contains the inner and outer identity of an authentication request, the station ID and MAC address.
In case of a successful authentication or rejection I'd like to have the inner identity and a status on a line,
We do this by using lots of custom linelog instances. In linelog.conf (just a few examples): linelog acceptlog { filename = "/var/log/radius/auth-%D.log" format = "%S (%l) id %I ACCEPT %{User-Name} (station %{%{Calling-Station -Id}:--}) auth-type %{control:Auth-Type}/%{EAP-Type} realm %{%{Realm}:--} nas %{ %{NAS-IP-Address}:-%{%{NAS-IPv6-Address}:--}-}/%{%{NAS-Port}:--} (operator %{%{O perator-Name}:--}) client %{%{Packet-Src-IP-Address}:-%{%{Packet-Src-IPv6-Addres s}:--}} (%{Client-Shortname}) ap '%{%{UCam-AP-Name}:--}' essid '%{%{UCam-Essid-N ame}:--}' => %{%{reply:User-Name}:--} reply-msg '%{reply:Reply-Message}'" } linelog inner-acceptlog { filename = "/var/log/radius/auth-%D.log" format = "%S (%l) id %I INNER-TUNNEL ACCEPT %{User-Name} (station %{%{ou ter.request:Calling-Station-Id}:--}) outer-id %{outer.request:User-Name} auth-ty pe %{outer.control:Auth-Type}/%{outer.request:EAP-Type}/%{control:Auth-Type} rea lm %{%{Realm}:--} nas %{%{outer.request:NAS-IP-Address}:-%{%{outer.request:NAS-I Pv6-Address}:--}}/%{%{outer.request:NAS-Port}:--} (operator %{%{outer.request:Op erator-Name}:--}) client %{%{Packet-Src-IP-Address}:-%{%{Packet-Src-IPv6-Address }:--}} (%{Client-Shortname}) ap '%{%{outer.request:UCam-AP-Name}:--}' essid '%{% {outer.request:UCam-Essid-Name}:--}' => %{%{reply:User-Name}:--} reply-msg '%{re ply:Reply-Message}'" } linelog proxy-replylog { filename = "/var/log/radius/auth-%D.log" format = "%S (%l) id %I PROXY REPLY %{User-Name} (station %{%{Calling-St ation-Id}:--}) auth-type /%{EAP-Type} realm %{%{Realm}:--} nas %{%{NAS-IP-Addres s}:-%{%{NAS-IPv6-Address}:--}-}/%{%{NAS-Port}:--} (operator %{%{Operator-Name}:- -}) client %{%{Packet-Src-IP-Address}:-%{%{Packet-Src-IPv6-Address}:--}} (%{Clie nt-Shortname}) proxy %{%{proxy-reply:Packet-Src-IP-Address}:-%{%{proxy-reply:Pac ket-Src-IPv6-Address}:--}} proxy-reply-type %{proxy-reply:Packet-Type} proxy-rep ly-msg '%{proxy-reply:Reply-Message}' => %{%{proxy-reply:User-Name}:--}" } We call them as follows: [default] post-proxy { ... proxy-replylog ... } post-auth { ... acceptlog ... } [inner-tunnel] post-auth { ... inner-acceptlog ... } There are some references to %{UCam-AP-Name} and things in there -- we set these with things like: if ("%{Aruba-Location-Id}") { update request { UCam-AP-Name := "%{Aruba-Location-Id}" UCam-Essid-Name := "%{Aruba-Essid-Name}" } } ... they let us not refer to the direct Aruba attributes and would allow us to more easily add another wireless system (we used to have Cisco but migrated away) - if we had to move again, we don't have lots of Cisco-specific bits all over the place. Note that the attributes are defined in 'dictionary'. The above stuff will give lines like: 2013-08-29 10:53:02 (1377769982) id 175 INNER-TUNNEL ACCEPT rcf34@cam.ac.uk (station 0015AF81CEB3) outer-id @cam.ac.uk auth-type EAP/PEAP/EAP realm LOCAL nas 131.111.1.20/0 (operator 1lapwing.cam.ac.uk) client 131.111.1.20 (errigal@lapwing.cam.ac.uk) ap '00:24:6c:c3:24:fd' essid 'eduroam' => rcf34 reply-msg '[cam.ac.uk] Successful authentication <ACCEPT>' [example from inner-acceptlog.] Hope this helps, - Bob -- Bob Franklin <rcf34@cam.ac.uk> +44 1223 748479 Network Division, University of Cambridge Computing Service
Andrej wrote:
This brings me back to my earlier question: what values are available where, and when, via which mechanism?
This was asked and answered. I suggest reading responses to your messages. Asking what "values" are available is wrong. There are no magic "values" in the server. There are just attributes in a packet. If you want to know what attributes are available, look at the debug output. That REALLY is it. It's not hard. It's not rocket science. There's no magic.
I think I still don't fully understand how modules hang together, how I pass information from e.g. an EAP request into line-log,
Read doc/aaa.rst You don't "passd" information into a module. The incoming packet (and associated data) is given to the module. The module then decides what to do.
sites-enabled/eap-inner-tunnel, how I tell f_ticks (or linelog, or any other modules for that matter) which values I'd like to work with.
Have you tried reading the debug output? It's *telling you* what it's doing. The f_ticks module is telling you what it's doing. Have you tried reading the default configuration for the "linelog" module? It has LOTS of documentation describing how it works. Ask *specific* questions about what's confusing you.
I would like f_ticks to write out a single line into syslog that contains the inner and outer identity of an authentication request, the station ID and MAC address.
So... do you see that data in the debug output? If so, read "man unlang" for how to reference attributes. See the default "linelog" configuration for how the module works. Put the two together, and you'll have it.
Can anyone point me at a walk-through or how-to? I've now spent days flicking from one wiki-page to the next, and reading mailing list archives w/o find anything that helps me understand.
There are NO examples which document exactly what you're trying to do. Most deployments are unique. Creating documentation for every possible deployment is impossible. It sounds like you're not understanding basic concepts, and reading random web pages, looking for a magic solution. This isn't the best approach. Read doc/aaa.rst. Read "man unlang". Read the debug output. Read the default "linelog"configuration. Alan DeKok.
participants (5)
-
Alan Buxey -
Alan DeKok -
Andrej -
Martin Kraus -
Robert Franklin