Radiator required a valid Authenticator to be part of the Accouning Request. I am proxying from freeradius to radiator. How can this be resolved ? -----Original Message----- From: freeradius-users-bounces@lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] On Behalf Of freeradius-users-request@lists.freeradius.org Sent: 30 September 2005 06:12 PM To: freeradius-users@lists.freeradius.org Subject: Freeradius-Users Digest, Vol 5, Issue 103 Send Freeradius-Users mailing list submissions to freeradius-users@lists.freeradius.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freeradius.org/mailman/listinfo/freeradius-users or, via email, send a message with subject or body 'help' to freeradius-users-request@lists.freeradius.org You can reach the person managing the list at freeradius-users-owner@lists.freeradius.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Freeradius-Users digest..." Today's Topics: 1. RE: Proxy of accounting message (Ashwin Gobind) 2. EAP-PEAP-MSCHAPv2: use_tunneled_reply = yes (Bjarni Hardarson) 3. Re: freeradius and MS SQL -- anyone got it working? (Duane Cox) 4. Re: Expose RADIUS packet's identifier (James J J Hooper) 5. Re: Segmentation Fault - 1.0.5 (Alan DeKok) 6. Re: SSL3_GET_CLIENT_KEY_EXCHANGE (Alan DeKok) 7. Re: freeradius and MS SQL -- anyone got it working? (Alan DeKok) 8. Re: Proxy of accounting message (Alan DeKok) ---------------------------------------------------------------------- Message: 1 Date: Fri, 30 Sep 2005 14:39:18 +0200 From: "Ashwin Gobind" <Ashwin.Gobind@vodacom.co.za> Subject: RE: Proxy of accounting message To: <freeradius-users@lists.freeradius.org> Message-ID: <753BF83740BB6C48BF8A15B5C61C88470BC3B149@zamdc02100.vodacom.corp> Content-Type: text/plain; charset="us-ascii" Thanks nick. However when I proxy the message, the message-authenticator field has an <INVAILID TOKEN> (see trace below). Why is this Sending Accounting-Request of id 1 to 10.113.46.170:1813 Acct-Status-Type = Start Service-Type = Framed-User Called-Station-Id = "vlive" Framed-Protocol = GPRS-PDP-Context Framed-Protocol = GPRS-PDP-Context Acct-Delay-Time = 5 Calling-Station-Id = "27829800729" NAS-Identifier = "GMC-GGSN0-13-2" Acct-Session-Id = "20050529" User-Name = "27829800729" User-Name = "27829800729" NAS-Port = 6000 NAS-Port-Type = Virtual NAS-IP-Address = 10.111.14.46 Message-Authenticator <INVALID-TOKEN> 0x00000000000000000000000000000000 Proxy-State = 0x30 "This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.net/legal/email.aspx " ------------------------------ Message: 2 Date: Fri, 30 Sep 2005 14:51:25 +0200 From: "Bjarni Hardarson" <freeradius@hardarson.se> Subject: EAP-PEAP-MSCHAPv2: use_tunneled_reply = yes To: <freeradius-users@lists.freeradius.org> Message-ID: <000a01c5c5bd$af45b880$6400a8c0@client> Content-Type: text/plain; charset="us-ascii" Hi all, I'm using FreeRADIUS with Cisco 1200 Series Access points for dynamic VLAN assignment. When i set use_tunneled_reply = yes for PEAP i get an Access-Challenge with the correct attributes but the final Access-Accept has no attributes and the User-Name is the anonymous one from the outer tunnel. This username is then used by the AP for accounting. Is this by design or is my configuration wrong? Partial debug, Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 24 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns ok for request 24 modcall: group authenticate returns ok for request 24 PEAP: Got tunneled reply RADIUS code 2 User-Name = "radtest" Tunnel-Private-Group-Id:0 = "310" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN EAP-Message = 0x03080004 Message-Authenticator = 0x00000000000000000000000000000000 PEAP: Processing from tunneled session code 0x818f508 2 User-Name = "radtest" Tunnel-Private-Group-Id:0 = "310" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN EAP-Message = 0x03080004 Message-Authenticator = 0x00000000000000000000000000000000 PEAP: Tunneled authentication was successful. rlm_eap_peap: SUCCESS modcall[authenticate]: module "eap" returns handled for request 24 modcall: group authenticate returns handled for request 24 Sending Access-Challenge of id 8 to 127.0.0.1:33229 User-Name = "radtest" Tunnel-Private-Group-Id:0 = "310" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Message-Authenticator = 0x00000000000000000000000000000000 EAP-Message = 0x010900501900170301002079fdf7026cf88ffd8c978e4fb62290b4d4f4a1596c767f55 7ada bdaf51b7437d17030100209a1de8e9b88b4654d03b0754d4f5a04887b57b329c94a6494e f84d 2bf74f294c State = 0x3c86d1f16a6312263ae7a01dbfc81a28 Finished request 24 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 127.0.0.1:33229, id=9, length=205 User-Name = "anon" NAS-IP-Address = 127.0.0.1 Calling-Station-Id = "00-00-00-00-00-02" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x0209005019001703010020f8f585176e2220ba00055d66cd73494a9539cce8d52da81f f067 f5835fd4de1117030100207461f938bb9af8c154f926ab2eb5653392cb1ebb02782ac58c 3b6c ca8566fbdd State = 0x3c86d1f16a6312263ae7a01dbfc81a28 Message-Authenticator = 0x830975610af464574e583a2a9240068d Processing the authorize section of radiusd.conf modcall: entering group authorize for request 25 modcall[authorize]: module "preprocess" returns ok for request 25 radius_xlat: '/var/log/radiusd/radiusd-20050930' rlm_detail: /var/log/radiusd/radiusd-%Y%m%d expands to /var/log/radiusd/radiusd-20050930 modcall[authorize]: module "auth_log" returns ok for request 25 modcall[authorize]: module "chap" returns noop for request 25 modcall[authorize]: module "mschap" returns noop for request 25 rlm_realm: No '@' in User-Name = "anon", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 25 rlm_eap: EAP packet type response id 9 length 80 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 25 modcall[authorize]: module "files" returns notfound for request 25 modcall: group authorize returns updated for request 25 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 25 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS eaptls_verify returned 7 rlm_eap_tls: Done initial handshake eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: Received EAP-TLV response. rlm_eap_peap: Tunneled data is valid. rlm_eap_peap: Success rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns ok for request 25 modcall: group authenticate returns ok for request 25 Sending Access-Accept of id 9 to 127.0.0.1:33229 MS-MPPE-Recv-Key = 0x73f9e4f3cc50836d0d52db55ddceb6afb7fea6e50313380873101fe245e6532d MS-MPPE-Send-Key = 0xcbf30f484d74cc947dcd0ea4fb49f7d94adb6be677e23d4edae3a22d136ad3b9 EAP-Message = 0x03090004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "anon" Finished request 25 Going to the next request Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 16 ID 0 with timestamp 433d25b6 Cleaning up request 17 ID 1 with timestamp 433d25b6 Cleaning up request 18 ID 2 with timestamp 433d25b6 Cleaning up request 19 ID 3 with timestamp 433d25b6 Cleaning up request 20 ID 4 with timestamp 433d25b6 Cleaning up request 21 ID 5 with timestamp 433d25b6 Cleaning up request 22 ID 6 with timestamp 433d25b6 Cleaning up request 23 ID 7 with timestamp 433d25b6 Cleaning up request 24 ID 8 with timestamp 433d25b6 Cleaning up request 25 ID 9 with timestamp 433d25b6 Nothing to do. Sleeping until we see a request. --------------------------------------------------- When i use TTLS everything works perfectly. If i set use_tunneled_reply = no for TTLS the outer tunnel identity is used in the Access-Accept and no attributes are returned. Partial debug, Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 7 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns ok for request 7 modcall: group authenticate returns ok for request 7 TTLS: Got tunneled reply RADIUS code 2 User-Name = "radtest" Tunnel-Private-Group-Id:0 = "310" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN EAP-Message = 0x03070004 Message-Authenticator = 0x00000000000000000000000000000000 TTLS: Got tunneled Access-Accept rlm_eap: Freeing handler TTLS: Freeing handler for user radtes modcall[authenticate]: module "eap" returns ok for request 7 modcall: group authenticate returns ok for request 7 Sending Access-Accept of id 7 to 127.0.0.1:33227 User-Name = "radtest" Tunnel-Private-Group-Id:0 = "310" Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Message-Authenticator = 0x00000000000000000000000000000000 MS-MPPE-Recv-Key = 0xf250fa51ea382aef2f2ea5ebaab8596fa822cf6788ccd2782fe2e7df98cd06aa MS-MPPE-Send-Key = 0xca164c1041c8b439c99b13505ba04aaf48cabf6802df8c92738a2c12349b4be2 EAP-Message = 0x03070004 Finished request 7 Going to the next request Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 0 with timestamp 433d1f58 Cleaning up request 1 ID 1 with timestamp 433d1f58 Cleaning up request 2 ID 2 with timestamp 433d1f58 Cleaning up request 3 ID 3 with timestamp 433d1f58 Cleaning up request 4 ID 4 with timestamp 433d1f58 Cleaning up request 5 ID 5 with timestamp 433d1f58 Cleaning up request 6 ID 6 with timestamp 433d1f58 Cleaning up request 7 ID 7 with timestamp 433d1f58 Nothing to do. Sleeping until we see a request. raddb/eap.conf eap { default_eap_type = peap timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no tls { private_key_password = ******** private_key_file = ${raddbdir}/certs/srv_key.pem certificate_file = ${raddbdir}/certs/srv_cert.pem CA_file = ${raddbdir}/certs/demoCA/prv.pem dh_file = ${raddbdir}/certs/dh random_file = /dev/urandom } ttls { default_eap_type = mschapv2 copy_request_to_tunnel = no use_tunneled_reply = yes } mschapv2 { } peap { default_eap_type = mschapv2 copy_request_to_tunnel = no use_tunneled_reply = yes } mschapv2 { } } raddb/users DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1 User-Name = "%{User-Name}", Fall-Through = Yes DEFAULT Huntgroup-name == "LAN", FreeRADIUS-Proxied-To == 127.0.0.1, Autz-Type := LAN DEFAULT Huntgroup-name == "AIR", FreeRADIUS-Proxied-To == 127.0.0.1, Autz-Type := AIR ------------------------------ Message: 3 Date: Fri, 30 Sep 2005 08:28:39 -0500 From: "Duane Cox" <duanec@mail.illicom.net> Subject: Re: freeradius and MS SQL -- anyone got it working? To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Message-ID: <006101c5c5c2$ded92ff0$7c01a8c0@COMPUTER> Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original There are a few qwerks with getting FreeRadius to work with MSSQL. First thing, the FreeTDS files have been removed (more like abandonded) from FreeRadius. If you really want to call FreeTDS direclty, you will have to download the files from the "attic". But more than that you will also have to update the files as they do not currently compile properly, they are a bit old. I would suggest to go with unixodbc or iodbc, even though using FreeTDS is IMHO the best way, it's not supported. Second, in order to get MSSQL to work with the current version of FreeRadius 1.0.5, you will need to install either unixodbc or iodbc. I chose unixodbc; and in doing so it requires FreeTDS. So install both FreeTDS and unixODBC. Third. You will need to include mssql.conf and call rlm_sql_unixodbc. The mssql.conf has to many tricks to it. First the default driver is invalid and the "server" is really the DSN and must match that name found in /etc/odbc.ini. Also /etc/odbc.ini must be readable by the freeradius daemon. Also, there is an extra statement in the mssql.conf that is totaly not used and can be deleted; it's "authenticate_query". These things should help you out. If you need any further assistance, ie. configure/make commands and file contents ask again. Good Luck Duane Hi list, What is the status of MS SQL support for freeradius? Did anyone get it working? And if yes, which version do you use and what is required to get it work? I'm currently using freeradius 1.0.2 on Debian Sarge and I didn't manage to get it connect to the MS SQL server. As the rlm_sql_freetds module states that it is under development ans so, not enabled by default, I was wondering, if the iODBC or the unixodbc modules would work and if yes, how to set this up (aside from freeradius.. seems the 'drivers' are missing, whatever this means). Need some help here. Anyone? Cheers Arne ------------------------------ Message: 4 Date: Fri, 30 Sep 2005 15:24:39 +0000 From: James J J Hooper <jjj.hooper@bristol.ac.uk> Subject: Re: Expose RADIUS packet's identifier To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <B50EB08E7A3193762AED22AB@valium.cse.bris.ac.uk> Content-Type: text/plain; charset=us-ascii; FORMAT=flowed

