- Freeradius-Users - lists.freeradius.org

Question concerning changing a User-Name
by Bryan Graham 02 Apr '09

02 Apr '09

I'm using freeradius 2.1.4, hand compiled, and running on Solaris 10, in a zone. I've already got my server authorizing off of ldap and authenticating off of kerberos. What I would like to do is something slightly trickier. I would like to authorize off ldap and then authenticate off of kerberos, but using a different username. Optimally, this would happen by storing the alternate username in ldap, and then setting the username that will be used to authenticate against kerberos to this entry. I don't know if I would have to try to change the User-Name field (which I haven't had luck doing via the users file), or if there is some way to tell rlm_krb5 "hey, user this username instead". Worst case, I could create a mapping somewhere in a text file if needed, but storing the "other" username in ldap would be optimal. thanks, Bryan Graham

1 0

proxy setup questions
by Dallas Helquist 02 Apr '09

02 Apr '09

freeradius version: 1.0.1 (Centos4) I have the need to proxy requests based on "@domain.com" to different radius servers. I thought this would be fairly simple after reading proxy.conf, but I must be missing something! Here's the relevant portion of my proxy.conf: realm test.com { type = radius authhost = 10.19.3.8:1812 accthost = LOCAL secret = testing123 } realm test2.com { type = radius authost = 10.19.3.9:1812 accthost = LOCAL secret = testing123 } When testing via radtest using "test(a)test.com" the expected behavior happens - I see the request proxied to 1.1.1.1: <SNIP> rad_recv: Access-Request packet from host 127.0.0.1:53468, id=229, length=65 User-Name = "test(a)test.com" User-Password = "test" NAS-IP-Address = 255.255.255.255 NAS-Port = 123 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 rlm_realm: Looking up realm "test.com" for User-Name = "test(a)test.com" rlm_realm: Found realm "test.com" rlm_realm: Adding Stripped-User-Name = "test" rlm_realm: Proxying request from user test to realm test.com rlm_realm: Adding Realm = "test.com" rlm_realm: Preparing to proxy authentication request to realm "test.com" <SNIP> Sending Access-Request of id 0 to 10.19.3.8:1812 User-Name = "test" User-Password = "test" NAS-IP-Address = 255.255.255.255 NAS-Port = 123 Proxy-State = 0x323239 Great! Now I try it with "test(a)test2.com": rad_recv: Access-Request packet from host 127.0.0.1:53482, id=7, length=66 User-Name = "test(a)test2.com" User-Password = "test" NAS-IP-Address = 255.255.255.255 NAS-Port = 123 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 rlm_realm: Looking up realm "test2.com" for User-Name = "test(a)test2.com" rlm_realm: Found realm "test2.com" rlm_realm: Adding Stripped-User-Name = "test" rlm_realm: Proxying request from user test to realm test2.com rlm_realm: Adding Realm = "test2.com" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 0 Why would it make the Authentication realm LOCAL? If I move the realm test2.com above test.com in proxy.conf then test2.com works & test.com doesn't. Can someone point me in the right direction? I've read included doc/proxy, proxy.conf & the online wiki sections on proxy. It seems so simple, yet I can't seem to figure it out! Thanks in advance. -dallas

6 8

Re: Help checking group membership with FreeRadius
by Chris Li 02 Apr '09

02 Apr '09

