Correlating request and accept/reject log?
Hey, Suppose you are logging access requests, access-accepts, and access-rejects (into different log files), how do you link a request to a reject (or accept) message? Can we include additional items (like Calling-Station-Id, NAS-Port, etc.) in the reject log? Thanks, Marki
On Mar 30, 2017, at 10:01 AM, jm+freeradiususer@roth.lu wrote:
Suppose you are logging access requests, access-accepts, and access-rejects (into different log files), how do you link a request to a reject (or accept) message?
By it's request number, it's %n.
Can we include additional items (like Calling-Station-Id, NAS-Port, etc.) in the reject log?
Yes. See radiusd.conf, look in the "log" section. There are a number of configurable messages documented there. Alan DeKok.
Hmm, you mean "%I" (request ID)? (--> https://wiki.freeradius.org/config/run_time_variables) How would you include it? The ID is present neither in my auth nor reply/reject log. I tried using "header = ..." but Freeradius just started rejecting everything after that. Ideally one would have one log entry (or even inject into SQL), with one entry per event (all the info present in the request + the decision whether it was accepted or rejected...) --- Auth detail: detail auth_log { filename = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d permissions = 0600 suppress { User-Password } } Example: Thu Mar 9 18:46:57 2017 Packet-Type = Access-Request User-Name = '50-26-xx-xx-xx-xx' Service-Type = Framed-User Called-Station-Id = '20-B3-xx-xx-xx-xx' Calling-Station-Id = '50-26-xx-xx-xx-xx' NAS-Identifier = 'SWITCH1' NAS-Port = 131 NAS-Port-Type = Ethernet NAS-Port-Id = 'ge.3.27' NAS-IP-Address = 192.168.xx.xxx Message-Authenticator = 0xXXXXXXXXXXXXXXXXXXXXXXXXXX --- Reply detail: detail reply_log { filename = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d permissions = 0600 } Example: Fri Mar 31 02:08:54 2017 Packet-Type = Access-Accept Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = '100' Reply-Message = 'ACCEPTED MAC address 70-8b-xx-xx-xx-xx, VLAN 100' --- Reject detail: detail reject_log { filename = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reject-detail-%Y%m%d permissions = 0600 } Example: Fri Mar 31 09:35:56 2017 Packet-Type = Access-Reject Fri Mar 31 09:36:27 2017 Packet-Type = Access-Reject Fri Mar 31 09:36:27 2017 Packet-Type = Access-Reject Thanks, Marki
On Fri, Mar 31, 2017 at 09:55:19AM +0200, jm+freeradiususer@roth.lu wrote:
Hmm, you mean "%I" (request ID)? (--> https://wiki.freeradius.org/config/run_time_variables)
In version 3, %n. I'll update the wiki page. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Mar 31, 2017, at 3:55 AM, jm+freeradiususer@roth.lu wrote:
Hmm, you mean "%I" (request ID)? (--> https://wiki.freeradius.org/config/run_time_variables)
No.
How would you include it? The ID is present neither in my auth nor reply/reject log. I tried using "header = ..." but Freeradius just started rejecting everything after that.
What does that mean? Vague comments like this are distinctly unhelpful. "I tried stuff, but it didn't work... what's wrong?" i.e. There is simply no way to give you any advice on "fixing stuff". It's just too vague
Ideally one would have one log entry (or even inject into SQL), with one entry per event (all the info present in the request + the decision whether it was accepted or rejected...)
That's easy to do
--- Auth detail:
detail auth_log { filename = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d
See all of the %-things here? Add %n. It's that easy. Each request will be logged to it's own filename.
detail reply_log { filename = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d permissions = 0600 }
Add %n here, too.
detail reject_log { filename = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reject-detail-%Y%m%d
And here. Alan DeKok.
Hmm, you mean "%I" (request ID)? (--> https://wiki.freeradius.org/config/run_time_variables)
No.
Yes you do. However it seems the wiki was not up-to-date. I see it has been corrected and is now correctly documented as %n just as you said, thanks.
How would you include it? The ID is present neither in my auth nor reply/reject log. I tried using "header = ..."
What does that mean?
It means that in order to get a log with the information I want I tried using the header statement in the detail log definition like so: detail auth_log { filename = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d # # This MUST be 0600, otherwise anyone can read # the users passwords! permissions = 0600 # You may also strip out passwords completely suppress { User-Password } header = "%t %n" } However, freeradius then starts rejecting every request. But we do not necessarily need to investigate because of what you wrote after that:
Ideally one would have one log entry (or even inject into SQL), with one entry per event (all the info present in the request + the decision whether it was accepted or rejected...)
That's easy to do
Ok :) How? If you could kindly direct me to the appropriate docs. In fact, if you could kindly direct me to a single point of exhausting docs with examples please.
filename = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d
See all of the %-things here? Add %n. It's that easy. Each request will be logged to it's own filename.
I don't want one file per request. I want (ideally) one file that contains one line per request/action taken, much like the file generated by using the "requests" statement in the virtual server's log{} section. However the virtual server's log section does not allow to log specifically defined fields into a DB therefore I guess this has to be done some other way. Thanks.
On Fri, Mar 31, 2017 at 02:33:51PM +0200, jm+freeradiususer@roth.lu wrote:
Hmm, you mean "%I" (request ID)? (--> https://wiki.freeradius.org/config/run_time_variables)
No.
Yes you do. However it seems the wiki was not up-to-date. I see it has been corrected and is now correctly documented as %n just as you said, thanks.
No, they are not the same thing. In the wiki page update I did not change what %I means. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Mar 31, 2017, at 8:33 AM, jm+freeradiususer@roth.lu wrote:
Hmm, you mean "%I" (request ID)? (--> https://wiki.freeradius.org/config/run_time_variables)
No.
Yes you do.
If you know better than me, why are you asking questions on this list?
It means that in order to get a log with the information I want I tried using the header statement in the detail log definition like so: ... header = "%t %n" }
However, freeradius then starts rejecting every request.
If only there was some kind of debug log to tell you WHY it was doing things... The problem here is that the information you need is in front of you. But instead of reading it, you ask vague questions on the list. And then argue with the answers. You should learn to ask better questions, and to not argue with the experts.
That's easy to do
Ok :) How? If you could kindly direct me to the appropriate docs. In fact, if you could kindly direct me to a single point of exhausting docs with examples please.
No. Just... no. Why? Because everything *is* documented. It requires you to read the documentation, understand it, and put the pieces together yourself. There simple will NEVER be examples for every single thing that everyone wants to do. One, it's sheer laziness for you to ask that. And two, such examples would be infinite. It's much better to document how everything works, and then to rely on people to read that documentation.
filename = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d
See all of the %-things here? Add %n. It's that easy. Each request will be logged to it's own filename.
I don't want one file per request.
You didn't say what you wanted. That would have been helpful. Instead, you posted examples of the detail file, so I gave you answers about the detail file. If you want good answers, ask good questions.
I want (ideally) one file that contains one line per request/action taken,
See the "linelog" module. It does exactly this. And no, I'm not going to spoon-feed you to say how to add %n to the linelog messages. It should be pretty clear from the examples.
much like the file generated by using the "requests" statement in the virtual server's log{} section. However the virtual server's log section
The virtual server doesn't have a "log" section. Alan DeKok.
If you know better than me, why are you asking questions on this list?
I'm sorry I did not realize there was a "new %n" and an "old %n" (duh). I also didn't realize that there is a difference between a "request number" and a "request ID". Well, now I do. Please don't panic :)
It requires you to read the documentation.
Ok, let me rephrase my query in a neutral manner. These are the documentations that I am currently aware of: * The comments in the config files (as they are included with our distro, sometimes also a search at https://github.com/FreeRADIUS/freeradius-server/ to be on the safe side) * http://freeradius.org/radiusd/man/ * http://wiki.freeradius.org/... * Searching the mailing list may also prove fruitful * http://networkradius.com/doc/current/ + unfinished docs at the bottom of http://networkradius.com/freeradius-documentation/ * http://deployingradius.com/ Would there be any other resources that you would add to the list? BTW concerning the last two resources I mentioned, I'm not really sure if it's official and/or up-to-date (well it should be since they are interlinked).
linelog
Thank you. I couldn't find anything appropriate at http://freeradius.org/radiusd/man/index.html#modules. Well I could just have looked in /etc/raddb/mods-available.
And no, I'm not going to spoon-feed you to say how to add %n to the linelog messages. It should be pretty clear from the examples.
It is indeed.
The virtual server doesn't have a "log" section.
Correct, I of course meant the main config in radiusd.conf :-[ But I guess you know what I meant. Let me provide an example how things are sometimes not clear, maybe you can explain how you would have reasoned in this case in order to find the solution: As far as logging to SQL is concerned it is indeed not very difficult. Here is what I did: 1) I installed the freeradius-server-mysql package (depends on your distro, if you compile from source you probably have it out-of-the-box) 2) I then enabled the mysql module, so far so good 3) I inserted "sql" into the post-auth section of the virtual server (and also the "Post-Auth REJECT" sub-section) 4) To start easily, I decided to have FreeRadius write the SQL queries to a file, to that end I uncommented "logfile = ${logdir}/sqllog.sql" in /etc/raddb/mods-enabled/sql. However, nothing got logged. It turned out you need to uncomment the "logfile" entry in the post-auth{} section of "/etc/raddb/mods-config/sql/main/mysql/queries.conf". So, 1) How did I find that out? Well, I saw /etc/raddb/mods-config/sql/main/mysql/queries.conf being included at the bottom of /etc/raddb/mods-enabled/sql. So I went there and saw that it contained a post-auth{} section with a commented "logfile" entry that I uncommented. At that point, I was guessing. That's why I'm asking how I would have been supposed to find that solution. 2) I guess "logfile" from /etc/raddb/mods-enabled/sql then is only used when not using rlm_sql_null? Indeed, it makes sense that you don't write to disk twice, but c'mon ;-) Please have mercy with the people that didn't actually code this software :) BFN Marki
On Mar 31, 2017, at 11:17 AM, jm+freeradiususer@roth.lu wrote:
If you know better than me, why are you asking questions on this list?
I'm sorry I did not realize there was a "new %n" and an "old %n" (duh). I also didn't realize that there is a difference between a "request number" and a "request ID". Well, now I do.
That's fine. The problem is when you ask a question and get an answer, don't tell me I'm wrong. Honestly, I have *never* understood that mentality. It's one thing to say "are you sure?" or "I found X when you said Y, is that the same thing"? It's another thing entirely to have a flat-out "No, that's not what you meant". It's rude.
It requires you to read the documentation.
Ok, let me rephrase my query in a neutral manner. These are the documentations that I am currently aware of: * The comments in the config files (as they are included with our distort,
Which is the best and most up to date source of documentation.
sometimes also a search at https://github.com/FreeRADIUS/freeradius-server/ to be on the safe side)
Which just gets you a fancier search on the same data.
Which is just a copy of the "man" pages that come with the server.
That has a lot of information.
* Searching the mailing list may also prove fruitful
Mainly for "how do I configure some complex scenario", i.e. use-cases. As I said already, we don't document every single use-case. It's impossible.
* http://networkradius.com/doc/current/ + unfinished docs at the bottom of http://networkradius.com/freeradius-documentation/ * http://deployingradius.com/
Those are all good.
Would there be any other resources that you would add to the list?
No, that's it.
BTW concerning the last two resources I mentioned, I'm not really sure if it's official and/or up-to-date (well it should be since they are interlinked).
Since I wrote all 3 of those last links, yes, they're up to date, they're correct, and there's nothing wrong in them.
linelog
Thank you. I couldn't find anything appropriate at http://freeradius.org/radiusd/man/index.html#modules. Well I could just have looked in /etc/raddb/mods-available.
And that's my point.
Let me provide an example how things are sometimes not clear, maybe you can explain how you would have reasoned in this case in order to find the solution:
As a GOOD question on the list: Q: "Hi, I want to have a file which logs information about the packets. Ideally, one line per entry. Also, being able to correlate requests and replies in that file would be useful." A: use linelog. Use %n, here's how. Instead, you went down a rats nest of detail files, arguing, and searching other documentation.
As far as logging to SQL is concerned it is indeed not very difficult. Here is what I did: 1) I installed the freeradius-server-mysql package (depends on your distro, if you compile from source you probably have it out-of-the-box) 2) I then enabled the mysql module, so far so good 3) I inserted "sql" into the post-auth section of the virtual server (and also the "Post-Auth REJECT" sub-section) 4) To start easily, I decided to have FreeRadius write the SQL queries to a file, to that end I uncommented "logfile = ${logdir}/sqllog.sql" in /etc/raddb/mods-enabled/sql. However, nothing got logged. It turned out you need to uncomment the "logfile" entry in the post-auth{} section of "/etc/raddb/mods-config/sql/main/mysql/queries.conf".
In recent versions of the server, the comments about "logfile" in raddb/mods-enabled/sql also tell you to look in the subdirectories. Those comments && fixes went in almost 2 years ago.
So, 1) How did I find that out? Well, I saw /etc/raddb/mods-config/sql/main/mysql/queries.conf being included at the bottom of /etc/raddb/mods-enabled/sql. So I went there and saw that it contained a post-auth{} section with a commented "logfile" entry that I uncommented. At that point, I was guessing. That's why I'm asking how I would have been supposed to find that solution. 2) I guess "logfile" from /etc/raddb/mods-enabled/sql then is only used when not using rlm_sql_null? Indeed, it makes sense that you don't write to disk twice, but c'mon ;-)
If only there was a newer version of the server available with updated docs, and bugs fixed...
Please have mercy with the people that didn't actually code this software :)
My problem is not that you're new to it. My problem is you ask bad questions, and then argue with the answers. If you had asked good questions, you would have had the answer in about 5 minutes. Again, I have no idea why this is surprising. This should be a lesson for *you* to ask better questions, not to blame *me* for anything. Alan DeKok.
If only there was a newer version of the server available with updated docs, and bugs fixed...
The explanation for that is that we are actually using Enterprise Linux distros (RHEL, SLES), meaning: software is not bleeding edge. Since we're paying support for that, we could ask them questions, but they are probably not experts in every single product or technology that they provide a package for. Even if they were, the limits of "normal" tech support are quickly reached, and consulting becomes "necessary" (or at least that's what they would tell you). As an alternative we could install everything entirely up-to-date manually. But then there would be no support, at least not for that software. So we either would have to pay twice (#1: for the old version that comes with the distro anyway, #2 for a newer version that we install ourselves and that would thus not be covered by #1.) Or we could drop Enterprise Linuxes entirely and either hope that everything works out, or buy support for each individual software, which is unfeasible. Now, however, we are OT I guess :)
On Mar 31, 2017, at 11:52 AM, jm+freeradiususer@roth.lu wrote:
If only there was a newer version of the server available with updated docs, and bugs fixed...
The explanation for that is that we are actually using Enterprise Linux distros (RHEL, SLES), meaning: software is not bleeding edge.
That's an issue. But... not *our* issue here.
Since we're paying support for that, we could ask them questions,
And you should.
but they are probably not experts in every single product or technology that they provide a package for. Even if they were, the limits of "normal" tech support are quickly reached, and consulting becomes "necessary" (or at least that's what they would tell you).
Then why pay support? Alan DeKok.
participants (3)
-
Alan DeKok -
jm+freeradiususer＠roth.lu -
Matthew Newton