ATTRIBUTE Packet-Authentication-Vector 1088 octets

Alan DeKok.

can't get it to work: radius -X says: WARNING: Attempt to use unknown xlat function, or non-existent attribute in string %{Packet-Authentication-Vector} in radiusd.conf: exec logit { wait = yes input_pairs = request output_pairs = none program = "/etc/raddb/bin/logit.sh %{Packet-Authentication-Vector}" } logit called in authorize. Thanks in advance for any help you can give, James. ------------------------------ Message: 5 Date: Fri, 30 Sep 2005 11:01:25 -0400 From: "Alan DeKok" <aland@ox.org> Subject: Re: Segmentation Fault - 1.0.5 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <20050930150125.3446116CC1@mail.nitros9.org> "Rohaizam Abu Bakar" <haizam@myjaring.net> wrote:

cleaning up old files... recompile... and still segmentation fault... but worse than before.. since the daemon cannot even up..

seems problem with rlm_ldap...

That's bug #98. Either link statically, or put the libraries rlm_ldap needs in a place where the dynamic linker can find them. Alan DeKok. ------------------------------ Message: 6 Date: Fri, 30 Sep 2005 11:02:44 -0400 From: "Alan DeKok" <aland@ox.org> Subject: Re: SSL3_GET_CLIENT_KEY_EXCHANGE To: Juan Daniel Moreno <juanitomoreno@gmail.com>, FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <20050930150244.AA91016CC1@mail.nitros9.org> Juan Daniel Moreno <juanitomoreno@gmail.com> wrote:

