Hello together, I have setuped a radius system like eduroam with 3 server. I use "daloradius" for user and accounting management. Authentication and accounting works with realm, but the field realm is empty in table radacct. Furthermore, I want to know how I use / configure Hot Spots in "daloradius". I can't find any description about that. It's rly hard to learn freeradius without a good wiki or something else. There are two locations A @sb-dfki.de and B @kl-dfki.de with their radius server. And a global Server only for Radius proxyforwarding. I've got my client and an access point 172.16.18.82 on location A. I think my configuration is ok. If not, pls tell me. You can see my Debuglogs with a Login by markus@kl-dfki.de Location A http://pastebin.com/A1HNtSeu Location B http://pastebin.com/Q2DWbTes Thank you! Xylakant
xylakant@vorsicht-bissig.de wrote:
Authentication and accounting works with realm, but the field realm is empty in table radacct.
Does the accounting packet have a username with a realm? The debug log says "no". Please *read* the debug log. It has a lot of information and can be hard to understand. But it shouldn't be hard to look for an accounting packet, and then look for "realm". If there are no references to "realm"... that explains why the realm isn't in the radacct table.
You can see my Debuglogs with a Login by markus@kl-dfki.de
No. Read the debug log. Alan DeKok.
Yes I, know. I always read the debug. But I don't know to change it! My biggest problem is, that I can't find any good descriptions about freeradius config. Everything I learn by reading other stuff from forum and blogs. The wiki of freeradius is bad. I've got a old book Radius from O'reilley, but this so about freeradius v1. So couldy you help me? Thank you
-------- Original-Nachricht -------- Datum: Wed, 10 Oct 2012 10:32:02 -0400 Von: Alan DeKok <aland@deployingradius.com> An: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Betreff: Re: No Realm in table radacct
xylakant@vorsicht-bissig.de wrote:
Authentication and accounting works with realm, but the field realm is empty in table radacct.
Does the accounting packet have a username with a realm? The debug log says "no".
Please *read* the debug log. It has a lot of information and can be hard to understand. But it shouldn't be hard to look for an accounting packet, and then look for "realm". If there are no references to "realm"... that explains why the realm isn't in the radacct table.
You can see my Debuglogs with a Login by markus@kl-dfki.de
No. Read the debug log.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
xylakant@vorsicht-bissig.de wrote:
Yes I, know. I always read the debug. But I don't know to change it!
The User-Name comes from the user. Log in using a realm, and FreeRADIUS will use it.
My biggest problem is, that I can't find any good descriptions about freeradius config.
I guess the thousands of lines of documentation in the config files don't help.
Everything I learn by reading other stuff from forum and blogs. The wiki of freeradius is bad.
It is written by volunteers.
I've got a old book Radius from O'reilley, but this so about freeradius v1.
And it's content is largely copied from the FreeRADIUS documentation.
So couldy you help me?
With *what*? Ask good questions. What do you want to do? Magically invent a realm where none exists? Alan DeKok.
The user markus@kl-dfki.de is saved in the mySql database as user markus on Server B. So i activate module suffix to check for the realm and then it checks this user in the database. This works, but the server answers only, that he knows "markus", not "markus@kl-dfki.de". What should I do to configure my radiusserver to recive the realm of "markus"? THX
Hello again, sorry for the late answer, but I tried to resolve the problem for myself and learnd more about the process of freeradius. So my problem is always that the radius doesn't reply the realm of the authenticated user. The server dectects the realm and knows about it ( %{Realm} ->. "kl-dfki.de" ). But in the Access-Accept is not the realm attribute. I tried to update it manualy without success. Other attributes like 3Com-Ip-Host-Addr are possible to send. Sending Access-Accept of id 188 to 172.16.3.225 port 1814 User-Name = "markus" MS-MPPE-Recv-Key = 0x19bfda63662c5eda0d0cfd34c617f262ae8611b10aab33c89598e9478000e667 MS-MPPE-Send-Key = 0xa653fb00f50ffb9b86c15b777bc4d6807912c23511749aef1d030b87cb3b0619 EAP-Message = 0x03e00004 Message-Authenticator = 0x00000000000000000000000000000000 3Com-Ip-Host-Addr = "123.456.789.012" Proxy-State = 0x323437 Proxy-State = 0x323132 In "post-auth" of my "default" config: update reply { #Realm Realm = "%{Realm}" } update reply { 3Com-Ip-Host-Addr = 123.456.789.012 } Here you can see the log: http://pastebin.com/fhvtnyv8 I hope you can help me. Thanks Ulf
Sending Access-Accept of id 188 to 172.16.3.225 port 1814 User-Name = "markus" MS-MPPE-Recv-Key = 0x19bfda63662c5eda0d0cfd34c617f262ae8611b10aab33c89598e9478000e667 MS-MPPE-Send-Key = 0xa653fb00f50ffb9b86c15b777bc4d6807912c23511749aef1d030b87cb3b0619 EAP-Message = 0x03e00004 Message-Authenticator = 0x00000000000000000000000000000000 3Com-Ip-Host-Addr = "123.456.789.012" Proxy-State = 0x323437 Proxy-State = 0x323132
You should add "nostrip" into your local realm definition: # raddb/proxy.conf realm kl-dfki.de { nostrip }
Here I'm again, ;-) so worked on my problem this evening, but all the time without success. :-( So I thought Realm is a Radius Attribute, but now I think its only a temporay variable on the radius server. Cause I can't find it on IANA Attributes. So this is the wrong way to submit the realm adress of the user. The users are saved in the database without the realm suffix. ( "markus" ). I watched my user-name in post-auth, before it is sending the access-accept message: expand: %{Realm} -> kl-dfki.de ++[reply] returns ok expand: %{User-Name} -> markus@kl-dfki.de ++[reply] returns ok Like I said in my last mail, the username is in the access-accept message is only "markus" and no realm attribute. Please tell me, what and where I can fix that. Ulf
xylakant@vorsicht-bissig.de wrote:
So I thought Realm is a Radius Attribute, but now I think its only a temporay variable on the radius server. Cause I can't find it on IANA Attributes.
That's right. It doesn't ever go into a RADIUS packet.
Please tell me, what and where I can fix that.
You don't. The NAS only understands attributes in its internal dictionary. Adding a realm to the FreeRADIUS dictionary doesn't change the NAS. Please explain why you need to send the realm to the NAS, and why you think the NAS will understand it. Alan DeKok.
Hello, in the radacct table are saved the authorized sessions of the user. I use the database schema of daloradius. There is a column with realm, which is empty. It would be nice, if there is something into to work with it. And without the full userdetails the accounting is not working. Cause the local server knows only "markus" he send his Account-Request to DEFAULT and this server can not proxy this one. Cause he has no realm, too. I'm wondering me, cause this "Global" Server now replies this request. I want to send attributes in the accounting area and put them into the radacct table. But not without the forwarding of the accounting request. The transmission of some attribute works in authorize. Do you understand my problem? Thanks Ulf
On Sat, Oct 20, 2012 at 7:15 PM, <xylakant@vorsicht-bissig.de> wrote:
I want to send attributes in the accounting area and put them into the radacct table. But not without the forwarding of the accounting request.
The transmission of some attribute works in authorize.
Do you understand my problem?
No. I'm having a hard time understanding your english. You'd probably be able to find more help if you spend some more time determening what your problems are, and write them in an understandable manner. Anyway, I'm going to take a guess based on the debug log you posted earler. Here's another hint: you'd be able to get more help if you: (1) Try to read and understand the log first. Often the logs tell you everything you need if you just read them. (2) Paste it directly inline instead of in pastebin. Anyway, back to the log. I'm using the one you posted as "Location A http://pastebin.com/A1HNtSeu ". In it there's these entries: ... rad_recv: Accounting-Request packet from host 172.16.18.82 port 53432, id=35, length=189 Acct-Session-Id = "50758488-00000002" Acct-Status-Type = Stop Acct-Authentic = RADIUS User-Name = "markus" ... and ... rad_recv: Access-Request packet from host 172.16.18.82 port 36327, id=36, length=175 User-Name = "markus@kl-dfki.de" NAS-IP-Address = 172.16.18.82 ... Short version, your NAS (172.16.18.82) sends inconsistent user name. It sends "markus@kl-dfki.de" for access-request, but "markus" for accounting. Fix the NAS. Period. -- Fajar
On Sat, Oct 20, 2012 at 11:17:21PM +0700, Fajar A. Nugraha wrote:
Short version, your NAS (172.16.18.82) sends inconsistent user name. It sends "markus@kl-dfki.de" for access-request, but "markus" for accounting. Fix the NAS. Period.
I don't know about different NASes, but ours send the User-Name in the Accounting-Request that was returned to the NAS in the Access-Accept, not the User-Name that they used in the Access-Request. Therefore the result from FreeRADIUS does directly affect what is sent for Accounting. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Sun, Oct 21, 2012 at 12:25 AM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Sat, Oct 20, 2012 at 11:17:21PM +0700, Fajar A. Nugraha wrote:
Short version, your NAS (172.16.18.82) sends inconsistent user name. It sends "markus@kl-dfki.de" for access-request, but "markus" for accounting. Fix the NAS. Period.
I don't know about different NASes, but ours send the User-Name in the Accounting-Request that was returned to the NAS in the Access-Accept, not the User-Name that they used in the Access-Request. Therefore the result from FreeRADIUS does directly affect what is sent for Accounting.
In that case you need to tell the owner of the remote radius (172.16.3.225) to fix their system. Cause FR pretty much only proxy what they send. Sending Access-Request of id 147 to 172.16.3.225 port 1812 User-Name = "markus@kl-dfki.de" NAS-IP-Address = 172.16.18.82 ... Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Accept packet from host 172.16.3.225 port 1812, id=147, length=172 User-Name = "markus" AFAIK many people on this list use eduroam (I don't, BTW). If you take some time to ask your question in a more understandable manner, they might be able to help you more. But they can't do anything if they don't even understand your question. What I don't understand is how come the reply that FR sends STILL contains User-Name. Reading raddb/attrs and raddb/modules/attr_filter, it looks like FR should never allow User-Name on Access-Accept. Did you REMOVE attr_filter.post-proxy from raddb/sites-available/default or whatever virtual server you're using? You might want to try simply REMOVE User-Name attribute from the Access-Accept packet using unlang. If you want to try this, see the man page, look for "-=". You should be able to add it in post-proxy section. -- Fajar
Hi Guys, thank you for your answers. I killed the attribute user-name on my global radius server in post-proxy and post-auth sections by unlang. Now I have got the full username on my server, because it is not overwritten by other radius communicatons. The realm is not in the radacct table of server A. But I kow the reason, because FR doesn't know this realms. But thats ok.
What I don't understand is how come the reply that FR sends STILL contains User-Name. Reading raddb/attrs and raddb/modules/attr_filter, it looks like FR should never allow User-Name on Access-Accept. Did you REMOVE attr_filter.post-proxy from raddb/sites-available/default or whatever virtual server you're using?
Sry, I don't understand the problem. I see more attributes than just user-name. All filters are disabled by default. A filter is only for rejecting requests, which are not matching. Right? And sorry again for my bad english. ;-) Ulf
On Mon, Oct 22, 2012 at 11:13 PM, <xylakant@vorsicht-bissig.de> wrote:
Hi Guys,
thank you for your answers. I killed the attribute user-name on my global radius server in post-proxy and post-auth sections by unlang.
Now I have got the full username on my server, because it is not overwritten by other radius communicatons.
The realm is not in the radacct table of server A. But I kow the reason, because FR doesn't know this realms. But thats ok.
Good to know.
What I don't understand is how come the reply that FR sends STILL contains User-Name. Reading raddb/attrs and raddb/modules/attr_filter, it looks like FR should never allow User-Name on Access-Accept. Did you REMOVE attr_filter.post-proxy from raddb/sites-available/default or whatever virtual server you're using?
Sry, I don't understand the problem. I see more attributes than just user-name. All filters are disabled by default. A filter is only for rejecting requests, which are not matching. Right?
No. And that, is the root of your problem: blindly changing config files without knowing what it's for. Had you left it the way it was in the first place, you wouldn't have had this problem. -- Fajar
participants (5)
-
Alan DeKok -
Fajar A. Nugraha -
Iliya Peregoudov -
Matthew Newton -
xylakant＠vorsicht-bissig.de