a.cudbardb at freeradius.org
Mon Dec 10 16:56:00 CET 2012
On 10 Dec 2012, at 15:27, John Dennis <jdennis at redhat.com> wrote:
> On 12/09/2012 07:33 PM, Arran Cudbard-Bell wrote:
>> Just pushed up a few patches to add LDAP accounting.
> Just out of curiosity why are we adding support for "worst practice", shouldn't we be encouraging "best practice" via the choice of supported configurations?
It seemed like something fun and potentially useful.
> Maintaining accounting data in LDAP is an abuse of the LDAP design goals of "frequent lookup, infrequent modification". Databases were designed for the type of data management that radius accounting involves, directories were not. Accounting should be in a database, not a directory. Directories were designed to solve different problems. Maintaining authentication and identity information across an enterprise is exactly one of those problems LDAP was designed to handle which makes auth/authz lookups in a directory appropriate. Maintaining accounting information in a directory is not.
Sure, but it also contains authorization information too. The new code can be used to do things like set authentication lockouts on authentication failure, automatically rehash passwords, update current session IDs.
For smaller sites the frequency of updates is very unlikely to cause issues, for larger ones, yes, they should look into a proper SQL (PostgreSQL) or noSQL database (Cassandra).
I don't see why we should avoid supporting something that people have requested, which was fairly easy to implement, just because it does fit the original problem the protocol was designed to solve.
If people do take down their enterprise LDAP directory then that is *their* issue. We should not avoid implementing potentially useful features because someone might misuse them.
The current system also prevents people attempting full session accounting by not allowing the creation or deletion of objects (which would have been fairly trivial to add). That said, I would gladly add full object creation and deletion support if someone came up with a decent use case, i've just not seen one yet.
More information about the Freeradius-Devel