> Date: Mon, 23 Mar 2009 11:22:22 -0400 > From: Josh Hiner <josh(a)remc1.org> > Subject: Help checking group membership with FreeRadius > To: freeradius-users(a)lists.freeradius.org > Message-ID: <200903231522.n2NFMNxv077788(a)mxdrop218.xs4all.nl> > Content-Type: text/plain; charset=UTF-8 > Currently we have a radius server that performs authentication off our samba domain controller for wireless users. This works great. I would like to limit users so they must be a member of the wireless group in order to connect. Since the /etc/group file is on a different server I believe I cannot use the etc_group module. Also, in order to use that module the user must have a valid account on the radius server as well. > Any ideas on checking group membership? I use ntlm_auth in the mschap module for authentication in Freeradius ver 2.1.3-1. i had a similar problem a few days ago run "getent passwd username" to see if you can get a line like: smith:*:100:3243::/home/smith:/usr/bin/sh if you do, '3243' is the principal group ID of the user my solution: use a perl script 'chkgrpmembership.pl'. to check the group membership of the user. the script set 'Group' attribute if the user is found. 1. chkgrpmembership.pl use strict; # use ... # This is very important ! Without this script will not get the filled hashesh from main. use vars qw(%RAD_REQUEST %RAD_REPLY %RAD_CHECK); use Data::Dumper; # This is hash wich hold original request from radius #my %RAD_REQUEST; # In this hash you add values that will be returned to NAS. #my %RAD_REPLY; #This is for check items #my %RAD_CHECK; # # This the remapping of return values # use constant RLM_MODULE_REJECT=> 0;# /* immediately reject the request */ use constant RLM_MODULE_FAIL=> 1;# /* module failed, don't reply */ use constant RLM_MODULE_OK=> 2;# /* the module is OK, continue */ use constant RLM_MODULE_HANDLED=> 3;# /* the module handled the request, so stop. */ use constant RLM_MODULE_INVALID=> 4;# /* the module considers the request invalid. */ use constant RLM_MODULE_USERLOCK=> 5;# /* reject the request (user is locked out) */ use constant RLM_MODULE_NOTFOUND=> 6;# /* user not found */ use constant RLM_MODULE_NOOP=> 7;# /* module succeeded without doing anything */ use constant RLM_MODULE_UPDATED=> 8;# /* OK (pairs modified) */ use constant RLM_MODULE_NUMCODES=> 9;# /* How many return codes there are */ # Function to handle authorize sub authorize { my $getentResult = qx(getent passwd $RAD_REQUEST{'User-Name'}); my @resultArray = split ":", $getentResult; my $arraySize = scalar @resultArray; # Group ID 11184 = staff # Group ID 12705 = student if ($arraySize != 0) { my $groupID = $resultArray[3]; if ($groupID == 11184) { $RAD_REPLY{'Group'} = "Staff"; } elsif ($groupID == 12705) { $RAD_REPLY{'Group'} = "Student"; } else { # We only allow Staff and Student group return RLM_MODULE_REJECT; } } else { #user no found in AD return RLM_MODULE_REJECT; } return RLM_MODULE_OK; } 2.add the following lines to the modules section of radius.conf perl { module = /etc/freeradius/chkgrpmembership.pl func_authorize = authorize } 3. In the Authorize section, uncomment 'files'. Then add a line containing 'perl' after it. In the Authentication section add Auth-Type Perl { perl } 4. if you use EAP/TLS, you need to enable use_tunneled_reply, in (peap and/or ttls section) eap.conf 5. finally, you can a line to 'users' file DEFAULT Group != "wireless", Auth-Type := Reject (Sorry for starting a new thread, i subscribed to the "digest" version of the mailing list) Chris

2 1

Radclient & PHP
by AHMED KHIDR 02 Apr '09

02 Apr '09

Hii All , Please Any one have an idea how to make a PHP code to run Radclient in order to disconnect users , Thanks

7 8

integrate dhcpd and freeRADIUS logs
by deveshgade 02 Apr '09

02 Apr '09

I want to maintain a log of the username,ip address and the mac address of the client connecting to my FreeRADIUS-2.1.1 server in a wireless network. I am using dhcpd, from which the mac address of client can be obtained. I wanted to know if anyone has written a script to map radius logs to the dhcpd logs so that one would be able to compare the username,ip address and mac address of the client. Based on comparison of the above values,access to the wifi network would be granted to the user. Can anyone give me a sample or an real shell script or php script for the same?? -- View this message in context: http://www.nabble.com/integrate-dhcpd-and-freeRADIUS-logs-tp22854371p228543… Sent from the FreeRadius - User mailing list archive at Nabble.com.

2 1

Seg Fault in 2.0.3
by Garber, Neal 02 Apr '09

02 Apr '09

I have a FR 2.0.3 server running under FreeBSD 6.3 which intermittently exits with a segmentation fault. I tried searching the list for known seg fault issues with 2.0.3 and only found one which sounded like it only happens when running under gdb. Do you think upgrading to 2.1.3 (it's the latest port for FR under FreeBSD) could potentially resolve this issue? (I'm not looking for a guarantee, just an opinion based upon whether there were known seg faults in 2.0.3 that were fixed in later releases.) Should I run FR under gdb to get more information about the seg fault? This morning it happened while I was running "radiusd -Xx" and the error occurred a few minutes after a request was successfully processed as a new request was received and before it was able to output any information about it. The server had been running for less than a week (most times it runs longer than this before crashing). So, the last two lines of output were: Tue Mar 31 07:52:08 2009 : Debug: Ready to process requests. Segmentation Fault: 11 I realize this isn't enough to diagnose the problem (but, it's all the information I currently have). Please let me know how you think it's best to proceed (e.g., upgrade, get more info about the problem, other..) Thanks in advance for any assistance/advice you can provide.

