- Freeradius-Users - lists.freeradius.org

Freeradius iodbc mssql
by Andrea Berardi 04 Aug '06

04 Aug '06

Hi all, I'm trying to use freeradius (on a Debian Sarge system) for accounting, and I have to write data to a mssql DB. As you can see from the output reported below, generate by execution of freeradius in debug mode (`freeradius -X`), I have problems with iodbc: It can't connect correctly to my SQL server. [...] Module: Loaded SQL sql: driver = "rlm_sql_iodbc" sql: server = "XXXdsn" [...] rlm_sql (sql): Driver rlm_sql_iodbc (module rlm_sql_iodbc) loaded and linked rlm_sql (sql): Attempting to connect to usrXXX@XXXdsn:/XXXDB rlm_sql (sql): starting 0 rlm_sql (sql): Attempting to connect rlm_sql_iodbc #0 sql_create_socket: SQLConnectfailed: [iODBC][Driver Manager]Data source name not found and no default driver specified. Driver could not be loaded rlm_sql (sql): Failed to connect DB handle #0 rlm_sql (sql): starting 1 rlm_sql (sql): starting 2 rlm_sql (sql): starting 3 rlm_sql (sql): starting 4 rlm_sql (sql): Failed to connect to any SQL server. Module: Instantiated sql (sql) [...] I think that the problem could be in /etc/odbc.ini and /etc/odbcinst.ini, with the DSN definition. I also tryed the unixodbc package and I can connect correctly to my SQL server with the isql cmd-line tool, but I can't use unixodbc with freeradius because It can't load the rlm_sql_unixodbc driver(it's not included in the debian package) Any suggestions? Sorry for the long post and thank you all. -- | .' ' `. Andrea Berardi aka Syneus | : :' : Debian User | `. `'` | `- Linux Registered User #395193 | Debian GNU/Linux http://counter.li.org/ | http://www.debian.org

1 0

Q:ABOUT:return an attribute in bcd format
by Alejandro Sanchez 03 Aug '06

03 Aug '06

Hello. I need return an attribute in bcd format (binary code decimal) anybody knows is freeradius has a mechanism to do this? Thank's ___________________________________________________________ Do You Yahoo!? La mejor conexión a Internet y <b >2GB</b> extra a tu correo por $100 al mes. http://net.yahoo.com.mx

2 2

Prepaid Bandwidth disconnections
by Michael da Silva Pereira 03 Aug '06

03 Aug '06

Hi, I am currently trying to setup a bandwidth prepaid realm, Whereby clients buy 1G, 2G, 10Gigs, or watever. Then I need my radius server to disconnect these people as soon as this number is hit, is there anyway to do this. I am running a cisco PDSN as my NAS, I've already looked at session-timeouts, but my clients would be annoyed being disconnected all the time. Thanks, Michael da silva pereira

2 1

URL authentication
by Joe Warren-Meeks 03 Aug '06

03 Aug '06

Hey guys, (Using freeradius-1.1.2 on Ubuntu Linux, with MySQL backend) I'm setting up an HTTP based download service and we are looking to authenticate users to download a specific object only. So, I'm looking for a way to authenticate based on username, password and url. Now, I can extend the radcheck table to include the URL and add that into the sql query as defined in mysql.conf, but how do I get freeradius to authenticate on the triple? Any ideas? My search in the mailing list for URL and authenticate strangely turned up a lot of results ;-) Thanks. -- joe. Joe Warren-Meeks T: +44 (0) 208 962 0007 Aggregator Ltd. M: +44 (0) 7789 176 078 Unit 62/63 Pall Mall Deposit F: +44 (0) 208 962 0008 124-128 Barlby Road, London W10 6BL PGP: 361F 78D0 56F5 8D7F 2639 947D 71E2 8811 F825 64CC

5 7

limiting user access
by simon＠434canada.com 02 Aug '06

02 Aug '06

