Fail to restart radiusd
Hi, We're running freeradius server v2.0.3 and restart of the daemon failed with: #/etc/init.d/radiusd restart Stopping RADIUS server: [FAILED] Starting RADIUS server: Fri Jul 16 07:50:16 2010 : Info: Starting - reading configuration files ... [FAILED] In the radius.log, it shows: Error: There appears to be another RADIUS server running on the authentication port 1812 <--- The odd thing is that there is no radiusd process running on the Linux server at all: # ps aux | grep rad root 4869 0.0 0.0 4544 636 pts/1 S+ 12:11 0:00 grep rad #Debug messages: /usr/sbin/radiusd -X restart Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /etc/raddb/proxy.conf Config: including file: /etc/raddb/clients.conf Config: including file: /etc/raddb/snmp.conf Config: including file: /etc/raddb/sql.conf main: prefix = "/" main: localstatedir = "//var" main: logdir = "/var/log" main: libdir = "//lib" main: radacctdir = "/etc/radacct" main: hostname_lookups = no main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 1024 main: delete_blocked_requests = 0 main: port = 1812 main: allow_core_dumps = no main: log_stripped_names = yes main: log_file = "/var/log/radius.log" main: log_auth = yes main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = "//var/run/radiusd/radiusd.pid" main: bind_address = 10.25.210.21 IP address [10.25.210.21] main: user = "(null)" main: group = "(null)" main: usercollide = no main: lower_user = "no" main: lower_pass = "no" main: nospace_user = "no" main: nospace_pass = "no" main: checkrad = "//sbin/checkrad" main: proxy_requests = no proxy: retry_delay = 5 proxy: retry_count = 3 proxy: synchronous = no proxy: default_fallback = yes proxy: dead_time = 120 proxy: post_proxy_authorize = yes proxy: wake_all_if_all_dead = no security: max_attributes = 200 security: reject_delay = 1 security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms There appears to be another RADIUS server running on the authentication port 1812 <--- Does anybody know why it complains about "another RADIUS server running on the authentication port 1812" although there is no existing radiusd process at all? Thanks.
Yang Xue wrote:
Hi,
We're running freeradius server v2.0.3 and restart of the daemon failed with:
#/etc/init.d/radiusd restart Stopping RADIUS server: [FAILED] Starting RADIUS server: Fri Jul 16 07:50:16 2010 : Info: Starting - reading configuration files ... [FAILED]
If it didn't stop the server, it won't be able to start a new one.
In the radius.log, it shows:
Error: There appears to be another RADIUS server running on the authentication port 1812 <---
The odd thing is that there is no radiusd process running on the Linux server at all:
# ps aux | grep rad root 4869 0.0 0.0 4544 636 pts/1 S+ 12:11 0:00 grep rad
<shrug> It might have a different name. See also: $ netstat -an | grep 1812
Does anybody know why it complains about "another RADIUS server running on the authentication port 1812" although there is no existing radiusd process at all?
The server tries to use port 1812, and the OS says it can't, because there's another process using it. Find that process, and stop it. Alan DeKok.
Hi, Alan netstat -an | grep 1812 returns nothing, which means the port is not used by any process. netstat -an | grep 1812 [root@server1 etc]# On Fri, Jul 16, 2010 at 2:03 PM, Alan DeKok <aland@deployingradius.com> wrote:
Yang Xue wrote:
Hi,
We're running freeradius server v2.0.3 and restart of the daemon failed with:
#/etc/init.d/radiusd restart Stopping RADIUS server: [FAILED] Starting RADIUS server: Fri Jul 16 07:50:16 2010 : Info: Starting - reading configuration files ... [FAILED]
If it didn't stop the server, it won't be able to start a new one.
In the radius.log, it shows:
Error: There appears to be another RADIUS server running on the authentication port 1812 <---
The odd thing is that there is no radiusd process running on the Linux server at all:
# ps aux | grep rad root 4869 0.0 0.0 4544 636 pts/1 S+ 12:11 0:00 grep rad
<shrug> It might have a different name. See also:
$ netstat -an | grep 1812
Does anybody know why it complains about "another RADIUS server running on the authentication port 1812" although there is no existing radiusd process at all?
The server tries to use port 1812, and the OS says it can't, because there's another process using it.
Find that process, and stop it.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Greetings, I would like to be able to incorporate processing of ADSL-Agent-Circuit-Id into my freeradius / mysql environment. I have a stock debian / freeradius2 server with a local mysql database, and my bras is correctly getting this attribute to me and I see it under freeradius -X. I would like to implement a policy of 'ignore username/password' and instead authenticate based on the presence of this attribute and the database entry corresponding to it. I do not want to simply overwrite User-Name with the attribute, I really want to only peform this step if the attribute is actualy present otherwise proceed normally for chap/pap. So I guess the question is, how can I conditionally authenticate based on presence of this attribute (and a corresponding db entry saying "Auth-type = Accept" or "Reject")? Previous posters suggesting overwriting User-Name open up a hole where if anyone just makes their username the same as a valid circuit ID, they'd be allowed and really I want to enforce it based on the presence of the acutal attribute itself. Mike-
Ad this into the authorize section: authorize { if %{ADSL-Agent-Circuit-Id} { update request { User-Name := "%{ADSL-Agent-Circuit-Id}" Password := "%{ADSL-Agent-Circuit-Id}" } } Make sure that to add the User-Name (ADSL-Agent-Circuit-Id) to radcheck and set the password to the value of ADSL-Agent-Circuit-Id. +--------+-----------+--------------------+----+-----------+ | id | username | attribute | op | value | +--------+-----------+--------------------+----+-----------+ | 226529 | adslagent | Cleartext-Password | := | adslagent | +--------+-----------+--------------------+----+-----------+ 1 row in set (0.00 sec) Tim
-----Original Message----- From: freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org [mailto:freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org] On Behalf Of Mike Sent: Tuesday, July 20, 2010 12:37 PM To: FreeRadius users mailing list Subject: freeradius and ADSL-Agent-Circuit-Id
Greetings,
I would like to be able to incorporate processing of ADSL-Agent-Circuit-Id into my freeradius / mysql environment. I have a stock debian / freeradius2 server with a local mysql database, and my bras is correctly getting this attribute to me and I see it under freeradius -X. I would like to implement a policy of 'ignore username/password' and instead authenticate based on the presence of this attribute and the database entry corresponding to it. I do not want to simply overwrite User-Name with the attribute, I really want to only peform this step if the attribute is actualy present otherwise proceed normally for chap/pap. So I guess the question is, how can I conditionally authenticate based on presence of this attribute (and a corresponding db entry saying "Auth-type = Accept" or "Reject")? Previous posters suggesting overwriting User-Name open up a hole where if anyone just makes their username the same as a valid circuit ID, they'd be allowed and really I want to enforce it based on the presence of the acutal attribute itself.
Mike-
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Tim Sylvester wrote:
Ad this into the authorize section:
authorize {
if %{ADSL-Agent-Circuit-Id} { update request { User-Name := "%{ADSL-Agent-Circuit-Id}" Password := "%{ADSL-Agent-Circuit-Id}" } }
Make sure that to add the User-Name (ADSL-Agent-Circuit-Id) to radcheck and set the password to the value of ADSL-Agent-Circuit-Id.
+--------+-----------+--------------------+----+-----------+ | id | username | attribute | op | value | +--------+-----------+--------------------+----+-----------+ | 226529 | adslagent | Cleartext-Password | := | adslagent | +--------+-----------+--------------------+----+-----------+
This opens up a security hole I wish to avoid - if someone knows what my circuit Id's look like, and that database is used in any context where a user can send an id/password to authenticate that does NOT have ADSL-Agent-Cirtcuit-Id in it, then I've created a bunch of known user id's for the bad guys to use. I am happy having a non-default sql database schema but I think I really need the sql lookup to be being based on ADSL-Agent-Circuit-Id and not User-Name. Mike-
This opens up a security hole I wish to avoid - if someone knows what my circuit Id's look like, and that database is used in any context where a user can send an id/password to authenticate that does NOT have ADSL-Agent-Cirtcuit-Id in it, then I've created a bunch of known user id's for the bad guys to use. I am happy having a non-default sql database schema but I think I really need the sql lookup to be being based on ADSL-Agent-Circuit-Id and not User-Name.
OK. Read the docs on modifying the SQL schema and the SQL queries. Tim
This opens up a security hole I wish to avoid - if someone knows what my circuit Id's look like, and that database is used in any context where a user can send an id/password to authenticate that does NOT have ADSL-Agent-Cirtcuit-Id in it, then I've created a bunch of known user id's for the bad guys to use. I am happy having a non-default sql database schema but I think I really need the sql lookup to be being based on ADSL-Agent-Circuit-Id and not User-Name.
OK. You could try a few other things: Change the radcheck entry to:
+--------+-----------+-----------------------+----+-----------+ | id | username | attribute | op | value | +--------+-----------+-----------------------+----+-----------+ | 226529 | adslagent | ADSL-Agent-Circuit-Id | := | adslagent | +--------+-----------+-----------------------+----+-----------+
On 2010/07/20 10:50 PM, Mike wrote:
authorize {
if %{ADSL-Agent-Circuit-Id} { update request { User-Name := "%{ADSL-Agent-Circuit-Id}" Password := "%{ADSL-Agent-Circuit-Id}" } }
Make sure that to add the User-Name (ADSL-Agent-Circuit-Id) to radcheck and set the password to the value of ADSL-Agent-Circuit-Id.
+--------+-----------+--------------------+----+-----------+ | id | username | attribute | op | value | +--------+-----------+--------------------+----+-----------+ | 226529 | adslagent | Cleartext-Password | := | adslagent | +--------+-----------+--------------------+----+-----------+ This opens up a security hole I wish to avoid - if someone knows what my circuit Id's look like, and that database is used in any context where a user can send an id/password to authenticate that does NOT have ADSL-Agent-Cirtcuit-Id in it, then I've created a bunch of known user id's for the bad guys to use. I am happy having a non-default sql database schema but I think I really need the sql lookup to be being based on ADSL-Agent-Circuit-Id and not User-Name.
Mike-
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
How about this: I'm 100% sure my syntax is wrong today (I'm not an unlang master yet), but the idea should work. Opinions? authorize { if %{ADSL-Agent-Circuit-Id} { if (%{sql: select count(*) from CircuitIdList where CircuitId='%{ADSL-Agent-Circuit-Id}'} > 1) { Auth-Type = Accept } else { Auth-Type = Reject } } -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
Johan Meiring wrote:
I'm 100% sure my syntax is wrong today (I'm not an unlang master yet), but the idea should work.
Opinions?
Close. - You need to "update" a specific list. - you need double quotes around string values - the parser is *very* specific. Follow the examples in "man unlang" closely. authorize { ... if (ADSL-Agent-Circuit-Id && \ ("%{sql: select ...}")) { update control { Auth-Type := Accept } } else { reject } } Alan DeKok.
On 2010/07/21 11:00 AM, Alan DeKok wrote:
authorize { ... if (ADSL-Agent-Circuit-Id&& \ ("%{sql: select ...}")) { update control { Auth-Type := Accept }
} else { reject }
}
I disagree with the logic slightly. In my opinion it will also be rejected if ADSL-Agent-Circuit-Id does not exist. As fas as I understand, the desireable result is: If the ADSL-Agent-Circuit-Id does *not* exist, normal authentication must happen. If it *does* exist, accept or reject, depending on its value. Would this not work better? authorize { ... if (ADSL-Agent-Circuit-Id) { if ("%{sql: select ...}") { update control { Auth-Type := Accept } } else { reject } } } -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
Johan Meiring wrote:
I disagree with the logic slightly. In my opinion it will also be rejected if ADSL-Agent-Circuit-Id does not exist.
Yes. It all depends on what you want.
As fas as I understand, the desireable result is: If the ADSL-Agent-Circuit-Id does *not* exist, normal authentication must happen. If it *does* exist, accept or reject, depending on its value.
Would this not work better?
authorize { ... if (ADSL-Agent-Circuit-Id) { if ("%{sql: select ...}") { update control { Auth-Type := Accept } } else { reject } } }
Yes, that will do what you want. Alan DeKok.
Johan Meiring wrote:
On 2010/07/21 11:00 AM, Alan DeKok wrote:
authorize { ... if (ADSL-Agent-Circuit-Id&& \ ("%{sql: select ...}")) { update control { Auth-Type := Accept }
} else { reject }
}
I disagree with the logic slightly. In my opinion it will also be rejected if ADSL-Agent-Circuit-Id does not exist.
As fas as I understand, the desireable result is: If the ADSL-Agent-Circuit-Id does *not* exist, normal authentication must happen. If it *does* exist, accept or reject, depending on its value.
Would this not work better?
authorize { ... if (ADSL-Agent-Circuit-Id) { if ("%{sql: select ...}") { update control { Auth-Type := Accept } } else { reject } } }
I have been attempting to implement this advice. I can use a 'select count(*)' sql query and based on wether the value is 1, I can then set Auth-Type := Accept just like it's written above. But, there's additional processing that is desireable that I just can't figure out how to do here. Instead of just blindly setting Accept, I might want to proceed with having the sql module do group processing and so forth to finally accumulate all of the reply attributes that apply to this request. Maybe that reply is 'Auth-Type := Reject" but then others contain 'Accept' along with framed-ip-address and so forth. This would involve using a modified sql query in the event that ADSL-Agent-Circuit-Id is present, and there doesn't appear to be any way at run time to make that selection. I am getting the impression that perhaps I need to run maybe a second server that has it's sql configured with queries tailored for the presence of this attribute, and then proxy requests from the primary server to this one in this case. I could probably run it on lookback on another port so that the radius clients don't have to know anything about it. Still it's a bit of work but that seems to be the only way possible to make sql query one database if the attribute is present, and query another if it's not (or, use different queries). Would love more insight if anyone cares to share. Thank you.
Try the following: Add this to the top of the Authorize section: authorize { if ADSL-Agent-Circuit-Id { update request { User-Name := "%{ADSL-Agent-Circuit-Id}" User-Password := "%{ADSL-Agent-Circuit-Id}" } } Then, add the Circuit-IDs to radcheck: mysql> select * from radcheck where username = "circuit-123"; +--------+-------------+-----------------------+----+-------------+ | id | username | attribute | op | value | +--------+-------------+-----------------------+----+-------------+ | 226536 | circuit-123 | ADSL-Agent-Circuit-Id | == | circuit-123 | | 226537 | circuit-123 | Cleartext-Password | := | circuit-123 | +--------+-------------+-----------------------+----+-------------+ 2 rows in set (0.00 sec) Then run a test to make sure that when using the Circuit-Id to authenticate the device, the ADSL-Agent-Circuit-Id must be in the request. [root@sparky performance]# cat circuit-id.rad User-Name = "test" User-Password = "FreeRADIUS" User-Name = "circuit-123" User-Password = "circuit-123" User-Name = "" ADSL-Agent-Circuit-Id ="circuit-123" User-Name = "void" ADSL-Agent-Circuit-Id ="circuit-123" [root@sparky performance]# [root@sparky performance]# radclient -f circuit-id.rad localhost auth FreeRADIUS Received response ID 81, code 2, length = 20 Received response ID 165, code 3, length = 20 Received response ID 157, code 2, length = 20 Received response ID 119, code 2, length = 20 [root@sparky performance]# Tim
-----Original Message----- From: freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org [mailto:freeradius-users- bounces+tim.sylvester=networkradius.com@lists.freeradius.org] On Behalf Of Mike Sent: Wednesday, July 28, 2010 3:37 PM To: FreeRadius users mailing list Subject: Re: freeradius and ADSL-Agent-Circuit-Id
Johan Meiring wrote:
On 2010/07/21 11:00 AM, Alan DeKok wrote:
authorize { ... if (ADSL-Agent-Circuit-Id&& \ ("%{sql: select ...}")) { update control { Auth-Type := Accept }
} else { reject }
}
I disagree with the logic slightly. In my opinion it will also be rejected if ADSL-Agent-Circuit-Id does not exist.
As fas as I understand, the desireable result is: If the ADSL-Agent-Circuit-Id does *not* exist, normal authentication must happen. If it *does* exist, accept or reject, depending on its value.
Would this not work better?
authorize { ... if (ADSL-Agent-Circuit-Id) { if ("%{sql: select ...}") { update control { Auth-Type := Accept } } else { reject } } }
I have been attempting to implement this advice. I can use a 'select count(*)' sql query and based on wether the value is 1, I can then set Auth-Type := Accept just like it's written above. But, there's additional processing that is desireable that I just can't figure out how to do here. Instead of just blindly setting Accept, I might want to proceed with having the sql module do group processing and so forth to finally accumulate all of the reply attributes that apply to this request. Maybe that reply is 'Auth-Type := Reject" but then others contain 'Accept' along with framed-ip-address and so forth. This would involve using a modified sql query in the event that ADSL-Agent-Circuit-Id is present, and there doesn't appear to be any way at run time to make that selection.
I am getting the impression that perhaps I need to run maybe a second server that has it's sql configured with queries tailored for the presence of this attribute, and then proxy requests from the primary server to this one in this case. I could probably run it on lookback on another port so that the radius clients don't have to know anything about it. Still it's a bit of work but that seems to be the only way possible to make sql query one database if the attribute is present, and query another if it's not (or, use different queries).
Would love more insight if anyone cares to share.
Thank you.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Tim Sylvester wrote:
Try the following:
Add this to the top of the Authorize section:
if ADSL-Agent-Circuit-Id { update request { User-Name := "%{ADSL-Agent-Circuit-Id}" User-Password := "%{ADSL-Agent-Circuit-Id}" } }
Thank you for taking the time to provide this detailed example. I should have included the previous thread where this was suggested and that it 'works', but also that it creates a security hole in that an end user could simply set their user name and password to be the same as a Circuit-Id, thereby taking advantage of a 'known passwords' if anyone knows what my circuit id's look like. The task is to set things up so that _only_ in the event that the request contains an actual ADSL-Agent-Circuit-Id attribute, that I don't bother trying to do chap/pap, but instead I pull everything (Including Access-Accept) from the database indexed by ADSL-Agent-Circuit-Id. If there is no such attribute, then just proceed as normal. I can use sql to get a truth value wether the circuit-id is present in a non-default table, and I can use unlang to update the control with "Auth-Type := Accept". This works and results in 'access accept' to the client. But, it does not get me anyway to pull attributes specific to this id and return them to the client. What I was talking about was perhaps using the presence of ADSL-Agent-Circuit-Id to decide whether to proxy the request to another virtual server. I could configure this virtual server to listen on loopback so the only way to consult it is thru the proxy, and I could configure the sql query used on THIS server to peform the authorization query. This seperation would give me the abillity to either engage chap/pap or not based on presence of the attribute, instead of simply overwriting the attribute values which doesn't address my security concerns. I'm still looking for a good method to accomplish this. Mike-
Tim Sylvester wrote:
Try the following:
Add this to the top of the Authorize section:
if ADSL-Agent-Circuit-Id { update request { User-Name := "%{ADSL-Agent-Circuit-Id}" User-Password := "%{ADSL-Agent-Circuit-Id}" } }
Thank you for taking the time to provide this detailed example. I should have included the previous thread where this was suggested and that it 'works', but also that it creates a security hole in that an end user could simply set their user name and password to be the same as a Circuit-Id, thereby taking advantage of a 'known passwords' if anyone knows what my circuit id's look like.
No. You should have read my message in more detail. If you look at the example below, you will see that if someone tries to use a Username/Password with the Circuit-Id, the authentication will fail. The second entry for in the radcheck table requires that both the username/password and the username/ADSL-Agent-Circuit-Id are required.
The task is to set things up so that _only_ in the event that the request contains an actual ADSL-Agent-Circuit-Id attribute, that I don't bother trying to do chap/pap, but instead I pull everything
(Including
Access-Accept) from the database indexed by ADSL-Agent-Circuit-Id. If there is no such attribute, then just proceed as normal. I can use sql to get a truth value wether the circuit-id is present in a non-default table, and I can use unlang to update the control with "Auth-Type := Accept". This works and results in 'access accept' to the client. But, it does not get me anyway to pull attributes specific to this id and return them to the client.
My configuration will allow you to do what you want. Try it before dismissing it.
What I was talking about was perhaps using the presence of ADSL-Agent-Circuit-Id to decide whether to proxy the request to another virtual server. I could configure this virtual server to listen on loopback so the only way to consult it is thru the proxy, and I could configure the sql query used on THIS server to peform the authorization query. This seperation would give me the abillity to either engage chap/pap or not based on presence of the attribute, instead of simply overwriting the attribute values which doesn't address my security concerns. I'm still looking for a good method to accomplish this.
You are welcome to try your much more complicated method. Or you could re-read my message and perform some actual tests before responding in e-mail. Tim
participants (5)
-
Alan DeKok -
Johan Meiring -
Mike -
Tim Sylvester -
Yang Xue