April 2009 - Freeradius-Users - lists.freeradius.org

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

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

01 Apr '09

> >I can't get SQL xlat to work in the Clients file. I'm trying to do a > DB > >query for the Shared Secret. > > > > And where did you find that it should work? 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. > >I'm getting invalid Message-Authenticator (Shared secret is incorrect) > >errors. > > You should fix client secret to match the server not other way round. > > >The select statement works fine when ran on my DB server. > > > >Have any suggestions? > > 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? Thanks! Eric

2 1

Is WLAN IEEE802.1x EAP-TLS authentication with ESSID selection possible?
by Ulf Leichsenring 01 Apr '09

01 Apr '09

Hi FreeRADIUS user community I'm in search for some ideas for the following situation: Given are several WLANS controlled by a Siemens Hipath C2400 WLAN Controller with Siemens APs. The controller provides different WLANs identified by different ESSIDs. All WLAN Clients use IEEE802.1x authentication with EAP-TLS and client certificates. The authentication is done by FreeRADIUS 1.0.1 on Redhat EL AS4. At the moment, all clients use certificates and inside the FreeRADIUS eap-tls section the ca certificates are trusted. All Windows clients use a MS CA an have certificates with the Windows system name as the certificates common name. Other devices like mobile scanners or WLAN mobile phones (VoIP) have manually generated certificates with the device type as the certificates common name like "phone", "mobile scanner" or else. So long, it works. But now I was asked if it is possible to restrict the association of several device types to defined ESSIDs. There shoul be a WLAN "office" where all devices are allowed to connect if they have a valid certificate. Other ESSIDs should only accept special devices, eg. only devices with the certificates common name "phone" should be allowed to connect to the ESSID "voice". I know, the Siemens controller is able to send the ESSID the device is trying to connect inside the RADIUS request as vendor specific attribute. Is it possible with FreeRADIUS to match these requirements? To select based on the ESSID the device is connecting to? If the connecting ESSID is "office", all devices with a valid certificate are allowed to connect. If the ESSID is "voice", only devices with a valid certificate and with a certificates common name that contains "*phone*" are allowed to connect. If the ESSID is "production-1", only devices with a valid certificate and with a certificates common name that contains "*mobile scanner*" are allowed to connect. I've googled a lot, without success. All Freeradius documentation I've found about eap-tls only descibes how to accept all devices with a valid certificate. I've seen this scenario running with commercial RADIUS servers but I guess it might also be possible using FreeRADIUS. Any tip oder idea is welcome. -- Ulf Leichsenring ulf(a)leichsenring.net

3 4

rlm_python example?
by Hristo Trendev 01 Apr '09

01 Apr '09

I am trying to figure out how to properly setup freeradius with rlm_python. The module loads and scripts execute, but I seem to miss something when I try to return value pairs to be used in the reply packet (Access-Accept). I have tried with the following script: def authorize (params): print params return (0, ('Reply-Message', 'banned1'), ('Reply-Message', 'banned2')) and received (when I run with -X option): -----snip----- +- entering group authorize {...} rlm_python:authorize: tuple element 0 is not a tuple rlm_python:authorize: tuple element 1 is not a tuple rlm_python:authorize: tuple element 0 is not a tuple rlm_python:authorize: tuple element 1 is not a tuple ++[python] returns reject -----snip----- I have also tried changing it to: def authorize (params): print params return (0, ('Reply-Message', 'banned')) but then I get: -----snip----- +- entering group authorize {...} rlm_python:authorize: tuple must be (return, replyTuple, configTuple) ++[python] returns ?? -----snip----- Can someone point me in the right direction? What is supposed to be passed in configTuple? How do I return multiple value pairs at? I was able to make it work with rlm_exec, but I'd like to use the the python module instead. I am using freeradius on ubuntu 8.04. installed via apt-get from hardy-backports (2.1.0+dfsg-0ubuntu2~hardy1) BR, Hristo

2 2

Authenticating Restricted Users through LDAP
by sankalpk 01 Apr '09

01 Apr '09

Hi All, 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. In the current scenario, I am not using any radius Schema or any other attribute specific to Radius. Thanks and Regards, Sankalp +---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 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.

2 1

vlan priority query
by Mitul Modi 01 Apr '09

01 Apr '09

hi, How we can configure radius server to send vlan priority in access accept message? Thanks, Mitul Modi

3 6

Duplicate Acct-Status packets
by Bogomolov Andrei 01 Apr '09

01 Apr '09

I'm running freeradius-1.1.7: NAS server sends Acct-Status-Start packet, then freeradius processes it, and confirms with Acct-Status-Reply. But if the reply packet is lost due UDP-nature, NAS sends second Acct-Status-Start. In this situation I have two duplicate records in radacct table. How can I avoid this? Unique db-indexes, or better something else?

3 4

SQL xlat not working
by Eric Geier 01 Apr '09

01 Apr '09

I can't get SQL xlat to work in the Clients file. I'm trying to do a DB query for the Shared Secret. I'm getting invalid Message-Authenticator (Shared secret is incorrect) errors. The select statement works fine when ran on my DB server. Have any suggestions? Thanks, Eric

2 1

RE: MAC auth won't work with SQL
by Eric Geier 01 Apr '09

01 Apr '09

Great, works now. Thanks! Is there a way to load the Database Value field with multiple MAC addresses, and freeradius check against them....so I can specify multiple devices the user can use? - Eric > -----Original Message----- > From: freeradius-users-bounces+me=egeier.com(a)lists.freeradius.org > [mailto:freeradius-users-bounces+me=egeier.com@lists.freeradius.org] On > Behalf Of tnt(a)kalik.net > Sent: Tuesday, March 31, 2009 5:11 PM > To: FreeRadius users mailing list > Subject: Re: MAC auth won't work with SQL > > >Hi, I've setup two different Linux machines with FR and still can't > get MAC > >authentication working with Calling-Station-Id in the radchk table. > I've > >checked FAQ and have googled for hours. I've tried a hosted and local > mySQL > >server. > > > > If you only bothered looking at debug and configuration files for the > authentication method you are using. Outer request: > > >rad_recv: Access-Request packet from host 192.168.0.1 port 41576, > id=191, > >length=230 > .. > > Calling-Station-Id = "00-1C-B3-B1-3E-07" > .. > > has that attribute in it, and inner request (user is authenticated in > inner tunnel): > > >Sending tunneled request > > > > EAP-Message = > >0x026c00491a026c00443177f318d460fc36f9cc77a41c0a4b36560000000000000000 > 10538d > >55c2badfcc4a85b41f875a5521f978d255be29a7d20065676569657240736b796e6574 > 73 > > > > FreeRADIUS-Proxied-To = 127.0.0.1 > > > > User-Name = "egeier@skynets" > > > > State = 0x8433f2b7845fe8463016d60fe5b8c67e > > .. doesn't! You have a setting copy_request_to_tunnel in peap section > of eap.conf. Enable it. > > Ivan Kalik > Kalik Informatika ISP > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html

2 1