Can you please tell me the client's exchange packet form the server is attempting? How is it calculated?

Read the FreeRADIUS source code.

Or, can you show me a typical byte suite from this message? (I hope you understand me)

Use ethereal. Alan DeKok. ------------------------------ Message: 7 Date: Fri, 30 Sep 2005 11:14:57 -0400 From: "Alan DeKok" <aland@ox.org> Subject: Re: freeradius and MS SQL -- anyone got it working? To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <20050930151457.9FDB316CC1@mail.nitros9.org> "Duane Cox" <duanec@mail.illicom.net> wrote:

First thing, the FreeTDS files have been removed (more like abandonded) from FreeRadius.

It was "abandoned" at the specific request of the FreeTDS project members, who told us the FreeTDS API used by the module was not stable, and shouldn't be used by anyone.

Second, in order to get MSSQL to work with the current version of FreeRadius 1.0.5, you will need to install either unixodbc or iodbc. I chose unixodbc; and in doing so it requires FreeTDS. So install both FreeTDS and unixODBC.

Oh, so it *does* work with the unixODBC module, like I said. Why then the comments about the freetds module?

Third. You will need to include mssql.conf and call rlm_sql_unixodbc. The mssql.conf has to many tricks to it. First the default driver is invalid and the "server" is really the DSN and must match that name found in /etc/odbc.ini. Also /etc/odbc.ini must be readable by the freeradius daemon. Also, there is an extra statement in the mssql.conf that is totaly not used and can be deleted; it's "authenticate_query".

Please submit patches to the files & docs. We'll be glad to fix any issues with the project. Alan DeKok. ------------------------------ Message: 8 Date: Fri, 30 Sep 2005 12:02:34 -0400 From: "Alan DeKok" <aland@ox.org> Subject: Re: Proxy of accounting message To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <20050930160236.1CA4116CC1@mail.nitros9.org> "Ashwin Gobind" <Ashwin.Gobind@vodacom.co.za> wrote:

Thanks nick. However when I proxy the message, the message-authenticator field has an <INVAILID TOKEN> (see trace below). Why is this

Message-Authenticator is NOT supported in Accounting packets. Alan DeKok. ------------------------------ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html End of Freeradius-Users Digest, Vol 5, Issue 103 ************************************************ �This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.net/legal/email.aspx "