> -----Original Message----- > From: [email protected] > [mailto:freeradius-users- > [email protected]] On Behalf Of Alan DeKok > Sent: Wednesday, 20 July 2011 5:53 AM > To: FreeRadius users mailing list > Subject: Re: Trying to wrap my head around FreeRadius config > > 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.
I hadn't seen or heard of that file before. Thanks for the pointer. When I unpacked the sources for FreeRadius (freeradius-server-2.0.5.tar.gz) that Gentoo used to build the server, I found a doc directory, and in there was a "aaa.txt" file, but no "aaa.rst" file; I assume the content is the same? It looks more in-depth and more what I'm looking for. In fact, there's alot of info in that directory that I haven't seen, so I'm going to read that next. > > 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. Where's the guide on setting up both PAP and PEAP-MSCHAPv2 to authenticate both SSH logons and 802.1x requests coming from both HP and Cisco switches and routers using Active Directory? I haven't seen that one, but if you point me to it, I'll follow it. Seriously though, I've found one on PAP, one on ntlm_auth/AD, one on HP, one on Cisco, but when I've followed each one, they doesn't seem to work together properly. At which point, I thought I'd try to understand things a bit deeper so I know which bits from each guide I need to end up with the solution I want. > > 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. Well, that's what I'm trying to do. I'm just trying to understand the sequence first, and ensure I'm trying to configure the right thing in the right place. Then I'll have a look at each piece individually and configure it properly. > 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. Well, now that I know that "suffix" is an instance of "realm", yeah, the debug output does have a few "suffix" lines followed by "rlm_realm". And now, in hindsight, I can see how the messages go together. > 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. > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html I understand what you're trying to tell me. I've seen you make the point again and again in my searches for information: "Follow the guides, and READ (usually emphasized in some way) the debug info". But honestly, I've spent a few weeks now, reading and re-reading config files, wiki articles, mailing list archives (which if I understand correctly, need to be treated with suspicion, as many of them are out of date), and general Googling (also suspect), and I haven't been able to find out how to configure what I'm trying to do. Specifically, I want to set up: a) RADIUS-based authentication against AD using PEAP-MSCHAPv2 to log users into switches b) RADIUS-based authentication against AD using PAP to log users into switches (some of our switches are older and don't support PEAP-MSCHAPv2 for logon, only for 802.1x, so I'm forced to use PAP) c) 802.1x on the same switches, again using PEAP-MSCHAPv2, to authenticate computers (and the users on them) and IP phones to the network and put them in the appropriate VLAN. I've gotten b) to work, although in the debug info, it doesn't explicitly say it's using PAP, only that it's using ntlm_auth to in the authenticate section. I'm trying to get a) to work now, but I'm having trouble working out if I should be using PEAP-TLS, ntlm_auth, another module, or some combination of all of them. And to do that, I need to know what each piece is doing, and how they fit together. Thanks for taking the time to respond, I appreciate it. 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.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
