Hello, Running FreeRadius 2.0.5, with the following log related config: logdir = syslog log { log_destination = syslog syslog_facility = local7 stripped_names = no auth = yes auth_badpass = no auth_goodpass = no } I've found lots of conflicting info among the wiki, documentation, and list suggesting different statements (log_destination=, destination=), and perhaps outside of log{}. I did look at the code, and it looks to me as if log_destination is the proper statement. Regardless of what I try (and I have tried both destination= and log_destination=, both inside and outside of log{}), the server does not show it as a parsed command when I fire up attached with debugging: [root@h36laa001:/etc/raddb]% radiusd -X -f FreeRADIUS Version 2.0.5, for host x86_64-redhat-linux-gnu, built on Aug 14 2008 at 23:20:24 Copyright (C) 1999-2008 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License v2. Starting - reading configuration files ... including configuration file /etc/raddb/radiusd.conf including configuration file /etc/raddb/clients.conf group = radiusd user = radiusd including dictionary file /etc/raddb/dictionary main { prefix = "/usr" localstatedir = "/var" logdir = "syslog" libdir = "/usr/lib64" radacctdir = "syslog/radacct" hostname_lookups = no max_request_time = 30 cleanup_delay = 5 max_requests = 1024 allow_core_dumps = no pidfile = "/var/run/radiusd/radiusd.pid" checkrad = "/usr/sbin/checkrad" debug_level = 0 proxy_requests = yes log { stripped_names = no auth = yes auth_badpass = no auth_goodpass = no } } I'm sure I'm just missing something simple. Any ideas? --phil
Hi, where can I learn more about stripped usernames?! Thanks, Leander
What else is there to know apart from that you get it when you strip the realm from the username? Ivan Kalik Kalik Informatika ISP Dana 15/10/2008, "Leander S." <leander.schaefer@gmx.net> piše:
Hi,
where can I learn more about stripped usernames?!
Thanks,
Leander - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
The only thing I know about it is, that the username is not standing alone anymore like it was - but instead it's username@domain which looks to me like the stripped user will only connect to the NAS which belongs to this domain even if there might be a second RADIUS .... is it like that? And if the case would be that the RADIUS Server wich belongs to this domain is just proxying to another, then the request will be forwarded to another RADIUServer ... ?! Is that what you mean with proxying? Cause it sounds more like forewarding ... !? ... I mean I've alreadey a running RADIUS SQL test-system - but a szenario like described above would be very interesting for my new network environment .. so I would like to know what positiv options it might bring to stripp usernames ... and also some about proxying ... Thanks for some new be attention ;) Leander tnt@kalik.net schrieb:
What else is there to know apart from that you get it when you strip the realm from the username?
Ivan Kalik Kalik Informatika ISP
Dana 15/10/2008, "Leander S." <leander.schaefer@gmx.net> piše:
Hi,
where can I learn more about stripped usernames?!
Thanks,
Leander - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
The only thing I know about it is, that the username is not standing alone anymore like it was - but instead it's username@domain which looks to me like the stripped user will only connect to the NAS which belongs to this domain even if there might be a second RADIUS .... is it like that?
Sort of. It's quite unlikely that you will have same user/pass in your database as well.
And if the case would be that the RADIUS Server wich belongs to this domain is just proxying to another, then the request will be forwarded to another RADIUServer ... ?!
Not very likely. It is usually the home server and it will accept or reject the request. But it can be relayed further too.
Is that what you mean with proxying? Cause it sounds more like forewarding ... !?
Does it? http://en.wikipedia.org/wiki/Proxy_server It helps when you know what you are talking about.
.... I mean I've alreadey a running RADIUS SQL test-system - but a szenario like described above would be very interesting for my new network environment .. so I would like to know what positiv options it might bring to stripp usernames ... and also some about proxying ...
It works sort of like this: your radius server recieves a request from user@realmx. You don't do realmx, but you know a man who does. He is a friend of yours and you have agreed to let his lot onto your network. You have his radius server configured in proxy.conf. He also knows that you might be sending such requests his way so he has your server configured in his clients.conf. If you are sending the request to the server that should "know" the user (home server) you normally strip the username. If you are sending to the proxy chain (like EDUROAM) you don't. Ivan Kalik Kalik Informatika ISP
Phillip Heller wrote:
I've found lots of conflicting info among the wiki, documentation, and list suggesting different statements (log_destination=, destination=), and perhaps outside of log{}.
The configuration files contain the most up-to-date description of the configuration.
I did look at the code, and it looks to me as if log_destination is the proper statement.
That's accepted for backwards compatibility. The *preference* is just "destination", inside of the "log" section. "log_destination" inside of the "log" section won't work. "log_destination" *outside* of the "log" section might work. The log destination is parsed before other configuration directives... to ensure that the logs go to the right place. See also 2.1.1, which has a number of fixes. Alan DeKok.
participants (4)
-
Alan DeKok -
Leander S. -
Phillip Heller -
tnt＠kalik.net