LDAP Accounting

[Peter Lambrechtsen]

On Tue, Dec 11, 2012 at 4:27 AM, 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?
>
> 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.
>

In our example (which I believe kicked this all off :)

We update our 7 instance Novell eDirectory LDAP Database which replicates
across 3 geographically different sites when a specific Accounting Start
message comes off our BNG saying that the subscribers session has started.
Against the LDAP entry we write a status attribute that includes the
NAS-Port-ID & Framed-IP-Address allocated to the subscriber.  I currently
use a small piece of perl code which is called from the accounting section
to perform this add/delete of the subscriber state.  Since our BNGs
allocate IP addresses using an internal DHCP server.
The reason behind that is once the subscriber attribute has been updated.
All of our subscriber provisioning is to an internal facing instance of the
database so when a subscriber profile is updated (such as to rate limit
them back to "dialup esq speeds" or block / unblock port 25 from the
subscriber if they want to run their own SMTP server, otherwise normally
it's blocked).  The change occurs on an internal instance, the background
eDirectory replication replicates that to the instances sitting in the
core, and we have a Novell Identity Manager driver listening to database
changes, when it sees a change on the database, and the subscriber session
is up it generates a CoA or DM message using the Coova JRadius client back
to the BNG to either change the subscribers profile, or to kick them off
their connection.

It's a very simple with few moving parts solution (which is needed in
carrier grade situation) and yet happily scales to 1million + subs without
too much drama.  We get on average 200k add/updates/delete per day give or
take, and replication tends to sit around 20 seconds at the max where all
instances agree they are up to date.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20121211/b3274840/attachment.html>