Proxy Treatment of PAP/Chap Auth Types

[Alan DeKok]

James T Mugauri wrote:
> We have 2 RADIUS installations, thus:
> 1. FreeRADIUS/mysql Version 2.1.1, in whose radcheck, Password attribute
> is 'User-Password'

  Change that to Cleartext-Password.

> 2. FreeRADIUS/mysql Version 2.1.10, in whose radcheck, Password
> attribute is 'Cleartext-Password'
> 
> On both freeradius servers sql and perl modules are enabled in authorize
> and accounting groups, and both servers accept PAP and CHAP auth if
> queried directly

  So that seems to work.

> Server 2 is configured to proxy requests for unknown users for certain
> prefixes/suffixes to server 1, if perl and sql return no user:
> 
> authorize {
> preprocess
> chap
> mschap
> digest
> eap {
> ok = return
> }
> files
> expiration
> logintime
> sql 
> perl
> if (notfound) {
> suffix
> hotspotUser
> }
> pap
> }

  I'm presuming that "suffix" and/or "hotspotuser" sets Proxy-To-Realm.
 Do they actually do that?

> Challenge is, on Server 2, testing with radtest (passing the attributes
> so: radtest -t <type> iS_u2h4gna a2uwv localhost 1812 secret) , local
> users are authed fine, but non-local users always return with a reject.

  So *what* returns a reject?  Server 2?  Or server 1?  Your statement
isn't clear about that.  Knowing that will help.

> Debug output of server 1, if I use CHAP to attempt auth with radtest on
> server 2, is always:

  <sigh>  The point of running the server in debugging mode is to read
the ENTIRE THING.  If it's doing something wrong, you need to see if
it's doing what you expect.  i.e. proxying.

> ++[pap] returns noop
> Found Auth-Type = CHAP
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> !!!    Replacing User-Password in config items with
> Cleartext-Password.     !!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> !!! Please update your configuration so that the "known
> good"               !!!
> !!! clear text password is in Cleartext-Password, and not in
> User-Password. !!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> +- entering group CHAP {...}
> [chap] login attempt by "iS_u2h4gna" with CHAP password
> [chap] Using clear text password "uz3f9" for user iS_u2h4gna
> authentication.
> [chap] Password check failed

  It's trying to authenticate the user locally.  I thought you said that
it didn't do that?

  Have you checked if it's proxying the user?

> ++[chap] returns reject
> Failed to authenticate the user.
> Using Post-Auth-Type Reject
> +- entering group REJECT {...}
> 
> If, I use PAP with radtest on server 2, server 1 returns

  Please be careful with terminology.  Use "home server" and "proxy",
not "1" and "2".  It's more descriptive, and easier to understand.

> ++[pap] returns updated
> Found Auth-Type = PAP
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> !!!    Replacing User-Password in config items with
> Cleartext-Password.     !!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> !!! Please update your configuration so that the "known
> good"               !!!
> !!! clear text password is in Cleartext-Password, and not in
> User-Password. !!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> +- entering group PAP {...}
> [pap] login attempt with password "a2uwv"
> [pap] Using clear text password "uz3f9"
> [pap] Passwords don't match

  Which is a different access request.

  Please don't mix and match random traffic.  You need to follow *one*
packet through the system.  Doing anything else is wasting your time.

> I have tried changing the "known good" clear text password on server 1
> as recommended in the warning to no effect. (Is this because
> User-Password and Cleartext-Password must necessarily be the unequal and
> co-related)?

  Changing Cleartext-Password won't fix a broken proxy.  You're changing
something OTHER than the cause of the problem.

> If so, How can i convert 1 to the other?

  You don't.  You *do* use industry standard terms, and you *do* post
the full debug output.

  Once you do, I'll wager that the problem is pretty simple.  Just
reading the debug output solves 90% of common issues.

  Alan DeKok.