- Freeradius-Devel - lists.freeradius.org

Enable dhcp
by Stephen R. van den Berg 23 Aug '11

23 Aug '11

--- debian/rules | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/debian/rules b/debian/rules index 8c25de4..49614ff 100755 --- a/debian/rules +++ b/debian/rules @@ -81,6 +81,7 @@ endif --enable-ltdl-install=no --enable-strict-dependencies \ --with-large-files --with-udpfromto --with-edir \ --enable-developer \ + --with-dhcp \ --config-cache \ --without-rlm_eap_tnc \ --with-rlm_sql_postgresql_lib_dir=`pg_config --libdir` \ -- 1.7.5.4

1 0

Debianised?
by Stephen R. van den Berg 23 Aug '11

23 Aug '11

--- Make.inc.in | 2 +- raddb/radiusd.conf.in | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Make.inc.in b/Make.inc.in index dce571e..bf9f99f 100644 --- a/Make.inc.in +++ b/Make.inc.in @@ -50,7 +50,7 @@ LDFLAGS = @LDFLAGS@ LOGDIR = ${logdir} RADDBDIR = ${raddbdir} -RUNDIR = ${localstatedir}/run/radiusd +RUNDIR = ${localstatedir}/run/freeradius SBINDIR = ${sbindir} RADIR = ${radacctdir} LIBRADIUS = $(top_builddir)/src/lib/$(LIBPREFIX)freeradius-radius.la diff --git a/raddb/radiusd.conf.in b/raddb/radiusd.conf.in index d7cdc72..ebb35a6 100644 --- a/raddb/radiusd.conf.in +++ b/raddb/radiusd.conf.in @@ -62,7 +62,7 @@ radacctdir = @radacctdir@ # # name of the running server. See also the "-n" command-line option. -name = radiusd +name = freeradius # Location of config and logfiles. confdir = ${raddbdir} @@ -465,8 +465,8 @@ security { # member. This can allow for some finer-grained access # controls. # -# user = radius -# group = radius + user = freerad + group = freerad # Core dumps are a bad thing. This should only be set to # 'yes' if you're debugging a problem with the server. -- 1.7.5.4

1 0

accounting and Autorization script with mysql
by dragoalato1988 22 Aug '11

22 Aug '11

Hello, sorry for my English. I write from italy. I ask for help, and advice to solve my problem. I need to implement a script freeradius rlm_sql or modification that allows me to access or deny users. access must be managed by reading the tables in the database: profile, user. in practice the user table has the following fields. ID - USERNAME - PASSWORD - NAME - PROFILE - EXPIRED - 1 - pinco.pallino - pallino - marco - admin - 29-12-2011 profile in the table but there are characteristics of the profile and other data to be sent to the NAS as a fixed IP address ID - ProfileName - DATADOWNLOAD - DATAUPLOAD 1 - admin - 2353535 - 2662625 from these tables, I would like freeradius user reads and see if the user is. if there is control the password. if it reads the exact profile and profile is in the table to read its features. I thought I'd make a change to rlm_sql, and I'm starting to study there perl. I ask you to help or advice on the best choice. thanks to all the aid you give me. -- View this message in context: http://freeradius.1045715.n5.nabble.com/accounting-and-Autorization-script-… Sent from the FreeRadius - Dev mailing list archive at Nabble.com.

1 0

[PATCH] policy.conf rewrite.called_station_id fix
by Alexander Clouter 19 Aug '11

19 Aug '11