>> Ok, I think I am getting closer. I have defined a new passwd module >>like so: >> >> passwd nas_group { >> filename = ${raddbdir}/nas_group >> format = "*NAS-IP-Address:,User-Name" >> } > Thet creates a username by NAS IP address, I think... you don't want >to do that. > > See the "man" page for rlm_passwd. It says to create a group >attribute for a reason. > > Alan DeKok. OK, yes, I realize that was creating a user name. So if I change that format line to have a Group attribute instead of User-Name, then I have a Group being created by NAS-IP-Address. I still don't get how I can test to make sure that the user is part of this group. I have tried adding the group name to the usergroup table, but whether or not this value is correct (corresponds to the value in the nas_group file) or is even present doesn't make a difference. The user is always getting authenticated. Where does the logic need to lie to check that the user is a part of the named group? Simon

2 1

limiting user access
by simon＠434canada.com 02 Aug '06

02 Aug '06

Hi, Ok, I think I am getting closer. I have defined a new passwd module like so: passwd nas_group { filename = ${raddbdir}/nas_group format = "*NAS-IP-Address:,User-Name" } I have also added a call to nas_group in the authorize section, directly after preprocess: nas_group { notfound = reject } In my nas_group file, i have the following: 255.255.255.255:test_user When I test this out with radtest, I get success no matter what, with whatever user(s) are listed behind the NAS-IP-Address being "added to config_items". What I want though, is to make sure that the user name coming in is listed in the nas_group file after the NAS-IP-Address entry. If it is there, then the password should just be checked against the username, but if the user name is not associated with this NAS-IP-Address, then the attempt should be rejected. So how do I get the rlm_passwd module to check the list of user names against the user name in the incoming request? Thanks, Simon

2 1

EAP-TTLS MD5 hashed Passwords in MySQL Database for WPA-802.1x auth
by Christian Poessinger 02 Aug '06

02 Aug '06

Hello, I'm trying to setup a System to authenticate WLAN users via EAP-TTLS with md5 crypted passwords, stored in a sql database. I'm using MySQL as the Backend and it works great when the passwords are stored in cleartext or UNIX crypt. When i convert the password from crypt to md5 and change pap encryption_scheme to md5 it doen't work anymore. As I have to use the SQL attribute field with 'Crypt-Password' in it, it seems that it wants to use crypt passwords and not md5. I tried to change it to 'md5-password' but well ... that wasn't the answer. Here is the error: --------- modcall: entering group PAP for request 4 rlm_pap: login attempt by "foo" with password bar rlm_pap: Crypt-Password attribute but encryption scheme is not set to CRYPT modcall[authenticate]: module "pap" returns fail for request 4 modcall: leaving group PAP (returns fail) for request 4 auth: Failed to validate the user. TTLS: Got tunneled reply RADIUS code 3 TTLS: Got tunneled Access-Reject --------- Anyone has an Idea how to use the MD5 hashed Passwords in the Database with EAP-TTLS for authentication? I appended my radius configuration. Thanks. ----------- CONFIG ------------ eap { default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no leap { } tls { private_key_file = /etc/ssl/rad.pem certificate_file = /etc/ssl/rad.pem CA_file = /etc/ssl/ca.pem dh_file = /etc/ssl/rad.dh random_file = /dev/urandom fragment_size = 1024 include_length = yes check_crl = yes } ttls { default_eap_type = md5 copy_request_to_tunnel = no use_tunneled_reply = no } peap { default_eap_type = mschapv2 } mschapv2 { } } modules { pap { encryption_scheme = md5 } } authorize { preprocess suffix eap files sql } authenticate { Auth-Type PAP { pap } eap } users-file DEFAULT Auth-Type = PAP Fall-Through = 0 -------- END OF CONFIG -------------

3 10

Cisco's split tunneling policy attribute not returned?
by Geoff Silver 02 Aug '06

02 Aug '06

