"Scott Bartlett" <[EMAIL PROTECTED]> wrote:
> >It's just more complex than your average model of just authenticate
> then
> >authorize...
>
> True, but only really because of the fallback choices. In my own case,
> we only use SQL. The user either auths or they fail. End of process.
You're stuck on the concept that because your configuration is
simple, then FreeRADIUS is wrong because it allows different (and more
complicated) configurations. That's annoying.
> Yep, I was kinda thinking something similar - maybe there should be a
> 'preprocess' section (preprocessing, hints, realms etc) maybe then
> followed by a 'something?' section listing the authenticate mechanisms
> in the order to attempt (in my own case just 'sql' but obviously
> numerous for some people), then maybe some postprocessing section and/or
> then accounting or something. Basically, a slight re-jigging of the
> layout of the config file to (hopefully) make things a bit clearer.
They're called authorize, authenticate, and post-authenticate.
The server has had this setup for nearly 3 months now.
> From an administrator's (i.e. a configuration) level I conceptually kind
> of see authentication and authorization as two sides of the same
> conversation sort of happening at the same time (kind of hard to
> describe!) - the server tells the selected mechanism (e.g. 'sql') who
> user is and the response from the mechanism will show if they
> authenticated successfully ('access accept') and, if successful, their
> authorization (reply attributes). Kind of all in one.
Ah. So because the protocol includes 2-3 different things in the
same packet, then the server must do all of those 2-3 things at the
same time, in the same order as the attributes in the packet.
WTF?
> After all, the NAS sends basically one request to the server and
> gets one response for the auth/auth bit of the auth/auth/acct
> process,
What the heck does that have to do with anything?
> so maybe auth and auth (heh... now I'm confusing you!)
> should be treated conceptually as one thing in FR.
Then go write your own server. FreeRADIUS will NEVER include 2-3
logical functions in one stage. If anything, the stages will be
broken up even smaller, to allow administrators more control over
packet processing.
> Depending on the administrator's needs, FR will fall to the next
> mechanism if there's a failure and repeat the process until there's
> either a match or it runs out of modules. I know this is what it
> actually does already, but as noted it's that wording which gets me...
> and I assume other users judging by the problems/questions often
> cropping up on this list.
Then suggest new wording. Don't re-design the server until you
understand how it works now.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
