Auth failed accounts and write to SQL database

[Matthew Newton]

On 20/03/2023 17:29, Steven Walters (S) wrote:
> On a regular basis we have PPPoE customers whose authentication fails either due to incorrect password or suspension which ends up phoning the call centre because they have no internet connection.

A common occurrence...

> What I want to do, testing with the "guest" username, is to authorize customers with incorrect password or suspension, provide them with limited internet access to be redirected to a website

OK. Would have been clearer to say that the first time as it looked like 
it was just for one user.

> To achieve this, I need to write a value to a database field (that is what I am trying to do with post-auth) during authentication to identify these customers accordingly e.g., customers with incorrect password. When I receive the accounting start, I read this value from the database which I add as an attribute to the accounting start message before proxying  it to our PCRF. On the PCRF I will then add rules based on the value of this attribute. For example, if a customer has incorrect password on modem, route the customer to a website which displays a message that modem has incorrect password configured on modem and will have limited internet access until fixed.

So more like your original idea should work, if you want to blindly 
accept everyone.

   Auth-Type PAP {
     pap {
       reject=1
     }
     if (reject) { # with the &User-Name == "guest" for testing if wanted
       update request {
         &Tmp-String-1 := "reject"
       }
       accept
     }
   }

Then in post-auth you could do something like this

if (&request:Tmp-String-1 && &request:Tmp-String-1 == "reject") {
   if ("%{sql:INSERT INTO table ... whatever}") {
     noop
   }
}

or just update the post auth SQL query to add something else to the 
table. Most systems you'd just return e.g. a VLAN id in the 
Access-Accept to drop the user into a restricted network.

If you have to do something weird with Accounting packets instead then 
you'll need to tie the auth accept up with the incoming accounting 
start. Easiest way to do that if your NAS supports it is to set a Class 
attribute in the Access-Accept - then the NAS should send that back into 
the accounting start for you to use.

Set Class in a useful way and you can probably avoid the SQL update 
entirely.

-- 
Matthew