Running FreeRadius 1.1.0, and I'm wondering if I'm doing something wrong here. We have some users who have a split tunneling policy configured on their account for various historical reasons. The entries look like so: myuser Huntgroup-Name=="Office", Hint==Port-1812, Auth-Type:=Accept CVPN3000-IPSEC-Split-Tunneling-Policy = 1, CVPN3000-IPSEC-Split-Tunnel-List = "SPCCOLO_ST", Class = "OU=AOL-TW", Filter-Id = "SPCCOLO_O" Unfortunately, the split tunneling attributes aren't being returned by radiusd to the client (neither the NAS nor radclient). In testing with radclient, I get: # echo 'User-Name = "myuser", User-Password = "", NAS-IP-Address = 127.0.0.1, NAS-Port = 1' | /opt/bin/radclient -d /opt/share/dictionary/ -x 127.0.0.1:1812 auth foobar Sending Access-Request of id 63 to 127.0.0.1 port 1812 User-Name = "myuser" User-Password = "" NAS-IP-Address = 127.0.0.1 NAS-Port = 1 rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=63, length=42 Class = 0x4f553d414f4c2d5457 Filter-Id = "SPCCOLO_O" Our prior GNU radius setup (which I hate) did this just fine, returning: Sending Access-Request of id 224 to 172.18.165.36 port 1645 User-Name = "myuser" User-Password = "" NAS-IP-Address = 172.18.209.18 NAS-Port = 1 rad_recv: Access-Accept packet from host 172.18.165.36:1645, id=224, length=72 Class = 0x4f553d414f4c2d5457 Filter-Id = "SPCCOLO_O" Vendor-3076-Attr-55 = 0x00000001 Vendor-3076-Attr-27 = 0x535043434f4c4f5f5354 Is there something special I need to do to ensure that the Split-Tunneling attributes are returned upon successful authentication? Running radiusd in debug mode doesn't reveal anything obvious to me: # /opt/reverb/sbin/radiusd -AX Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /opt/reverb/etc/clients.conf Config: including file: /opt/reverb/etc/proxy.conf main: prefix = "/opt/reverb" main: localstatedir = "/var" main: logdir = "/var/log/radius" main: libdir = "/opt/reverb/lib" main: radacctdir = "/var/log/radius" 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 = no main: log_file = "/var/log/radius/radius.log" main: log_auth = yes main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = "/var/run/radiusd/radiusd.pid" main: user = "reverb" main: group = "reverb" main: usercollide = no main: lower_user = "yes" main: lower_pass = "no" main: nospace_user = "before" main: nospace_pass = "no" main: checkrad = "/opt/reverb/sbin/checkrad" main: proxy_requests = yes proxy: retry_delay = 5 proxy: retry_count = 1 proxy: synchronous = no proxy: default_fallback = yes proxy: dead_time = 300 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 listen: port = 1645 listen: type = "auth" listen: port = 1646 listen: type = "acct" listen: port = 1812 listen: type = "auth" listen: port = 1813 listen: type = "acct" radiusd: entering modules setup Module: Library search path is /opt/reverb/lib Module: Loaded exec exec: wait = yes exec: program = "(null)" exec: input_pairs = "request" exec: output_pairs = "none" exec: packet_type = "(null)" Module: Instantiated exec (exec) Module: Loaded expr Module: Instantiated expr (expr) Module: Loaded preprocess preprocess: huntgroups = "/opt/reverb/etc/huntgroups" preprocess: hints = "/opt/reverb/etc/hints" preprocess: with_ascend_hack = no preprocess: ascend_channels_per_line = 23 preprocess: with_ntdomain_hack = no preprocess: with_specialix_jetstream_hack = no preprocess: with_cisco_vsa_hack = yes Module: Instantiated preprocess (preprocess) Module: Loaded syslog syslog: hidepasswd = "yes" syslog: logextra = "(null)" syslog: logfacility = "local3" syslog: loglevel = "info" syslog: logname = "radiusd-auth" Module: Instantiated syslog (auth_log) Module: Loaded files files: usersfile = "/opt/reverb/etc/users" files: acctusersfile = "/opt/reverb/etc/acct_users" files: preproxy_usersfile = "/opt/reverb/etc/preproxy_users" files: compat = "no" Module: Instantiated files (files) Module: Loaded Acct-Unique-Session-Id acct_unique: key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port" Module: Instantiated acct_unique (acct_unique) syslog: hidepasswd = "yes" syslog: logextra = "(null)" syslog: logfacility = "local3" syslog: loglevel = "info" syslog: logname = "radiusd-acct" Module: Instantiated syslog (acct_log) syslog: hidepasswd = "yes" syslog: logextra = "User-Name = %{User-Name},Client-IP-Address = %{Client-IP-Address},NAS-IP-Address = %{NAS-IP-Address},NAS-Port = %{NAS-Port}" syslog: logfacility = "local3" syslog: loglevel = "info" syslog: logname = "radiusd-auth" Module: Instantiated syslog (reply_log) Listening on authentication *:1645 Listening on accounting *:1646 Listening on authentication *:1812 Listening on accounting *:1813 Listening on proxy *:1647 Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1:36126, id=68, length=64 User-Name = "myuser" User-Password = "" NAS-IP-Address = 127.0.0.1 NAS-Port = 1 rad_rmspace_pair: User-Name now 'myuser' Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 hints: Matched DEFAULT at 35 radius_xlat: 'Port-1812' modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "auth_log" returns ok for request 0 users: Matched entry myuser at line 28547 modcall[authorize]: module "files" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type Accept rad_check_password: Auth-Type = Accept, accepting the user Login OK: [myuser] (from client localhost port 1) Processing the post-auth section of radiusd.conf modcall: entering group post-auth for request 0 radius_xlat: 'User-Name = myuser,Client-IP-Address = 127.0.0.1,NAS-IP-Address = 127.0.0.1,NAS-Port = 1' rlm_syslog: User-Name = %{User-Name},Client-IP-Address = %{Client-IP-Address},NAS-IP-Address = %{NAS-IP-Address},NAS-Port = %{NAS-Port} expands to User-Name = myuser,Client-IP-Address = 127.0.0.1,NAS-IP-Address = 127.0.0.1,NAS-Port = 1 modcall[post-auth]: module "reply_log" returns ok for request 0 modcall: leaving group post-auth (returns ok) for request 0 Sending Access-Accept of id 68 to 127.0.0.1 port 36126 Class = 0x4f553d414f4c2d5457 Filter-Id = "SPCCOLO_O" Finished request 0 Going to the next request

