Alan, Alan, Despite trying to be constructive and give some input, especially with respect to helping out newbies who may not necessarily be UNIX programmers or gurus...
... I got the answer I expected from you: crude, insulting, inaccurate and dismissive. Thanks. And you also seem to have completely missed the point I was trying to make (which others got, so I don't think it was my writing)... (In brief: I wasn't commenting on *how* FreeRadius works - I think it's great - but just in some terminology/clarity, mostly as an aid to help users trying to get to grips with it. We're not all UNIX gods.) So, just this once, I'm putting my smiling, helpful, constructive trying-to-understand-and-help persona to one side for a moment because, to be honest, you pissed me off. I apologise in advance for the following, but them's the breaks. Onward then: >> Authenticate: proving the user is who they say they are. >> Authorization: setting limits on what the user can and cannot do. > This comes up again and again. My inclination is say "go write your >own radius server, and you'll see what's missing from yuor ad-hoc >definitions" Compare my above 'adhoc' definition with the one below which you agree '100%' with: well, I read them basically the same. Despite the shortcomings of RADIUS (and I'm no expert here by any means) the rest of the world seems to agree from what I can tell. Why have you changed the meaning of pretty much standard terms? As for writing my own radius server: a nice practical tip that. Not. If you can't be constructive, stay off the list and in your corner. You must have missed the chit-chat about the fact that RADIUS itself is a bit off in the auth vs auth department which is why everyone's RADIUS is a bit squiff when it comes to terminology, but everyone else seems to cope nicely. Never mind. Those people watching closely in the past will know from my posts that I'm neither a UNIX or C programmer (and unfortunately don't have much spare time either for various reasons). And before you say it : Yes, I have, at least indirectly and only in a tiny way, contributed to the FreeRadius community (those old notes starting back in the 0.2 days about using MySQL at http://www.frontios.com/freeradius.html - that was me). Hey, some of us have day jobs and need to earn money to pay the mortgage, feed the family etc... >> Indeed, to pick a definition out of the air, >> http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-10.txt >> defines these words thus: >> >> Authentication >> The act of verifying a claimed identity, in the form of a pre- >> existing label from a mutually known name space, as the >> originator of a message (message authentication) or as the >> end-point of a channel (entity authentication). >> >> Authorization >> The act of determining if a particular right, such as access >> to some resource, can be granted to the presenter of a >> particular credential. > Agreed 100%. IF YOU AGREE 100% WHY DOES FREERADIUS CONFUSE THESE TERMS FOR USERS THEN?? > Question: How do you determine how the server authenticates someone? > Answer : You check which authentication method they are authorized to use. You're stretching definitions a bit here. I would add that if you're 'authorizing' users to use an 'authentication' method you're possibly making a mockery of the fall-through and default user features. Off the top of my head (admittedly with little thought) how about: "answer: the server is bright enough to check each of the methods it has available (maybe to some admin-defined criteria or list) to try to identify (authenticate) then authorize the user". There. Wasn't hard was it? In fact, I think this applies to FreeRadius already. It's just a better way of saying it. Let's be honest - aside from programmers and people writing patches etc, *who cares* what happens 'under the hood' as long as a) it works well and b) people (and by that I mean the average admin) can actually use it and make it work. Otherwise FreeRadius will languish in obscurity and people will be stuck using other solutions. The poor sods. > I think I'm going to write some long text in 'doc/aaa.txt', telling >people that all of their analogies and ad-hoc models are wrong. That I assume would mean yours too... >The server is designed the way it is because it works. Not because it's >perfect, as there's always room for improvements. But it works. See. You missed the point. I have no trouble with FreeRadius and how it actually works - I was talking about a point of clarity/definition/terminology (whatever you want to call it), mostly with respect to helping new users (not even myself - I have this stuff working!). >> In the general sense above, for any kind of system requiring aaa, the >> user would 'authenticate' first and then be 'authorized' to do stuff. > Nonsense. RADIUS servers have been designed similarly to FreeRADIUS >for almost 10 years now. Would you say that for 10 years, those >administrators were deluding themselves, and the servers really didn't >work, because you didn't agree with the design? See previous point. I've no doubt the server is designed right, especially because of the way RADIUS works. That's not what I started this conversation about - please stay on topic. To clarify: I actually think FreeRadius is great. >> There might be a bit of twiddling at a lower level unseen by the masses, >> but this is the essence of the procedure (then followed of course by >> 'accounting'). > > Again, nonsense. Design a RADIUS server, and then see what stages >are required. Thanks for the practical response. I assume you also built your own house, grow your own food and smelted the ore and refined the fuel to build and run your own car. Oh, and wrote *all* the software on your own computer. We don't all have the same skills as you. Many people on this list are (relatively) new to RADIUS let alone FreeRadius. If you're not open to hearing reasonable ideas to maybe improve the software (either technically or in how to make it accessible to users) then why are you involved in an open source project??!? If my point is crap, tell me and tell me why. If my idea is bad, ditto. If I've got the wrong end of the stick then tell me (you don't have to tell me the right answer, just tell me I'm wrong - others here will doubtless point me in the right direction so that I can learn). Just don't give me all this bullshit... >If you're going to do a pre-authentication step of discovering which >authentication method to use, then (for historical reasons, and >because it costs next to nothing), you might as well assume they're >going to be authenticated, and collect a set of reply attributes, too. Yep, I agree. I have no issues with this. Why are you inventing an issue for me here? Did I say I thought this was a problem?? >Pushing the authorization step to AFTER authentication gains little. >But note that in 0.8 and above, there's a post-authentication stage, >in which anyone can do the extra post-authentication work that they >desire. I don't really care the order FreeRadius actually does stuff - as long as it does it the best way (I think it probably does already - it's a pretty groovy bit of software generally speaking). That's not what I was talking about. I didn't say you should do this. Let's talk plain English here for a moment: people say things like "I'm authenticating my users against an SQL database". OK, so this phrase might be technically wrong, but I know what they mean, pretty clearly too. I think people use the word 'authenticate' because they're talking about the place which holds the passwords. They just do. Thus, if a user is 'authenticating against an SQL database' they come unstuck wondering why they put 'sql' in the 'authorize' section in radiusd.conf and not in the 'authenticate' section. That was the point I was trying to make - the users get confused over terminology, so would it be an idea to clear it up a bit. Heck, it's only a small thing. Ok, so they eventually work it out (my mail box testifies to that), but it would probably be easier for them to go from A straight to B without diversions en route... >> For example, it says: "Authorization is a process of obtaining >> information about the user from external source (file, database or >> LDAP), and checking that the information in request is enough to >> authenticate user. > It does more than that. I know. I was making a point. It's usually common sense to do so without waffling on in intricate and unnecessary detail. > See the 'users' file. Quote that at newbies if you will. I know what the users file is. >> 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. WTF? Did you actually read my message(s) or just give them a cursory glance and miss bits? I wasn't bleating about my own config. Yep, I'm lucky to have a simple one. Others aren't. All the more reason to make it clear. And I didn't say that FreeRadius was 'wrong'. >> 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. Are we in the same conversation here?? That's my point. Let me summarize: "I think people might suffer confusion over the section names as they currently stand". >> 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? WTF?!??! Are you making this sh*te up or something? Where did I say that? Where did I say *anything* about the order of attributes in a packet?? I'm also talking about my own view of things. No where did I say "this is right" let alone "the server should do it like this". Don't put words in my mouth. >> 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? See previous point. Just in case you missed it. >> 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. Ah, as useful a tip as ever... >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. Yes. I know that. I think that's right too (I'm not a complete moron). I didn't say it wasn't. I'm not talking about how FreeRadius actually works (got that yet?). >> 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. See. You've just proved that you don't actually read the posts. I *did* make a suggestion. Go read it. > Don't re-design the server until you understand how it works now. How does making a suggestion for a possible alteration to the wording of a couple of config file entries constitute 're-design[ing] the server'??? >> Unfortunately, much to my annoyance, it's not possible - the >> disclaimer is hard-wired to our email server as company policy > Then you should hire real lawyers. The disclaimer has no legal validity >whatsoever. I know that. You know that. I did kind of make the inference that I found it dull (in fact, actually a serious pain and useless) and that it's currently company policy to have it and I'm stuck with it if I post from my mail email account. I'm actually trying to persuade those that do that it's pointless. PS: disclaimers *can* have legal validity. Not necessarily that ours does before anyone starts... >> Back to the topic, maybe something like this (comments removed for >> brevity, and I'm guessing a bit as I'm not sure what all the modules >> actually do in the more obscure cases): >> >> --- >> precheck { >... >> checkuser { >... > Great. You've re-designed the server to do exactly what it's doing now, >but with the names changed. Amazing. He gets it. Finally. Give the man a cigar. > How exaclty does that help? It was a tiny suggestion to possibly help make configuring FreeRadius clearer, especially for new users who, as you point out, keep getting confused over the auth vs auth issue (amongst other things) Well, that's me put off trying to be helpful to this community... and I was desperately trying to find time to update those notes I wrote too... SB <aka [EMAIL PROTECTED]> Scott Bartlett BTA Limited e: [EMAIL PROTECTED] (Please ignore disclaimer below - I can't get rid of it... ;-) --- 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
