Help with redundant autz

[Alan DeKok]

On Mar 2, 2017, at 5:12 AM, Paolo Cecchini via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> 
> First at all a few words about me, I’m from Italy and I work at my city, Urbino, University. Our AAA is freeradius based.
> 
> Student credential’s authoritative source is an Oracle database located outside of the local net, because the application is outsourced. Credentials went synced hourly to our internal LDAP.

  I presume that passwords are changed more often than that.

> We experienced sporadic black out with that database and in effort to mitigate the issue we’re planning to switch the first source to LDAP.

  Except if you're still using that SQL server, having it go down will still block FreeRADIUS.
> Something like this.
> 
> Users ….
> 
> DEFAULT Realm == "stud",Autz-Type := stud, Auth-Type := PAP

  You typically shouldn't set Auth-Type.  It's just not necessary.

> Now, scenarios.
> 
> a)The user is found in ldap, ldap_stud module returns ok, the password is checked via pap and matches, access-accept. The sql module is skipped, as intended.
> 
> b)The user is NOT found in ldap, the module returns notfound, proceed to sql_stud module (the same if ldap crashes, via fail)
> 
> c)The user IS FOUND in ldap but the user made a password change and ldap is not synced. The ldap_stud module returns ok, but now the pap will reject the authentication. Btw the sql_stud module is skipped, of course, because the previous returned ok.
> 
> I tried my best to solve the issue but that’s apparently far beyond my skill J

  If the password hasn't been synced, then the only real solution is to fix the sync issue so that the password *is* synced.

  There shouldn't be any issue with syncing passwords every 30-60s.  And 90% of the time, there won't be any changes.

  You should be able to SELECT the SQL rows which have changed since the last sync.  Then, write those to LDAP.

  If your database can't handle one SELECT statement every 30 seconds... it's time to throw it in the garbage.

> But when the sql is unattainable the radius will time-out a lot.

  Yes.  Which is why you don't want to check SQL when the password is wrong.  Because attackers will be trying random passwords, and you don't want those wrong passwords to cause SQL lookups.

  Stop trying to butcher the FreeRADUS configuration.  There is nothing you can do to FreeRADIUS to (a) fix the sync issue, or (b) make the SQL database responsive.

  Fix the underlying problem.  Only that will help.

  Alan DeKok.