2 2

limiting user access
by simon＠434canada.com 02 Aug '06

02 Aug '06

>> I am setting up a single server to handle various access points at >> various locations. Is there a mechanism to limit access to a >> particular access point based on the username? > There are generic mechanisms to configure the server to do what you >want. I suggest putting the users into a group (see man rlm_passwd), >and then keying off of the NAS IP address to ensure that people not in >that group are denied access. See the FAQ. > > Alan DeKok. Will this mechanism work if I am using MySQL as a backend to store user information? I have looked over the man pages and the FAQ for rlm_passwd, and am still not sure how it all fits together. Are there other sources I could look at for more information? How does the module know which file to read when it initializes? And since this does not support dynamic updates of the files, would it still be a good option if the file will be changed in a dynamic fashion? Thanks again, Simon

1 0

huntgroups and mysql
by simon＠434canada.com 02 Aug '06

02 Aug '06

Hi, I want to restrict access for particular access points based on a user name. So a particular user can be authenticated on several access points (through a single freeRadius server) but should be denied access on others. I have been reading around, and I think that the way to approach this is through the use of huntgroups. I am not sure what changes need to be incorporated to make this work properly. I am running freeRadius 1.1.2, and am using mySQL 5 as a backend. Here is what I have started with. I set up an entry in the huntgroups file something like this: groupname1 NAS-IP-Address == 192.168.2.3 Group = firstgroup Then, in my database, I would need the following entries in the following tables: -- radcheck -- id UserName Attribute Value Op 1 test Password testp == 2 test Huntgroup-Name groupname1 == -- usergroup -- id UserName GroupName 1 test firstgroup Is this all that needs to be done? The goal here is to allow user "test" to be authenticated when he tries to connect from the NAS with IP address 192.168.2.3. If he tries to be authenticated through another NAS, then it should be rejected. My other question is if I want user "test" to know be allowed to authenticate through another NAS (in addition to the previous one), what needs to be done? I would think that I would need to make another entry for the second NAS in the huntgroups file (giving a Group = secondgroup key-value pair), and then make another entry in the usergroup table with UserName "test" and GroupName "secondgroup". If I am way off, other suggestions would also be greatly appreciated. Thanks, Simon

3 2