Accounting question
Arran Cudbard-Bell
A.Cudbard-Bell at sussex.ac.uk
Thu Dec 17 17:41:14 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 16/12/2009 19:21, David Peterson wrote:
> OK I added the reply update and see the acknowledgement go out:
>
> Sending Access-Accept of id 8 to 172.16.4.2 port 1812
> Service-Type = Framed-User
> User-Name = "testtest"
> Framed-Filter-Id = "Bronze"
> Class = 0x7465737474657374
> EAP-Message = 0x03080004
> Message-Authenticator = 0x00000000000000000000000000000000
> WiMAX-IP-Technology = CMIP4
> WiMAX-hHA-IP-MIP4 = 192.168.10.3
> WiMAX-MSK = 0x686ea51099d982afffe6d3555b34d6a9ae889284f3e2db6eeab05848838fd290d00925dd068d797a09eb3b4d17b5a90ad00ab5291ce7ba9a519440b480bb3943
> WiMAX-MN-hHA-MIP4-Key = 0x4e96fdcb6522057bfefbe762e274dbc33640f2ff
> WiMAX-MN-hHA-MIP4-SPI = 1824920104
>
> However the NAS is overrriding the username and replying with:
>
> rad_recv: Accounting-Request packet from host 172.16.4.2 port 1813, id=31, length=262
> Acct-Status-Type = Start
> WiMAX-Beginning-Of-Session = 1
> Class = 0x7465737474657374
> WiMAX-IP-Technology = Reserved-0
> Acct-Session-Id = "00-12-cf-c3-fb-8c16\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
> Framed-IP-Address = 64.186.195.5
> User-Name = "{am=1}2D0E1FBA7E14896968495D723D41AC48 at test.com"
> Calling-Station-Id = "00-12-cf-c3-fb-8c"
> NAS-Identifier = "WC_LAB"
> WiMAX-hHA-IP-MIP4 = 192.168.10.3
> NAS-IP-Address = 172.16.4.2
> WiMAX-BS-Id = 0x000002030209
> Framed-Pool = "alias"
> Event-Timestamp = "Dec 16 2009 13:15:14 CST"
> WiMAX-GMT-Timezone-offset = 21600
> Acct-Authentic = RADIUS
>
> Any other thoughts?
Great! It includes a Class attribute in the response.
You have two options, the easy and bad way of doing things, or the harder but correct way.
bad - edit the definition for the Class attribute in freeradius/share/dictionary/dictionary.rfc2865 so FreeRADIUS treats it as a string:
ATTRIBUTE Class 25 string
Then add the following into post-auth:
update reply {
Class := "%{request:User-Name}"
}
And the following into pre-acct:
if(Class){
update request
User-Name := "%{request:Class}"
}
}
good -
1. Update the schema for the radpostauth table to include a 32byte field (called authsessionid?) with a unique index to record the value of the class attribute in the Access-Accept.
2. Update the postauth insert statement to record the value of %{reply:Class} (it's in raddb/sql/<server type>/<conf file>.
3. Insert the following into authorize
update reply {
Class := "%{md5:%{Client-IP-Address}%{NAS-IP-Address}%{%{NAS-Port-ID}:-%{NAS-Port}}%{Calling-Station-ID}%{reply:User-Name}%t}"
}
4. Insert the following into pre-acct
if(Class){
update request {
Tmp-String-0 := "%{sql:SELECT `username` FROM `radpostauth` WHERE `authsessionid` = %{request:Class} LIMIT 1}"
}
if(Tmp-String-0){
update request {
User-Name := "%{request:Tmp-String-0}"
}
}
}
The good option is also nice as it allows you to link postauth and accounting records in a more general way, and you can still treat Class as opaque binary data.
Hope this helps.
- -Arran
> ________________________________________
> From: Arran Cudbard-Bell [A.Cudbard-Bell at sussex.ac.uk]
> Sent: Tuesday, December 15, 2009 5:32 PM
> To: David Peterson-WirelessConnections; FreeRadius users mailing list
> Subject: Re: Accounting question
>
> David Peterson wrote:
>> Forgive my newbieness but where would I put that code? I tried adding it to the sites-available/default file under accounting but I am guessing that's not right.
>
> That'll stop any potential problems arising from the malformed Acct-Session-ID yes.
>
> Regarding the username, try putting the following in postauth.
>
> update reply {
> User-Name := 'testtest'
> Class := 'testtest'
> }
>
> See if either of those values are included in accounting sessions. If they are then there are ways to work around the User-Name in accounting packets.
>
> -Arran
>> David
>>
>> -----Original Message-----
>> From: Arran Cudbard-Bell [mailto:A.Cudbard-Bell at sussex.ac.uk]
>> Sent: Tuesday, December 15, 2009 10:56 AM
>> To: David Peterson-WirelessConnections; FreeRadius users mailing list
>> Subject: Re: Accounting question
>>
>> David Peterson wrote:
>>> Here is the accounting packet information I am getting:
>>> rad_recv: Accounting-Request packet from host 172.16.4.2 port 1813, id=5,
>>> length=239
>>> Acct-Status-Type = Start
>>> WiMAX-Beginning-Of-Session = 1
>>> WiMAX-IP-Technology = Reserved-0
>>> Acct-Session-Id =
>>> "00-12-cf-c3-fb-8c3\000\000\000\000\000\000\000\000\000\000\000\000\000\000\
>>> 000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
>>> Framed-IP-Address = 64.186.195.5
>>> User-Name = "{am=1}33AC5579CE57217426E7434FA60E4E65 at test.com"
>>> Calling-Station-Id = "00-12-cf-c3-fb-8c"
>>> NAS-Identifier = "WC_LAB"
>>> NAS-IP-Address = 172.16.4.2
>>> WiMAX-BS-Id = 0x000002030209
>>> Framed-Pool = "alias"
>>> Event-Timestamp = "Dec 15 2009 09:04:15 CST"
>>> WiMAX-GMT-Timezone-offset = 21600
>>> Acct-Authentic = RADIUS
>>>
>>> What I don't get is why the authentication works with clear text and the
>>> accounting has the "hex stuff". Is this pretty much controlled by the NAS?
>>
>> The "hex stuff" is the NAS appending 31 null chars to the session id.
>> FreeRADIUS is converting the unprintable characters into escape codes so that they're visible.
>>
>> The RFC recommendation is that:
>>
>> "The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] characters."
>>
>> Which SHOULD limit it to printable chars.
>>
>> Really this is something your NAS vendor should fix, as it's a bug in their code.
>>
>> ...Though if you really want you can trim off the superfluous nulls with:
>>
>> if(Acct-Session-ID =~ /(.*)/){
>> update request {
>> Acct-Session-ID := "%{1}"
>> }
>> }
>>
>>
>> -Arran
>>
>>
>>> David
>>>
>>> -----Original Message-----
>>> From: Alan DeKok [mailto:aland at deployingradius.com]
>>> Sent: Tuesday, December 15, 2009 9:44 AM
>>> To: David Peterson-WirelessConnections; FreeRadius users mailing list
>>> Subject: Re: Accounting question
>>>
>>> David Peterson wrote:
>>>> From what I can determine, the username is encrypted even though the
>>>> authentication is done in clear text during the EAP authentication.
>>> It's not "encrypted". My guess is that you are using WiMAX.
>>>
>>> As always, run the server in debugging mode to see what's going on.
>>>
>>> But if the NAS refuses to send a usable User-Name in an accounting
>>> packet, your only solution is to somehow write the *real* User-Name &&
>>> the hex stuff into an SQL table. Then, correlated them later when you
>>> receive the accounting packet.
>>>
>>> Alan DeKok.
>>>
>>> -
>>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>>
>>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- --
Arran Cudbard-Bell <A.Cudbard-Bell at sussex.ac.uk>,
Systems Administrator (AAA),
Infrastructure Services (IT Services),
E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT
DDI+FAX: +44 1273 873900 | INT: 3900
GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksqXyoACgkQcaklux5oVKJDVwCePIcFufQyaAtNV2m3yVgFkODo
418An19QnDKL8CuCiGjkFHeDik5VoLms
=Tp0P
-----END PGP SIGNATURE-----
More information about the Freeradius-Users
mailing list