2 2

if we add a smartcard!
by new conf 01 Apr '09

01 Apr '09

Hi everybody and experts in freeradius; :) I'm a new user of the server.. I succeeded to connect a client (supplicant) over wifi to the radius server using eap method.. now, i have to secure the server private key in a smart card.. have you an idea what can I add in eap.conf and in this attribute: certificate_file = ?? I'll be grateful for your help! thanks!

1 1

RE: SQL xlat not working
by Eric Geier 01 Apr '09

01 Apr '09

> >I've googled for it. Plus someone here had mentioned "rlm_raw and use > it > >with a SQL xlat rule". I think I'm doing that, but it's not working. > Please > >let me know what might be holding it up. > > > > Lack of rlm_raw? That doesn't come with the server. But even without using a raw attribute, the SQL xlat rule doesn't work, such as: client 192.168.0.1/32 { secret = "%{sql:SELECT secret FROM APs WHERE NAS-Identifier='blah'" shortname = testnet } When googling, I think I found that when using LDAP, I would have to change a setting to get this working....I didn't find a similar setting for SQL. > >> You can load clients from nas table. See read_clients setting near > the > >> end of sql.conf file. > > > >That may work, but could I have the Name field represent something > besides > >the IP, like the NAS-Identifier? > > No. Unless you alter source code. Patches are welcome. Is there a how to I can read to learn about this?

2 1

SOLVED: Re: Freeradius-Users Digest, Vol 48, Issue 4
by sankalpk 01 Apr '09

01 Apr '09

Hi Ivan, This solved my purpose. Thanks a lot for your quick response. Regards, Sankalp >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 01 Apr 2009 12:46:05 +0100 >From: <tnt(a)kalik.net> >Subject: Re: Authenticating Restricted Users through LDAP >To: "FreeRadius users mailing list" > <freeradius-users(a)lists.freeradius.org> >Message-ID: <LOuX7IkE.1238586365.8744300.tnt(a)kalik.net> >Content-Type: text/plain; charset=ISO-8859-2 > > > >>I have a setup of Freeradius 1.1.4 running with openldap 2.2.13. The >>radius server authenticates clients based on Username and Password that >>clients provide through a web page. This is working fine. Now I want >>that restricted users in LDAP can be authenticated, but I cannot make a >>separated OU for those users, since there are other applications being >>served by this LDAP. >> >>Is there a way that I can set an attribute like "radiusAccess" in LDAP, >>and Radius Server will check from LDAP that if radiusAccess attribute is >>set to 1 AND Username and Passwords match, then it shoud give the >>access. For users whose radiusAccess attribute is not set, access should >>not be given even if Username and Password are correct. >> >> >> > >Yes, attribute is called dialupAccess in ldap. Read ldap.conf to see how >to set this up. > >Ivan Kalik >Kalik Informatika ISP > > > DISCLAIMER: This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may containconfidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. The recipient acknowledges that Tulip Telecom Limited is unable to exercise control or ensure or guarantee the integrity of/overthe contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of Tulip Telecom Limited. Before opening any attachments please check them for viruses! and defects.

1 0

freeradius help
by Basant Agarwal 01 Apr '09

01 Apr '09

