Post-Auth-Type REJECT "broken" in 3.1.x

[Matthew Newton]

On Thu, Jun 23, 2016 at 11:02:28AM -0400, Alan DeKok wrote:
> On Jun 23, 2016, at 10:54 AM, Matthew Newton <mcn4 at leicester.ac.uk> wrote:
> > Looking at e.g. preprocess, there are a shedload of hacks for
> > things that look pretty old. How many are still useful, or could
> > be written as unlang policies instead?
> 
> Many could be written as policies.  My only concern is
> performance.  While unlang is flexible, it's not particularly
> fast.  So having policies in C is often useful.

Yes. I was mainly thinking that if hardly anyone uses some
feature, then an unlang policy might be a tidier option even
though it might not be quite as quick.

> > Things like mschap NT domain hack...
> > 
> > Talk a while back about renameing authorize{}, post-auth{} etc.
> > Though I don't think there were any conclusive arguments.
> 
>   It's started in 4.0.  :(

That's ":)" surely? :)

>   The argument is simple: keeping the existing methods is RADIUS-specific, confusing, etc.
> 
> Q: what happens when the server sends an Access-Reject?
> 
> A:  it runs the post-auth section, and for that, the Post-Auth-Type Reject subsection

Yeah.

> Q: Huh?  What kind of crack are you guys on anyways?

Not good enough quality crack, obviously. (Maybe just "cracked",
happy to include myself...)

>   In 4.0, it's now:
> 
> send Access-Reject {
> 	...
> }
> 
>   Simple.  Very, very, simple.

That looks nicer.

>   Also, the non-RADIUS protocols are currently hacked together
>   by running them through "authorize" or "post-auth" sections.
>   That's terrible.

It always seemed rather messy, and it's obvious they were an
afterthought.

> > I don't have any idea whether people are still using any of
> > this stuff...
> 
>   There are occasional questions about hunt groups, nothing about hints.

There was a question about hints a couple of days ago, which was
what got me thinking about it. It was the first question I
remember in a very long time.


>   TBH, hints could go today.  The hunt groups could be removed, and replaced with "use a database".

I wonder if FR should actually use a sqlite database by default,
given some tools to manage the data in it. Though I wouldn't want
to see 'files' go away entirely.

I must admit though I've never really liked the standard FR SQL
schema though. But I've also not ever had time to look at it and
see if there is something more sensible these days. Again, it
smells of 'legacy'.

>   Many of the other NAS-specific hacks can be removed.  They've
>   been there for 18 years, and I don't think any of that
>   equipment is still running.  If it is, people can just write
>   "unlang" for it.

Agreed.

Matthew


-- 
Matthew Newton, Ph.D. <mcn4 at 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 at le.ac.uk>