Trying to wrap my head around FreeRadius config
Moe, John
jmoe at hatch.com.au
Tue Jul 19 06:20:24 CEST 2011
Hello, all
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.
I've managed to get a FreeRadius instance up that will authenticate a
user's logon into a HP ProCurve switch against our Active Directory
using PAP. I'm now trying to get PCs to authenticate to that switch
using 802.1x/PEAP-MSCHAPv2. 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.
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 process below is based on the default install that came with my
distro (Gentoo), in case it differs from other distros. The config I'm
currently using has been modified from this, of course, but as I'm more
interested right now in how it fits together, I figured I'd start with
the default config.
1) When a RADIUS request gets received by the server, it first looks up
the device in the clients.conf file. If it doesn't exist there, it
ignores the request (with a message being logged saying it ignored the
request).
2) If it has the client listed in clients.conf, it then runs the request
through the sites-enabled/default file. That file seems to say,
starting with the authorize section, run it through the preprocess
module, then chap, mschap, suffix, eap, unix, files, expiration,
logintime and finally, pap.
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?
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.
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.
4) Given the information in the config items, it tries match the request
against the unix and files modules, and add/modify config items
appropriately. The "files" module is configured by default to read in
the entries from the users file, where I should add "DEFAULT" entries to
match the various types of authentication and authorization I'm trying
to configure. In there, if it matches against any ruleset, it adds the
reply items to the request.
5) It then runs the config items against the expiration and logintime
modules, which checks the Expiration attribute and some Time attributes
for authorization limitations.
6) It finally runs it through the PAP module to see if it's a PAP
request, and adds "Auth-Type := PAP" to the config items.
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.
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)
At some point, (I believe in both the authorize and authentication
sections, in the eap module), if it finds that a request is using PEAP,
it does much the same thing again, but runs the inner
"data/packet/encryption/not sure what to call it here" through the
sites-enabled/inner-tunnel file, with sections set up similarly to the
sites-enabled/default file.
Then there are the session and post-auth sections, that I haven't even
begun to look into yet; I hope to shortly. I'm skipping the accounting
and proxy sections as for the moment, I'm just trying to get RADIUS
authentication and authorization working, no accounting or proxying
happening.
Any assistance would be appreciated.
John H. Moe
Network Support - Hatch IT
HATCH
Tel: +61 (7) 3166 7777
Direct: +61 (7) 3166 7684
Fax: +61 (7) 3368 3754
Mobile: +61 438 772 425
61 Petrie Terrace, Brisbane, Queensland Australia 4011
*****************************
NOTICE - This message from Hatch is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential or proprietary.
Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. By communicating with us via e-mail, you accept such risks. When addressed to our clients, any information, drawings, opinions or advice (collectively, "information") contained in this e-mail is subject to the terms and conditions expressed in the governing agreements. Where no such agreement exists, the recipient shall neither rely upon nor disclose to others, such information without our written consent. Unless otherwise agreed, we do not assume any liability with respect to the accuracy or completeness of the information set out in this e-mail. If you have received this message in error, please notify us immediately by return e-mail and destroy and delete the message from your computer.
More information about the Freeradius-Users
mailing list