Check List for Integrating Active Directory to Your Bandwidth Controller

By Art Reisman, CTO,

Art Reisman CTO

The problem statement: You have in place an authentication service such as Radius, LDAP, or Active Directory, and now you want to implement some form of class of service per customer. For example, data usage limits (quotas) or bandwidth speed restriction per user. To do so, you’ll need to integrate your authentication device with an  enforcement device, typically a bandwidth controller.

There are products out there such as Nomadix that do both (authentication and rate limiting),  but most authentication devices are not turn-key when it comes to a mechanism to set rate limits.

Your options are:

1) You can haggle your way through various forums that give advice on setting rate limits with AD,

2) Or you can embark on a software integration project using a consultant to accomplish your bandwidth restrictions.

In an effort to help customers appreciate and understand what goes into such an integration, I have shared notes that I have used as starting point when synchronizing our NetEqualizer with Radius.

1) Start by developing (borrowing if you can) a generic abstract interface (middle ware) that is not specific to Active Dircectory, LDAP or Radius. Keep it clean and basic so as not to tie your solution to any specific authentication server.  The investment in a middle ware interface is well worth the upfront cost.  By using a middle layer you will avoid a messy divorce of your authentication system from your bandwidth controller should the need arise.

2) Chances are your bandwidth controller speaks IP, and your AD device speaks user name. So you’ll need to understand how your AD can extract IP addresses from user names and send them down to your bandwidth controller.

3) Your bandwidth controller will need a list of IP’s or MAC addresses , and their committed bandwidth rates. It will need to get this information from your authentication database.

5) On a cold start, you’ll need to make bandwidth controller aware of all active users, and perhaps during the initial synchronization, you may want to pace yourself so as to not bog down your authentication controller with a million requests on start-up.

6) Once the bandwidth controller has an initial list of users on board, you’ll need to have a back ground re-synch (audit) mechanism to make sure all the rate limits and associated IP addresses are current.

7) What to do if the bandwidth controller senses traffic from an IP that it is unaware of? You’ll need a default guest rate limit of some kind for unknown IP addresses. Perhaps you’ll want the bandwidth controller to deny service to unknown IPs?

8) Don’t forget to put a timeout on requests from the bandwidth controller to the authentication device.

Integrating NetEqualizer with Active Directory

By Art Reisman


I have to admit, that when I see this question posed to one of our sales engineers, I realize our mission of distributing a turn key bandwidth controller will always require a context switch for potential new customers.

It’s not that we can’t tie into Active Directory, we have. The point is that our solution has already solved the customer issue of bandwidth congestion in a more efficient way than divvying up bandwidth per user based on a profile in Active Directory.

Equalizing is the art form of rewarding bandwidth to the real time needs of users at the appropriate time, especially during peak usage hours when bandwidth resources are stretched to their limit. The concept does take some getting used to. A few minutes spent getting comfortable with our methodology will often pay off many times over in comparison to the man hours spent tweaking and fine tuning a fixed allocation scheme.

Does our strategy potentially alienate the Microsoft Shop that depends on Active Directory for setting customized bandwidth restrictions per user ?

Yes, perhaps in some cases it does. However, as mentioned earlier, our mission has always been to solve the business problem of congestion on a network, and equalizing has proven time and again to be the most cost effective in terms of immediate results and low recurring support costs.

Why not support Active Directory integration to get in the door with a new customer ?

Occasionally, we will open up our interface in special cases and integrate with A/D or Radius, but what we have found is that there are a myriad of boundary cases that come up that must be taken care of. For example, synchronizing after a power down or maintenance cycle. Whenever two devices must talk to each other in a network sharing common data, the support and maintenance of the system can grow exponentially. The simple initial requirements of setting a rate limit per user are often met without issue. It is the follow on inevitable complexity and support that violates the nature and structure of our turn-key bandwidth controller. What is the point in adding complexity to a solution when the solution creates more work than the original problem?

See related article on the True Cost of Bandwidth Monitoring.

%d bloggers like this: