TekRADIUS Forum

13.07.2010 05:19:24 jkb Posts: 2

I have been testing out the software for a a few days and found some very useful features that it lacks. We are using Microsoft IAS (AD Auth) with ProxyRadius for Hotpost Card system (RADIUS Manager). We would like to migrate from both of them to your solution. Currently out setup support more than 2000 CPEs (Monthly subscribers) and a few hundred hot users. The metro network has over 120 APs and growing every week. Here’s a list of feature that would make this software a lot better: 1. Regular expressions – It would be great if the software can support regular expressions for checks because each of our NAS has multiple SSIDs and the “Called-Station-Id” follows a standard how we identify a matching policy on this. i.e. rightnow we use simple: access* as the called-station-id (access-AP##) with TekRADIUS we tried access* and clients get auth fail. I know we can add multiple called-station-id parameters into a single line divided by colons, this a nightmare to add every single called-station-id in our network. With a simple reg expression it’s hassle free J Check out http://www.ultrapico.com/ 2. Client – NAS (you should be able to classify clients using CIDR i.e. 10.2.0.0/8) this way we don’t need to add 120APs. I know it’s possible to use “Default” as a work around as well for the mean time. 3. True SQL Integration – Our current custom system is built on .NET/SQL/AD that does accounting, auth, tower stats, IP, SNMP etc.. Is it possible to pull variables from SQL? i.e. clients CPEs MAC is the user name and we would like to pull the “Framed-IP-Address” on success reply to give the client the IP that’s in our current DB. Or another example would be pulling the Group the client belongs from another SQL DB making sure the names match the TekRADIUS groups this way we offer our active, pastdue, suspended and unAuth customers a different logon / advertisement page using MikroTik. Currently we SYNC SQL users with AD but it’s a bit problematic. If this can’t be done we’ll just write data from our SQL tables into TekRADIUS and see how it work on a few test APs. We looked at using the “External-Executable” attribute this can only return 0 or 1 and multiple queries will be intensive on the system since each command line gets execute in its own environment. 4. SQL – Second DB – This would be nice if TekRADIUS can specify a 2nd DB for fail over so users can get AUTH when SQL is down or there’s WAN problem, I know session state tables will be problematic but as long as they can AUTH when primary SQL is down or WAN connection in a region it would be good. 5. Attribute rules (search and replace) – With some NASes they pass the MAC as xx:xx:xx:xx:xx:xx and there’s no way to change it. A simple attribute rule that we use in IAS such as find “:” replace with “”. This fixes the issues because AD can’t take colons “:” in a user name. Also our SQL MAC address database has no “:” if this is not possible we can get around that in modifying the sync of users between our DB and TekRADIUS. 6. RADIUS Proxy – This is not required if we consolidate to your system but it’s good if you have an enterprise wide network and integrate with iPASS or boingo for example. In IAS we can write a policy that matches an attribute(s) using regular expressions or a relam/domain. If matched it can be forwarded to a remote RADIUS server. Within radius proxy we have attribute rules as well. I think that’s all for now sorry if my grammar is a bit off. It’s been a few long days of work. Cheers, Jakub

0 • permalink

---