post-auth configuration
Just curiosity really. My inner-tunnel configuration is appended below. It seems that my update to the outer session state has to be in both the main post-auth section and the REJECT subsection. Seems a bit counter- intuitive; what I would expect is the main section to apply to both ACCEPTs and REJECTs and then subsections to be applied additionally where appropriate. So just wondering what the rationale is. post-auth { #sql update outer.session-state { &User-Name = &User-Name } Post-Auth-Type REJECT { update outer.session-state { &User-Name = &User-Name } attr_filter.access_reject } }
On Jun 12, 2018, at 5:46 AM, Dom Latter <freeradius-users@latter.org> wrote:
It seems that my update to the outer session state has to be in both the main post-auth section and the REJECT subsection.
Because if you *read the debug output*, the main "post-auth" section is run only for Access-Accept, and the REJECT subsection is run only for Access-Reject.
Seems a bit counter- intuitive; what I would expect is the main section to apply to both ACCEPTs and REJECTs and then subsections to be applied additionally where appropriate. So just wondering what the rationale is.
Why would you expect that? The server works as documented. If your expectations are different from that, then they're wrong. i.e. READ the comments in the configuration you're editing. They explain how the server works. They should correct any misconceptions you have. Alan DeKok.
On 13/06/18 12:35, Alan DeKok wrote:
On Jun 12, 2018, at 5:46 AM, Dom Latter <freeradius-users@latter.org> wrote:
Seems a bit counter- intuitive; what I would expect is the main section to apply to both ACCEPTs and REJECTs and then subsections to be applied additionally where appropriate. So just wondering what the rationale is.
Why would you expect that?
Because every single programming language or bit of software I have EVER worked with, if there's a *sub*-section then it is performed in *addition* to whatever is in the main section. So I was wondering why freeradius differs from the norm.
The server works as documented. If your expectations are different from that, then they're wrong.
i.e. READ the comments in the configuration you're editing. They explain how the server works. They should correct any misconceptions you have.
You mean this? # Access-Reject packets are sent through the REJECT sub-section of the # post-auth section. That may be clear to you but coupled with an expectation of normality it is not clear at all that Reject packets will *not* go through the main part of the post-auth section.
On Jun 14, 2018, at 12:04 PM, Dom Latter <freeradius-users@latter.org> wrote:
Because every single programming language or bit of software I have EVER worked with,
Is not FreeRADIUS. FreeRADIUS has documentation describing how it works. I answered your question about how it works. You could have taken time to read the debug output to see how it works. Instead of learning, you got upset that ideas in your head didn't match reality. And doubled-down on complaining about it. Alan DeKok.
[Apologies for sending off-list as well] On 14/06/18 19:55, Alan DeKok wrote:
FreeRADIUS has documentation describing how it works. I answered your question about how it works. You could have taken time to read the debug output to see how it works.
Instead of learning, you got upset that ideas in your head didn't match reality. And doubled-down on complaining about it.
Alan, if you read my post carefully [0] you will see that I was not asking HOW it works: I'd already got that figured. I was asking WHY it was breaking the POLA [1], on the assumption that there must be a reason. Have a good weekend. [0] The irony... [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment
On Jun 15, 2018, at 8:21 AM, Dom Latter <freeradius-users@latter.org> wrote:
Alan, if you read my post carefully [0] you will see that I was not asking HOW it works: I'd already got that figured. I was asking WHY it was breaking the POLA [1], on the assumption that there must be a reason.
Your first message was complaining that HOW it works was a surprise. Despite documentation and the debug output which explained this. That's a problem we can't solve. If it breaks the POLA for you, that *also* means HOW it works is your main issue. Because POLA has nothing to do with *why* it works that way. If you want to know WHY it works this way, it's open source. The code is available to you. Learn. I'm arguing against the idea that "I don't have to read the documentation or the debug output, despite copies pages telling me to do so. Instead, if it doesn't work the way I expect, it's my right and duty to complain publicly about it. It doesn't matter that I got this software for free. I have every right to expect that it does what I want. I'm not going to suggest *improvements* to the documentation, in order to to make it clearer for others in my situation. Instead, I'm just going to complain." Enough. Stop arguing. This is your only warning. Alan DeKok.
On 15/06/18 13:43, Alan DeKok wrote:
On Jun 15, 2018, at 8:21 AM, Dom Latter <freeradius-users@latter.org> wrote:
Alan, if you read my post carefully [0] you will see that I was not asking HOW it works: I'd already got that figured. I was asking WHY it was breaking the POLA [1], on the assumption that there must be a reason.
Your first message was complaining that HOW it works was a surprise.
This is a complaint? "Just curiosity really [...] Seems a bit counter-intuitive [...] So just wondering what the rationale is." Please do not take offence where none was intended. I do try to "do my homework" and I have even read the source code on occasion but I would not expect to find the *rationale* for a decision like this actually in the source.
participants (2)
-
Alan DeKok -
Dom Latter