Hello , I am using Freeradius-1.1.7 with ldap , i am being able to authenticate users when i run radtest , those who are in my ldap directory, but i am unable to authenticate the same authenticate users when i try from the laptop(wifi ) . What should i do .. here the debug mode when i try from radtest---- rad_recv: Access-Request packet from host 127.0.0.1:2050, id=203, length=58 User-Name = "basant" User-Password = "basant" NAS-IP-Address = 255.255.255.255 NAS-Port = 0 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "basant", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 users: Matched entry DEFAULT at line 152 modcall[authorize]: module "files" returns ok for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for basant radius_xlat: '(cn=basant)' radius_xlat: 'ou=radius,dc=basant,dc=com' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to localhost:389, authentication 0 rlm_ldap: bind as cn=admin,dc=basant,dc=com/basant to localhost:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in ou=radius,dc=basant,dc=com, with filter (cn=basant) rlm_ldap: checking if remote access for basant is allowed by cn rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user basant authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type LDAP auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group LDAP for request 0 rlm_ldap: - authenticate rlm_ldap: login attempt by "basant" with password "basant" rlm_ldap: user DN: cn=basant,ou=admins,ou=radius,dc=basant,dc=com rlm_ldap: (re)connect to localhost:389, authentication 1 rlm_ldap: bind as cn=basant,ou=admins,ou=radius,dc=basant,dc=com/basant to localhost:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: user basant authenticated succesfully modcall[authenticate]: module "ldap" returns ok for request 0 modcall: leaving group LDAP (returns ok) for request 0 Processing the post-auth section of radiusd.conf modcall: entering group post-auth for request 0 modcall[post-auth]: module "ldap" returns noop for request 0 modcall: leaving group post-auth (returns noop) for request 0 Sending Access-Accept of id 203 to 127.0.0.1 port 2050 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 203 with timestamp 49d36e19 Nothing to do. Sleeping until we see a request. -(Above output is of, when i run the same FR server on virtual machine, result are same as when i do the same radtest on the server which is used below but name of users, password, and LDAP server name are different, ) Here the debug mode output when i try to test from the labtop -- rad_recv: Access-Request packet from host 172.16.1.205:3072, id=0, length=129 User-Name = "easypush" NAS-IP-Address = 172.16.1.205 Called-Station-Id = "001a70aa5bee" Calling-Station-Id = "0021002ca72e" NAS-Identifier = "001a70aa5bee" NAS-Port = 37 Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0200000d016561737970757368 Message-Authenticator = 0x19517eaaaf0d384f55a94c110166d9a7 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "easypush", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: EAP packet type response id 0 length 13 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 0 users: Matched entry DEFAULT at line 152 modcall[authorize]: module "files" returns ok for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for easypush radius_xlat: '(uid=easypush)' radius_xlat: 'ou=people,dc=mnit,dc=ac,dc=in' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to 172.16.1.150:389, authentication 0 rlm_ldap: bind as uid=easypush,ou=people,dc=mnit,dc=ac,dc=in/basant to 172.16.1.150:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in ou=people,dc=mnit,dc=ac,dc=in, with filter (uid=easypush) rlm_ldap: checking if remote access for easypush is allowed by uid rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user easypush authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 0 modcall: leaving group authorize (returns updated) for request 0 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_eap: EAP Identity rlm_eap: processing type md5 rlm_eap_md5: Issuing Challenge modcall[authenticate]: module "eap" returns handled for request 0 modcall: leaving group authenticate (returns handled) for request 0 Sending Access-Challenge of id 0 to 172.16.1.205 port 3072 EAP-Message = 0x010100160410176918b1dfe5a216d1b3635a4fff6d2a Message-Authenticator = 0x00000000000000000000000000000000 State = 0x1fe1317a964fed1b43bd8725746926b5 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host 172.16.1.205:3072, id=0, length=140 User-Name = "easypush" NAS-IP-Address = 172.16.1.205 Called-Station-Id = "001a70aa5bee" Calling-Station-Id = "0021002ca72e" NAS-Identifier = "001a70aa5bee" NAS-Port = 37 Framed-MTU = 1400 State = 0x1fe1317a964fed1b43bd8725746926b5 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020100060319 Message-Authenticator = 0x38d2a4a14038ef3786049229a013b6ca Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 modcall[authorize]: module "preprocess" returns ok for request 1 modcall[authorize]: module "chap" returns noop for request 1 modcall[authorize]: module "mschap" returns noop for request 1 rlm_realm: No '@' in User-Name = "easypush", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 1 rlm_eap: EAP packet type response id 1 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 1 users: Matched entry DEFAULT at line 152 modcall[authorize]: module "files" returns ok for request 1 rlm_ldap: - authorize rlm_ldap: performing user authorization for easypush radius_xlat: '(uid=easypush)' radius_xlat: 'ou=people,dc=mnit,dc=ac,dc=in' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=people,dc=mnit,dc=ac,dc=in, with filter (uid=easypush) rlm_ldap: checking if remote access for easypush is allowed by uid rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user easypush authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 1 modcall: leaving group authorize (returns updated) for request 1 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 1 rlm_eap: Request found, released from the list rlm_eap: EAP NAK rlm_eap: EAP-NAK asked for EAP-Type/peap rlm_eap: No such EAP type peap rlm_eap: Failed in EAP select modcall[authenticate]: module "eap" returns invalid for request 1 modcall: leaving group authenticate (returns invalid) for request 1 auth: Failed to validate the user. Delaying request 1 for 1 seconds Finished request 1 Going to the next request Waking up in 6 seconds... --- Walking the entire request list --- Sending Access-Reject of id 0 to 172.16.1.205 port 3072 EAP-Message = 0x04010004 Message-Authenticator = 0x00000000000000000000000000000000 Cleaning up request 1 ID 0 with timestamp 49d2d702 Nothing to do. Sleeping until we see a request.

2 1