Proxy of accounting message (Ashwin Gobind)
Ashwin Gobind
Ashwin.Gobind at vodacom.co.za
Mon Oct 3 12:18:08 CEST 2005
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 at lists.freeradius.org
[mailto:freeradius-users-bounces at lists.freeradius.org] On Behalf Of
freeradius-users-request at lists.freeradius.org
Sent: 30 September 2005 06:12 PM
To: freeradius-users at lists.freeradius.org
Subject: Freeradius-Users Digest, Vol 5, Issue 103
Send Freeradius-Users mailing list submissions to
freeradius-users at 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 at lists.freeradius.org
You can reach the person managing the list at
freeradius-users-owner at 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 at vodacom.co.za>
Subject: RE: Proxy of accounting message
To: <freeradius-users at lists.freeradius.org>
Message-ID:
<753BF83740BB6C48BF8A15B5C61C88470BC3B149 at 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 at hardarson.se>
Subject: EAP-PEAP-MSCHAPv2: use_tunneled_reply = yes
To: <freeradius-users at lists.freeradius.org>
Message-ID: <000a01c5c5bd$af45b880$6400a8c0 at 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 at mail.illicom.net>
Subject: Re: freeradius and MS SQL -- anyone got it working?
To: "FreeRadius users mailing list"
<freeradius-users at lists.freeradius.org>
Message-ID: <006101c5c5c2$ded92ff0$7c01a8c0 at 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 at bristol.ac.uk>
Subject: Re: Expose RADIUS packet's identifier
To: FreeRadius users mailing list
<freeradius-users at lists.freeradius.org>
Message-ID: <B50EB08E7A3193762AED22AB at 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 at ox.org>
Subject: Re: Segmentation Fault - 1.0.5
To: FreeRadius users mailing list
<freeradius-users at lists.freeradius.org>
Message-ID: <20050930150125.3446116CC1 at mail.nitros9.org>
"Rohaizam Abu Bakar" <haizam at 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 at ox.org>
Subject: Re: SSL3_GET_CLIENT_KEY_EXCHANGE
To: Juan Daniel Moreno <juanitomoreno at gmail.com>, FreeRadius users
mailing list <freeradius-users at lists.freeradius.org>
Message-ID: <20050930150244.AA91016CC1 at mail.nitros9.org>
Juan Daniel Moreno <juanitomoreno at 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 at ox.org>
Subject: Re: freeradius and MS SQL -- anyone got it working?
To: FreeRadius users mailing list
<freeradius-users at lists.freeradius.org>
Message-ID: <20050930151457.9FDB316CC1 at mail.nitros9.org>
"Duane Cox" <duanec at 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 at ox.org>
Subject: Re: Proxy of accounting message
To: FreeRadius users mailing list
<freeradius-users at lists.freeradius.org>
Message-ID: <20050930160236.1CA4116CC1 at mail.nitros9.org>
"Ashwin Gobind" <Ashwin.Gobind at 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 "
More information about the Freeradius-Users
mailing list