[rad] RE: Free Radius users record samples for SmartEdge router subcriberauthentication.

[Alan DeKok]

Charles Gregory wrote:
> Okay, this isn't just my favorite quibbler jumping on me. So I have to
> ask, even if there is a 'better' syntax, or a 'preferred' way of doing
> things, why is this 'standard' old radius check item so 'wrong'?

  The '==' operator should be *comparing* attributes.  There should be
no magic needed to compare attributes.

  Until 1.1.4, the code had magic specifically for User-Password.  This
kind of magic is wrong on many levels.  It makes the code more complex,
it is inconsistent, and it breaks the principle of "least surprise".

  In addition to that, many authentication methods do *not* contain a
User-Password.  So if we got rid of that magic without doing anything
else, checking "User-Password == foo" for EAP requests will *always*
fail.  This will make administrators unhappy.

  There is a simple solution.  Tell the server what the "known good"
password is.  Let the modules do the authentication.  So the MS-CHAP
module will take the "known good" password, do it's MS-CHAP
calculations, and compare that to what's in the packet.

  The same goes for CHAP, EAP, and other authentication protocols.

  That's why we have Cleartext-Password, NT-Password, Crypt-Password,
and others.  Those are all different forms of the "known good" password.
 And because they are "server side" attributes, they will *never* go
into a packet.  This is a Good Thing.

  This argument is the same argument against using "Auth-Type = LDAP".
LDAP is a *database*.  Using it as an authentication server is *wrong*,
because LDAP servers don't implement CHAP, MS-CHAP, EAP, etc.  Until the
documentation and examples were updated to SHOUT at people "don't use
Auth-Type = LDAP", there were weekly complaints that people had followed
some horrible third-party guide, and couldn't get EAP working.

> I checked the docs, and it *appears* that checking an input attribute
> value against a hard-coded constant is still valid syntax.

  Yes.  And there is magic to deal with User-Password, so that it does
what users expect, and *not* what is the "right" thing to do.

> So why is Input-Attribute == "value" now wrong?

  It's not.  Doing those comparisons on User-Password is wrong.
*Unless* you want to break every authentication method other than PAP.

> Or is '==' deprecated for all check items past a certain release?

  No.

> If so, why is it still in the 'users' man page for 2.x?

  Because it works.

> I finally noticed that "Cleartext-Password" is not an input attribute,

  Yes.  It's a "check" attribute.  See the "users" file documentation
for how check attributes are treated.

> which suggests that there is something 'different' about the way we're
> now specifying input attribute checking in the users file. I don't doubt
> that it 'makes sense' according to some new way of doing things, but it
> looks like an amazing departure from 'classic' Livingston syntax....

  Yes.  The Livingston server was wrong.  It had magic to deal with
'User-Password = foo', that made it work for CHAP authentication.  This
was (and still is) ugly.

  The Livingston server also read the entire "users" file into memory
for *every* request.  That behavior was wrong, too.

  The Livingston server didn't cache requests and responses, so it would
re-process duplicates, causing unnecessary delays and load.  See RFC
5080 for the *FreeRADIUS* way of doing things, which all RADIUS servers
have now implemented.

> If so, I'm *really* glad I didn't upgrade my live version. :-O

  Upgrading versions always requires care and attention.  This is no
different.

  Alan DeKok.