> Well.. you're right and wrong.
Ah... so I really am confused then... ;-)
>FreeRADIUS allows people to authenticate via several different
>mechanisms from the same master daemon process (radiusd), so it has to
>check each available mechanism to find out which one authorises the
>user (if any) before authenticating him against the correct mechanism
>So it's :-
>- check all available authentication mechanisms as defined
>- establish which will authenticate this user
>(actually preprocessing - hints -> realms -> users), although this *is*
>called authorization in the config file radiusd.conf
>- authenticate against mechanism authentication)
>- possibly fall back to another on auth fail (fallback)
>- then supply, on successful authentication, the radius attribute
> results (login authorization)->(accounting)
>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.
>maybe the section /should/ be called "preprocess" or
>"check_auth_method" or something...
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.
>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. 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, so maybe auth and auth
(heh... now I'm confusing you!) should be treated conceptually as one
thing in FR.
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.
Regards!
SB
---
This message (and any associated files) is intended only for the
use of the individual or entity to which it is addressed and may
contain information that is confidential, subject to copyright or
constitutes a trade secret. If you are not the intended recipient
you are hereby notified that any dissemination, copying or
distribution of this message, or files associated with this message,
is strictly prohibited. If you have received this message in error,
please notify us immediately by replying to the message and deleting
it from your computer. Messages sent to and from us may be monitored.
Internet communications cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. Therefore, we do not accept
responsibility for any errors or omissions that are present in this
message, or any attachment, that have arisen as a result of e-mail
transmission. If verification is required, please request a hard-copy
version. Any views or opinions presented are solely those of the author
and do not necessarily represent those of BTA Ltd.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
