Accept all Auth requests while replying individual parameters

[Alan DeKok]

On Feb 20, 2016, at 9:19 AM, Pavel Uhliar <pavel.uhliar at gmail.com> wrote:
> I am trying to modify existing FreeRADIUS setup (version 2.1.12) to accept
> all Auth requests, while responding to them with individual parameters
> (Framed-IP-Address and Framed-Route) based on Calling-Station-Id.

  You should really upgrade.
 
> I am in a running environment, where until now login requests are
> authorized by User-Name/Password based on radcheck table and individual
> parameters are sent based on the User-Name from radreply table and combined
> with group parameters from radgroupreply table (all MySQL). Users are
> paired to groups by individual entries in usergroup table

  OK...

> I would like to keep intact as much of the structure as possible, I just
> need to stop verifying User-Name/Password (because now whoever is able to
> access physical infrastructure is authorized to use it) and change the
> individual responses to be based on Calling-Station-Id instead of User-Name.

  So put Calling-Station-Id into the "name" field in SQL, and update the SQL queries to use Calling-Station-Id instead of the User-Name

> First I thought the solution will be quite simple:
> 1) I change the SQL query selecting from radreply table to be based on
> Calling-Station-Id

  Yes.

> 2) I add "DEFAULT Auth-Type := Accept" and "Fall-Through=Yes" in
> /etc/raddb/users file

  Yes.

> Step 1 is OK, no problem (change in /etc/raddb/sql/mysql/dialup.conf)
> 
> Problem is in Step 2. It does authorize all requests as expected (even
> those not matching User-Name/Password records in radcheck table), but when
> the User-Name/Password in request does not match User-Name/Password in
> radcheck, RADIUS skips querying the radreply table for additional
> parameters.

  For one, you should NOT be putting User-Password into the radcheck table.  It's been wrong for 10 years.  We've recommended Cleartext-Password.

  Two, if you're going to use Calling-Station-Id, then use it for *both* radcheck and radgroupicheck.

> This results in Auth response containing only parameters
> from radgroupreply table, but none from radreply. Requests containing
> User-Name/Password matching to those in radcheck get full responses
> (with radgroupreply and radreply)

  Then use Calling-Station-Id everywhere.
> 
> WARNING: Found User-Password == "...".
> WARNING: Are you sure you don't mean Cleartext-Password?
> WARNING: See "man rlm_pap" for more information.

  That's a big hint.

> I was trying to find some solution, did try "query_on_not_found"
> configuration directive, did play with "Fall-Through", but nothing seems to
> work. I was not able to force RADIUS to do the radreply query for
> not-matched credentials.

  You don't.  If the radcheck doesn't match, then radreply isn't used.  This is how the SQL module works.

> As other ways to solve the problem, I was trying to use policy to
> rewrite User-Name/Password in request to
> a Calling-Station-Id/<universal-password> to have all request authorized
> under my control, but this is not feasible as devices do not use only PAP,
> but also CHAP and MSCHAP, and password rewriting does not work for
> CHAP/MSCHAP requests.

  Which is why you need to use Cleartext-Password in the database.  So it can match for CHAP requests, when the packet doesn't contain User-Password.

  The error message recommends reading "man rlm_pap".  This all is explained there.

  Alan DeKok.