Trying to wrap my head around FreeRadius config

[Alan DeKok]

Moe, John wrote:
Moe, John wrote:
> Apologies in advance if this isn't the right forum for this, or if it's
> already been answered somewhere, and my Google-fu just isn't up to the
> task.  Please point me in the right direction if either is the case.

  doc/aaa.rst helps.

> In trying to get this step working, I'm
> trying to understand how all the various config files and modules all
> fit together, so that I can understand how to properly setup FreeRadius.

  One word: Don't.

  It's a large complicated piece of software.  The complexity is there
so that you don't *need* to understand it.  Follow the guides (on
freeradius.org && deployingradius.com).  It *will* work.

> I've read through the config files and the Wiki pages, but I'm still not
> entirely clear that I understand it all, so I'm hoping someone can
> correct me if I'm on the wrong track.

  The wrong track is the desire to understand everything all at the same
time.  You've posted a series of questions which contain some good
information, and some misunderstandings.  It's difficult to come up with
a good response, as the response is piecemeal:  it doesn't form a
coherent picture.

  The simple thing is this.  Packets come from clients.  The are
configured in clients.conf.  The server receives the packets.  It
processes them.  It sends a response.

  That's it.

  The details of how all of that works can be broken up into independent
pieces.  i.e. pieces which can be understood without referring to
anything else.

  The "files" module works by receiving a request, processing the
"users" file, and updating the request.

  The "unix" module works by receiving a request, looking the user up in
/etc/passwd, and updating the request.

  The "authorize" section just runs a bunch of modules, one after the other.

  As for the rest of it.  I'll response.  Not to give answers, but to
give corrections on the process which caused you to ask the questions.

> This is where things start to get a bit blurry for me.  I understand
> that the preprocess module is rlm_preprocess, and that the config lives
> in modules/preprocess, where I can read a description of that module and
> what it does.  Likewise for chap and mschap.  However, suffix doesn't
> appear to be a module; where'd this come from, and what does it do?

  It's a module, too.  grep the "modules" directory for "suffix".  Or
read the debug output.  It's all there.

  i.e. don't get confused.  The *process* to find the answer is simple:
debug output.

> There also appear to be some modules in /usr/lib64/rlm_* that appear to
> have neither a man page, nor a config file in the modules directory, nor
> any sort of description in the Configuration Files section of the Wiki
> page.  

  And why does this matter?  You're going out of your way to find
problems.  This is counter-productive and confusing.

> 3) The chap, mschap and eap modules seem to all look at the request and
> decide if the request is using any of these.  If so, they add "Auth-Type
> := <one of them>" to the config item list.  The eap module isn't
> configured under the modules directory, but in the root directory in
> eap.conf, the others in their respective file in the modules directory.

  So?  Why does this matter?

> 4) ...
> 5) ...
> 6) ...

  A bunch of modules run.  Details don't really matter.

> Where do the rest of the attributes that get sent with the packet get
> added to the config item list?  Does that happen first?  Does that
> happen later?  Or is the incoming request with all its attributes
> immediately turned into a list of config items?  None of the modules
> listed seem to say they parse the request and add the request's
> attributes to the config items.

  Read the documentation on config items versus request or response.
See "man unlang".  This is documented.

> After all this, it then runs through the authenticate section of the
> sites-enable/default file, where it does the user/password checking:
> 
> 1) It checks to see if the Auth-Type is PAP, CHAP, or MS-CHAP, and then
> runs them through the appropriate module.
> 
> 2) It runs the request through the unix module
> 
> 3) It runs it through the eap module (again, configured in eap.conf)

  Why do you think (2) and (3) are true?

  *READ* the debug output!  It's all there!

  Reading it shows that (2) and (3) are false.  Honestly, it's that simple

  Alan DeKok.