LDAP Accounting

[Arran Cudbard-Bell]

On 10 Dec 2012, at 20:45, Peter Lambrechtsen <peter at crypt.co.nz> wrote:

> 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 :)

Yes.

> 
> 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

(big aggregator of subscriber tunnels/traffic in none telco speak)

> 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.

Out of interest what are you using for DHCP?

> 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.

Because LDAP replication *works*.

>  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. -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Arran Cudbard-Bell
a.cudbardb at freeradius.org

Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org

Will code for halva - http://www.amazon.co.uk/gp/registry/wishlist/D1E1QB70FIKC