For 802.11 sessions Called-Station-Id is typically '00-11-22-33-44-55:foobar'. However, after calling rewrite.called_station_id it is re-written to '00-11-22-33-44-55::foobar' as the regex grouping captures the ':' too. The patch below prevents the addition of this extra. Signed-off-by: Alexander Clouter <alex(a)digriz.org.uk> diff --git a/raddb/policy.conf b/raddb/policy.conf index 73b1951..ece72b1 100644 --- a/raddb/policy.conf +++ b/raddb/policy.conf @@ -171,7 +171,7 @@ policy { # SSID component? if ("%{7}") { update request { - Called-Station-Id := "%{Called-Station-Id}:%{7}" + Called-Station-Id := "%{Called-Station-Id}%{7}" } } updated

2 1

Should MAX_STRING_LEN be 253?
by Makarand Pradhan 19 Aug '11

19 Aug '11

Greetings everyone. This email concerns the constant "MAX_STRING_LEN". Problem description: libradius.h #define MAX_STRING_LEN 254 /* RFC2138: string 0-253 octets */ I have been working on a EAP radius authentication issue where the Radius server is a Windows 2008 NPS. Authentication fails due to malformed packets. The freeradius package is being used to encode the message to be sent to the server. RFC2138 says: A summary of the Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The format of the value field is one of four data types. string 0-253 octets Based on the RFC the constant is correctly defined to be 254 bytes. All the same, if 2 bytes of the 255 bytes are reserved for type and length, I am left with 253 bytes to store my data. As the constant MAX_STRING_LEN is being used in our code to split a big EAP message into multiple segments, we tend to loose one byte in every segment causing authentication failure (malformed packet received). Question: Based on the above analysis it was felt that the constant should be 253. Should the constant be changed to 253 or is there any other reason for keeping it at 254? Have a nice day everyone. Cheers, Makarand. -- ___________________________________________________________________________ NOTICE OF CONFIDENTIALITY: This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail and delete this e-mail and any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. _____________________________________________________________________

3 4

Pair matching when attribute not present
by Brian Candler 19 Aug '11

19 Aug '11

There was a discussion previously about merging the different versions of paircompare logic, and I'd just like to mention a related issue. I was expecting that the following rlm_sql authorize_check_query response would work if the attribute was not present: 'Calling-Station-Id', '=~', '^$|^0845' However it doesn't. It looks like there are two sets of logic which might be used: src/lib/valuepair.c: paircmp() expands the argument using vp_prints_value. If it's missing then it expands to empty string. In that case, I think the match would succeed. src/main/valuepair.c: paircompare() fails immediately if the argument is non-existent, except when using the !* operator (T_OP_CMP_FALSE). I haven't yet worked out exactly in which circumstances paircmp() is used and in which circumstances paircompare() is used :-( Another usage case: 'Reply-Message', '!=', 'SPECIALOPTION' (i.e. I would like this to match if either Reply-Message is not present, or if its value is not SPECIALOPTION) It's a matter of discussion as to which is the desired behaviour, and is maybe something that could be considered for freeradius 3.x Regards, Brian.

2 3

some patches for branch v2.1.x
by Oliver Schröder 18 Aug '11

18 Aug '11

While migrating the configuration of our commercial radius to freeradius I needed to customise (parts of) the freeradius sources to our needs. Perhaps those patches are useful for others, so I want to contribute them and ask if you are willing to accept them: rlm_linelog: The original module does not create parent directories when needed. The patch fixes this behavior, so you can define filenames for logging like: filename = ${logdir}/whatever/%Y/%m/detail.%d This patch is trivial and has no effects to in-use installations. rlm_ldap: Our LDAP scheme provides 4 data fields, two for check-items and two for reply-items (RadiusReplyattrDSL/RadiusCheckattrDSL and RadiusReplyattr/RadiusCheckattr). Those fields contain attributes/value pairs in one row, eg: RadiusReplyattrDSL: Framed-IP-Address = 1.2.3.4, Session-Timeout = 86400, Uni-Egress-Policy-Name="pol6144",Uni-Ingress-Policy-Name="pol512" Which pair is used depends on values found in the request, i.e. if the request was sent by a BRAS then RadiusReplyattrDSL/RadiusCheckattrDSL are used, if sent by a (ISDN-) NAS then RadiusReplyattr/RadiusCheckattr are used. So I needed a way to extract those one-liners to a list of attribute/value pairs. To avoid rlm_perl I patched rlm_ldap, so you can configure the rows to use via configuration, especially in the hints file. While working on this module I also found it useful to be able to set the basedn via hints. So you can additionally provide the basedn: DEFAULT NAS-IP-Address =~ "(1.2.3.4|4.3.2.1)" LDap-basedn := "ou=Service-11200,ou=people,dc=company,dc=com", LDap-Multimap-reply := "RadiusReplyattrDSL", LDap-Multimap-check := "RadiusCheckattrDSL" rlm_ldap will then look for values in these fields and attach them to the reply set. rlm_translate: Additionally I found it useful to have the functionality of the unix 'tr' command in freeradius so I wrote rlm_translate. This module implements the full tr functionality as a freeradius module. The module configuration looks like: translate username_tolower { attribute = "User-Name" searchin = packet set1 = "A-Z" set2 = "a-z" complement = no translate = yes squeeze = no delete = no } I know those changes are not vital but I believe useful. If you like them I will provide (git-) .diff files. Currently I'm going with v2.1.x but can provide diffs for 3.x, too. What do you think? Regards, Oliver

3 5

LDAP timeouts during failure conditions
by Phil Mayers 15 Aug '11

15 Aug '11

So, some discussion on the JANET-ROAMING list leads me to believe that, during an "ldap server down" condition, rlm_ldap will incur "net_timeout" on every (or many) passes through the module. I don't really understand the MAX_FAILED_* logic at the start of perform_search, but it seems to conflict with the comments at the top of the file: * If conn->failed_conns > MAX_FAILED_CONNS_START then we don't * try to do anything and we just do conn->failed_conns++ and * return RLM_MODULE_FAIL ...perform_search has no such logic; in any event, it seems like it would be better to do an optional time-based per-server "fast fail" so that: redundant { ldap1 ldap2 } ...fails quickly if ldap1 is down. In some ways it's a shame we can't use a worker thread to manage the LDAP connection(s); that way, the module could be marked "fast fail" unless and until a live connection exists. Is there any scope for that? Cheers, Phil

5 19

Re: segmentation fault freeradius 2.1.7 using rlm_sql
by John Dennis 12 Aug '11

12 Aug '11

>> Upgraded freeradius to 2.1.11 (built from source) > Don't use 2.1.11 it segfaults, checkout the head of the 2.1.X branch in git > Notice how I DIDN'T suggest upgrading to 2.1.11, but to v2.1.x of git > branch? There's a reason for that, and you just found out the hard > way. "Houston, we have a problem" ;-) This is not the first time a FreeRADIUS release was not ready for production when it was released. Those of us who package upstream projects for distribution worry a lot about stability and robustness. I've said this before so forgive me, but I'm going to reiterate it again. Please don't get mad at the messenger, I have only the best intentions with these observations. FreeRADIUS has some problems which other projects have avoided. * FreeRADIUS has no notion of a "stable release". Many projects maintain both a stable production version and a current version (which is not the same as the "tip", rather it's tagged in source code control, tested and released just like any other release, it's just got a few more features than the rock solid stable release). The rock solid stable release has been field proven, should have the absolute confidence of system administrators and be viable for multiple years (in other words you can install it and be confident once it's put in production you're good to go for several years. Occasionally a stable release needs a bug or security fix. When that occurs the stable release is surgically modified to fix exactly that one issue, it's minor version number is bumped. System administrators are never told to upgrade to a significant new version because of the bug/security issue, instead they reinstall a patched version of "stable". * FreeRADIUS has way too much churn for a critical system service. Think about other system services, how often do you see kerberos, bind, iptables, pam, MySQL, etc. going through significant revisions? Are the administrators of those services constantly being told to upgrade the service because of the bug/feature du jour? * The QE component of FreeRADIUS has proven to be inadequate. I know Alan runs a set of tests and he calls for testing prior to a new release. But we've seen the amount of testing which actually occurs is inadequate because releases have gone out with significant problems and those releases have gotten pushed into production. I think part of the problem is the frequent release schedule (measured in months) and the lack of a coordinated beta testing program. Releases should not occur until after they've successfully navigated a beta program. I humbly would suggest the following: * Create and maintain a "stable" version. * Organize a rigorous beta test program. * Slow down the release schedule, avoid the temptation to cut a new release because of minor new features. If production servers can't run successfully without a feature that's an indication the prior release was too hasty. Critical bug fixes should occur in the release branch and the release branch re-released. The release interval for a system service like FreeRADIUS should be measured in years, not months or weeks. Comments? Thoughts? Do you agree/disagree? John -- John Dennis <jdennis(a)redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/

5 5

NAS-Identifier instead of IP
by Gunther 27 Jul '11

27 Jul '11

I have seen several requests in this mailing list regarding the use of the NAS-Identifier for the past 8 or so years. But somehow, there seems to be still no solution on the horizon. The addition of the dynamic client feature provided great relief compared to the static client/nas list which is only loaded during the radiusd startup or SIGHUP. Anyhow, I still have the problem that clients using ISPs with shared IP addresses (e.g. some satellite providers etc) have to use exactly the same shared secret for all routers (nas) despite they might be different customers. In addition, we have clients with the nas installed on vessels and they roam between different satellite links and IP addresses. At times vessels from different companies are using the same IP address at the same time. In my test setup I am now using dynamic clients with sql and rlm_raw on FR 2.1.11. I am extracting the NAS-Identifier within 'dynamic-clients': if ("%{sql: SELECT nas_identifier FROM phs_nas WHERE nas_identifier = '%{raw:NAS-Identifier}'}") { This works fine as only a nas with the correct NAS-Identifier will be allowed. After the first Access-Request the IP address of the NAS is added to the (memory resident) client/nas list. In my sql nas table I like to use the NAS-Identifier instead of the IP address (at least that is my intention). The standard scenario is working fine using the NAS-Identifier: rad_recv: Access-Request packet from host 192.168.25.215 port 49481, id=39, length=222 Wed Jul 27 04:25:18 2011 : Debug: server dynamic_client_server { Wed Jul 27 04:25:18 2011 : Debug: rlm_raw: (raw_xlat) Wed Jul 27 04:25:18 2011 : Debug: rlm_raw: NAS-Identifier = myTestID123 Wed Jul 27 04:25:18 2011 : Debug: rlm_sql_mysql: query: SELECT nasname FROM phs_nas WHERE nasname = 'myTestID123' ... Wed Jul 27 04:25:18 2011 : Debug: } # server dynamic_client_server Wed Jul 27 04:25:18 2011 : Debug: - Added client 192.168.25.215 with shared secret HereIsMySharedSecret1 rad_recv: Access-Request packet from host 192.168.25.215 port 49481, id=39, length=222 User-Name = " myuser" NAS-Identifier = "myTestID123" ... Wed Jul 27 04:25:19 2011 : Info: ++[exec] returns noop Sending Access-Accept of id 39 to 192.168.25.215 port 49481 Here comes the problem! Now radiusd receives a request from a different client/NAS, but with the same IP address: Since the IP is already in the memory resident client/nas list, there is no need to search the database again. The different NAS-Identifier and different shared secret is ignored and the Access-Request is accepted. rad_recv: Access-Request packet from host 192.168.25.215 port 53237, id=42, length=222 User-Name = "thisUser " NAS-Identifier = "myTestID456" ... Sending Access-Accept of id 42 to 192.168.25.215 port 53237 While the request (id=42) is getting through, the reply is using a different shared secret, the one found in the first access-request (id=39) and the reply will therefore not be accepted by the nas and the NAS log shows: RADIUS server is not responding My conclusion: I like to use the e.g. NAS-Identifier for a unique identification of a client/nas instead of the IP. I do not want to change anything on the client side (e.g. vpn etc.). All client/nas have to use unique NAS-Identifiers and Shared Secrets which is easy to achieve during setup. Any hints using FreeRadius with the NAS-Identifier in this context are appreciated! Or if FreeRadius cannot support this, are there other Radius server which could do this job? Is there by chance anywhere Freeradius developer documentation available or is the 'documented' source code the documentation? Thank you!

3 4