View Full Version : AP radius authentication
Getting AP radius authentication was a pleasant surprise in the latest release, I *think* I like this new feature a lot, but I have some questions first.
Does it only authenticate associating AP clients and IGNORE WDS ones. Ideally, it will NOT authenticate WDS associations as by default I (implicitly) want them to associate.
Likewise does it authenticate MAC connections on ethx: interfaces
The example script advises setting the default action to radiusd. Is there another way of doing this so I can have an alternative default action.
Apart from NAS-Identifier, what attributes can I use, that will be recognised by staros ?
Tim
WDS links are ignored, and allowed on without authentication.
Radius support is only for Access Points when it get an association request.
For multiple default actions, can you tell me what you had in mind?
At the moment NAS-Identifier is automatically set per AP to the Station Name, however this is only an initial release of the Radius code. We will be providing many more options to allow one to control username, passwords and realms. (and the format of each).
We currently ignore all reply attributes. We may support the maximum session time attribute in the near future.
That all sounds great.
By multiple default actions what I meant was I'd like to have an alternative to checking on a MAC address, so all my customers - (whose MAC address I know) will authenticate with Radius, all other users trying to associate would be allowed on but with limits set (see my attribute wishlist) - I guess the answer to this will lie with the radius server config.
Another question :
I am planning to use PPPoE with all my installs, is there any potential problems with the PPPoE doing an authenticate at the same time as the AP association check. presumably the ap check goes first. The same questions applies for PPtP too.
I guess my real question is will I need to use PPPoE at all (once the reply attributes are supported). It feels to me that the only benefit that I get with PPPoE is that my customers have to present a username/password. And that can be fixed with an Access-Challenge radius response !
Re attributes
If you are going to support attributes for multiple session times, what would also be very useful (& I know that it is something that radius does NOT support) would be the ability to disassociate a client. ie if the Login-Time attribute was set to weekdays only could we get staros to boot clients off at the right time ?
Another nice feature would be the ability to set bw limits (also for different times). In fact the ability to control just about everything using attributes would be useful.
Sorry to be asking for so many things, but you will appreciate this new radius stuff is like a whole new toy chest of goodies - and I cannot help wanting more :D !!!
Which radius are you using btw (freeradius ?)
Tim
I see what you are looking at. The idea sound interesting.
In regards to PPPoE / PPtP; Radius will take care of the authentication portion (ie, what PPPoE's job would be). PPtP is more on the security side of the fence as it requires an authenticated session (via radius or PPPoE) before it can be used, so it should still come in handy for those requiring encrypted sessions.
There is still much to do, and many new ideas to try. some of your ideas may come to light in the near future.
Tony
I'm afraid I've run into a problem with my MAC radius testing. I can't get it to work :cry:
I have filled in all the fields in the radiusd.conf file shown under
wireless > radius authentication setup, saved and reloaded, but nothing has happened. I am getting no calls going through to my radius server. It feels like there is a missing activation option :?:
Tim
georgew
07-28-2003, 01:13 PM
Ok, several things...
On your radius set-up, did you properly configure the clients database with your client secrets, and then configure each authenticating client with the same info, pointing them at the server?
As for the multiple actions thing... That is easy. Use the default user, luke! :idea:
The radius default user stanza is the config the server delivers when the authentication fails. It's been years since I played with it, but it was part of the original radius specification I believe... I assume that it is in the radius server StarOS is using, though I admit I have not checked... The default user could give the user a dead-end config, a config that manages a hotspot, etc.
I don't remember how the default user handles multiple users, I think we could call up ip addresses out of a pool local to the radius client on our radius set-up, they were defined out of 4 pools of addresses that resided on our terminal servers (ascend max's). But I think you can do it in other ways too, either having the user several times in the database with a different IP each time, or by adding code to the radius server... It's been a long time since we worked on this, then we abandoned the idea because before we finished dialup started dying, so the "dialup guest" thing we were working on was put aside.
I will dig into this in further detail and see if I can figure out how it would work with StarOS. It could be that the default user was a local mod, but I don't remember my guys writing that part... I'm pretty sure it is a radius thing.
As for turning users on and off... a simple method would be to add and remove users from the database by swaping the radius users file using a cron job on a unix machine. You can create the radius file from accounting information, turning accounts on and off as is appropriate, then you upload the file to the radius server. We do this hourly on our network. We used to run it every 15 minutes, but I think some of our accounting jobs needed more time to run, so we went to an hourly update. That way you could turn people on and off as their access schedule required, and as their payments became late or get paid.
georgew
07-28-2003, 01:31 PM
Tony,
Which radius server is StarOS running?
StarOS includes Freeradius.
To get the Radius working, simply use lines similar to this:
000210fea14b Auth-Type := Local, User-Password == "000210fea14b"
This is assuming the client's MAC address is 00:02:10:fe:a1:4b. Note the lower-case letters, they are required.
Make sure you have the proper secret in you wlan radius configuration, as well as your main radius server. (very important).
To help troubleshoot, you can enable remote syslog support and keep an eye on the authentication process - it will show any errors that occur while contacting the radius server.
Ok, several things...
On your radius set-up, did you properly configure the clients database with your client secrets, and then configure each authenticating client with the same info, pointing them at the server?
As for the multiple actions thing... That is easy. Use the default user, luke! :idea:
My radius server is interfaced to a MySQL server. I have been using it successfully for PPPoE sessions, and I am able to test it with NTRadPing.
I have set up the username:password entries for my MAC addresses in the sql server database and have tested that they authenticate correctly with NTRadPing
So everything on the radius side seems to be working. ***** I have just found my mistake - I forgot to put the default radiusd entry in the ACL config !!! what a twit. It is working now.
The multiple actions issue, yes I can see what you mean for a user file, but not for an sql one, (I wonder if I create a DEFAULT user if that will work .... I'll try it).
Okay, I'm back !!! It works, all you have to do is put an entry in the radcheck table for the user(s) and instead of putting a Password attrib ==, you put in an Auth-Type := Accept attrib. & it works - excellent !
As for turning users on and off...
This is one of the advantages of an sql db, as the data is always current.
Tim
To help troubleshoot, you can enable remote syslog support and keep an eye on the authentication process - it will show any errors that occur while contacting the radius server.
You will see in my previous post I found my problem no default = radiusd entry in the config file !!!
I did try the syslog trick but never got any log records. I opened up the firewall for udp port 514 (syslog) and was able to see log packets coming in using ipchains & tcpdump, but none got logged to file. I tried adding a *.syslog filename, line to syslog.conf and then restarted syslog using - service syslog restart, but no joy. I suspect my syslog.conf entry was wrong.
As for MAC radius checking :
Everything working nicely now, for authorising access.
The log records show all correct info except the NAS-IP-Address attribute. This is coming through as 127.0.0.1. This particular attrib is sent through to the MySQL accounting records so it would be useful to be able to provide this value as a configuration setting.
This is not urgent as I can use the NAS-Identifier instead.
Tim
Is Radius accounting available in the latest release as we charge for excess data by the MB.
THe new MAC radius authentication does generate accounting records, but the byte values are not generated until the client station disassociates and sends an Account stop status packet. I have enclosed the account start/stop records for a session :
Tue Jul 29 00:42:35 2003
Acct-Session-Id = "00022d51a81d913326331253"
User-Name = "00022d51a81d"
NAS-Identifier = "wlan2"
Acct-Status-Type = Start
Service-Type = Framed-User
Framed-Protocol = PPP
Acct-Authentic = RADIUS
NAS-Port-Type = Async
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
Acct-Delay-Time = 0
Client-IP-Address = xx.xx.xx.xx
Acct-Unique-Session-Id = "b96beea96b37ced4"
Timestamp = 1059435755
Tue Jul 29 00:47:46 2003
Acct-Session-Id = "00022d51a81d913326331253"
User-Name = "00022d51a81d"
NAS-Identifier = "wlan2"
Acct-Status-Type = Stop
Service-Type = Framed-User
Framed-Protocol = PPP
Acct-Authentic = RADIUS
Acct-Session-Time = 310
Acct-Output-Octets = 788
Acct-Input-Octets = 1770
Acct-Output-Packets = 4
Acct-Input-Packets = 13
NAS-Port-Type = Async
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
Acct-Delay-Time = 0
Client-IP-Address = xx.xx.xx.xx
I have replaced the real client-ip-address with xx.xx.xx.xx
One thing you should notice is that the timestamps are 5 minutes apart. That is because I have set my Sta removal value for this interface to be 5 minutes (from a default of 120 mins), so that the station will disassociate quiet clients fast, while I am experimenting. This is probably NOT a good idea !
The NAS-Identifier shown is wlan2, this is the station name for the AP interface and identifies the exact AP. The Client-IP-Address (the one xxx'ed out) is less valuable as it reports the ip address of the ap to radius connection. This means if you have multiple APs behind a NAT bridge they all get the same Client-IP-Address.
Tim