Radius is storing the accounting information using the EAP hashed username. Is there a way to change it to store the clear text username with the accounting info? David Peterson Engineer Wireless Connections 166 Milan Ave., Norwalk, Oh. 44857 ACCessing the Future Today!! ofc. 419.660.6100 ext 2287 cell 419-706-7355 fax 419-668-4077 <http://www.wirelessconnections.net/> http://www.wirelessconnections.net This transmission and any files attached to it, may contain confidential and/or privileged information and intended only for the named recipient. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, retransmission, dissemination, disclosure, copying or any use of the information or files contained is strictly prohibited. If you have received this transmission in error, please notify the sender by reply transmission and delete this electronic mail
David Peterson wrote:
Radius is storing the accounting information using the EAP hashed username.
What's an "EAP hashed username" ?
Is there a way to change it to store the clear text username with the accounting info?
Sure. Send a User-Name attribute in the Access-Accept, and the NAS *should* send that back in the Accounting packets. Alan DeKok.
Here is a sample of the accounting information I am getting back: 1 00-12-cf-c7-4c-f21 8de274900adce6a9 =7Bam=3D1=7D20dc847805b044128ac3c4bd8ce95540@example.com example.com 172.16.4.2 2009-12-07 08:54:44 2009-12-07 08:56:43 119 RADIUS 0 0 00-12-cf-c7-4c-f2 NAS-Request 64.186.195.5 0 0 2 00-12-cf-c7-4c-f22 24acff6ce9b251c3 =7Bam=3D1=7Dd333c622e88b4bbf996e8b96c9850967@example.com example.com 172.16.4.2 2009-12-07 08:56:41 2009-12-07 09:00:08 207 RADIUS 0 0
From what I can determine, the username is encrypted even though the authentication is done in clear text during the EAP authentication.
David -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Tuesday, December 15, 2009 9:13 AM To: David Peterson-WirelessConnections; FreeRadius users mailing list Subject: Re: Accounting question David Peterson wrote:
Radius is storing the accounting information using the EAP hashed username.
What's an "EAP hashed username" ?
Is there a way to change it to store the clear text username with the accounting info?
Sure. Send a User-Name attribute in the Access-Accept, and the NAS *should* send that back in the Accounting packets. Alan DeKok.
hi, those look like chargeable user identities - do you have CUI operational on your config? alan
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.
WiMax it is... If anyone has any experience with Alvarion WiMax please feel free to chime in. David -----Original Message----- From: Alan DeKok [mailto:aland@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.
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@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? David -----Original Message----- From: Alan DeKok [mailto:aland@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.
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@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@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
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. David -----Original Message----- From: Arran Cudbard-Bell [mailto:A.Cudbard-Bell@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@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@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
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@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@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@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
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@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? David ________________________________________ From: Arran Cudbard-Bell [A.Cudbard-Bell@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@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@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@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
-----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@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@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.
David
-----Original Message----- From: Arran Cudbard-Bell [mailto:A.Cudbard-Bell@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@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@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
-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- -- Arran Cudbard-Bell <A.Cudbard-Bell@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-----
What I am not understanding at this point is how the authentication works with the username "hashed" or using "hex stuff" but the accounting doesn't. You can see on this debug that the username looks the same when its authenticated as it does when it's used for accounting yet the username in the database is clear text. rad_recv: Access-Request packet from host 172.16.4.2 port 1812, id=152, length=192 User-Name = "{am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com" EAP-Message = 0x020800061500 Message-Authenticator = 0xdf8d44589c8c07b9f6ca5d31ce4e23e6 NAS-Identifier = "WC_LAB" NAS-IP-Address = 172.16.4.2 Calling-Station-Id = "00-12-CF-C3-FB-8C" WiMAX-BS-Id = 0x000002030209 NAS-Port-Type = 27 Framed-MTU = 2000 Service-Type = Framed-User WiMAX-GMT-Timezone-offset = 0 State = 0x7b727fb77d7a6afd64224fae48c09695 Tue Dec 15 12:03:56 2009 : Info: +- entering group authorize {...} Tue Dec 15 12:03:56 2009 : Info: ++[preprocess] returns ok Tue Dec 15 12:03:56 2009 : Info: ++[chap] returns noop Tue Dec 15 12:03:56 2009 : Info: ++[mschap] returns noop Tue Dec 15 12:03:56 2009 : Info: ++[wimax] returns ok Tue Dec 15 12:03:56 2009 : Info: [suffix] Looking up realm "test.com" for User-Name = "{am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com" Tue Dec 15 12:03:56 2009 : Info: [suffix] Found realm "test.com" Tue Dec 15 12:03:56 2009 : Info: [suffix] Adding Stripped-User-Name = "{am=1}1F48C19B43C8C33846FAA9CFC58990F4" Tue Dec 15 12:03:56 2009 : Info: [suffix] Adding Realm = "test.com" Tue Dec 15 12:03:56 2009 : Info: [suffix] Authentication realm is LOCAL. Tue Dec 15 12:03:56 2009 : Info: ++[suffix] returns ok Tue Dec 15 12:03:56 2009 : Info: [eap] EAP packet type response id 8 length 6 Tue Dec 15 12:03:56 2009 : Info: [eap] Continuing tunnel setup. Tue Dec 15 12:03:56 2009 : Info: ++[eap] returns ok Tue Dec 15 12:03:56 2009 : Info: Found Auth-Type = EAP Tue Dec 15 12:03:56 2009 : Info: +- entering group authenticate {...} Tue Dec 15 12:03:56 2009 : Info: [eap] Request found, released from the list Tue Dec 15 12:03:56 2009 : Info: [eap] EAP/ttls Tue Dec 15 12:03:56 2009 : Info: [eap] processing type ttls Tue Dec 15 12:03:56 2009 : Info: [ttls] Authenticate Tue Dec 15 12:03:56 2009 : Info: [ttls] processing EAP-TLS Tue Dec 15 12:03:56 2009 : Info: [ttls] Received TLS ACK Tue Dec 15 12:03:56 2009 : Info: [ttls] ACK handshake is finished Tue Dec 15 12:03:56 2009 : Info: [ttls] eaptls_verify returned 3 Tue Dec 15 12:03:56 2009 : Info: [ttls] eaptls_process returned 3 Tue Dec 15 12:03:56 2009 : Info: [eap] Freeing handler Tue Dec 15 12:03:56 2009 : Info: ++[eap] returns ok Tue Dec 15 12:03:56 2009 : Info: +- entering group post-auth {...} Tue Dec 15 12:03:56 2009 : Info: [sql] expand: %{User-Name} -> {am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com Tue Dec 15 12:03:56 2009 : Info: [sql] sql_set_user escaped user --> '{am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com' Tue Dec 15 12:03:56 2009 : Info: [sql] expand: %{User-Password} -> Tue Dec 15 12:03:56 2009 : Info: [sql] expand: %{Chap-Password} -> Tue Dec 15 12:03:56 2009 : Info: [sql] expand: INSERT INTO radpostauth (user, pass, reply, date) VALUES ( '%{User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S') -> INSERT INTO radpostauth (user, pass, reply, date) VALUES ( '=7Bam=3D1=7D1F48C19B43C8C33846FAA9CFC58990F4@test.com', '', 'Access-Accept', '2009-12-15 12:03:56') Tue Dec 15 12:03:56 2009 : Debug: rlm_sql (sql) in sql_postauth: query is INSERT INTO radpostauth (user, pass, reply, date) VALUES ( '=7Bam=3D1=7D1F48C19B43C8C33846FAA9CFC58990F4@test.com', '', 'Access-Accept', '2009-12-15 12:03:56') Tue Dec 15 12:03:56 2009 : Debug: rlm_sql (sql): Reserving sql socket id: 4 Tue Dec 15 12:03:56 2009 : Debug: rlm_sql (sql): Released sql socket id: 4 Tue Dec 15 12:03:56 2009 : Info: ++[sql] returns ok Tue Dec 15 12:03:56 2009 : Info: [wimax] MIP-RK = 0x8bbaf6bac41676e1fea6f3a75b5ee6ef94a178d9f52f48068c9b23ccc461aa02a10b5d2bd04a0166461374ec608a81eb4969e526897ae8062732a09112962ef5 Tue Dec 15 12:03:56 2009 : Info: [wimax] MIP-SPI = e5cf883a Tue Dec 15 12:03:56 2009 : Info: [wimax] WARNING: WiMAX-MN-NAI was not found in the request or in the reply. Tue Dec 15 12:03:56 2009 : Info: [wimax] WARNING: We cannot calculate MN-HA keys. Tue Dec 15 12:03:56 2009 : Info: [wimax] WARNING: WiMAX-IP-Technology not found in reply. Tue Dec 15 12:03:56 2009 : Info: [wimax] WARNING: Not calculating MN-HA keys Tue Dec 15 12:03:56 2009 : Info: ++[wimax] returns updated Sending Access-Accept of id 152 to 172.16.4.2 port 1812 User-Name = "test@test.com" Framed-Filter-Id := "Silver" EAP-Message = 0x03080004 Message-Authenticator = 0x00000000000000000000000000000000 WiMAX-MSK = 0x737de83d5678db5bd59d21f5f254922b253974cc3aad05dd5bed123a33ba4158dfac34faae6808255f5fe931271c7590a6aef9bdda4e7d55ad1fb807d1ade735 Tue Dec 15 12:03:56 2009 : Info: Finished request 7. Tue Dec 15 12:03:56 2009 : Debug: Going to the next request Tue Dec 15 12:03:56 2009 : Debug: Waking up in 2.0 seconds. Tue Dec 15 12:03:58 2009 : Info: Cleaning up request 0 ID 145 with timestamp +63 Tue Dec 15 12:03:58 2009 : Debug: Waking up in 0.1 seconds. Tue Dec 15 12:03:58 2009 : Info: Cleaning up request 1 ID 146 with timestamp +63 Tue Dec 15 12:03:58 2009 : Debug: Waking up in 0.2 seconds. Tue Dec 15 12:03:59 2009 : Info: Cleaning up request 2 ID 147 with timestamp +63 Tue Dec 15 12:03:59 2009 : Debug: Waking up in 0.4 seconds. Tue Dec 15 12:03:59 2009 : Info: Cleaning up request 3 ID 148 with timestamp +64 Tue Dec 15 12:03:59 2009 : Debug: Waking up in 0.4 seconds. Tue Dec 15 12:03:59 2009 : Info: Cleaning up request 4 ID 149 with timestamp +64 Tue Dec 15 12:03:59 2009 : Debug: Waking up in 0.8 seconds. Tue Dec 15 12:04:00 2009 : Info: Cleaning up request 5 ID 150 with timestamp +65 Tue Dec 15 12:04:00 2009 : Debug: Waking up in 0.6 seconds. rad_recv: Accounting-Request packet from host 172.16.4.2 port 1813, id=13, length=239 Acct-Status-Type = Start WiMAX-Beginning-Of-Session = 1 WiMAX-IP-Technology = Reserved-0 Acct-Session-Id = "00-12-cf-c3-fb-8c7\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}1F48C19B43C8C33846FAA9CFC58990F4@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 12:03:50 CST" WiMAX-GMT-Timezone-offset = 21600 Acct-Authentic = RADIUS Tue Dec 15 12:04:00 2009 : Info: +- entering group preacct {...} Tue Dec 15 12:04:00 2009 : Info: ++[preprocess] returns ok Tue Dec 15 12:04:00 2009 : Info: [acct_unique] WARNING: Attribute NAS-Port was not found in request, unique ID MAY be inconsistent Tue Dec 15 12:04:00 2009 : Info: [acct_unique] Hashing ',Client-IP-Address = 172.16.4.2,NAS-IP-Address = 172.16.4.2,Acct-Session-Id = "00-12-cf-c3-fb-8c7\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",User-Name = "{am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com"' Tue Dec 15 12:04:00 2009 : Info: [acct_unique] Acct-Unique-Session-ID = "a4c0011657ec8b3b". Tue Dec 15 12:04:00 2009 : Info: ++[acct_unique] returns ok Tue Dec 15 12:04:00 2009 : Info: [suffix] Looking up realm "test.com" for User-Name = "{am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com" Tue Dec 15 12:04:00 2009 : Info: [suffix] Found realm "test.com" Tue Dec 15 12:04:00 2009 : Info: [suffix] Adding Stripped-User-Name = "{am=1}1F48C19B43C8C33846FAA9CFC58990F4" Tue Dec 15 12:04:00 2009 : Info: [suffix] Adding Realm = "test.com" Tue Dec 15 12:04:00 2009 : Info: [suffix] Accounting realm is LOCAL. Tue Dec 15 12:04:00 2009 : Info: ++[suffix] returns ok Tue Dec 15 12:04:00 2009 : Info: [files] acct_users: Matched entry DEFAULT at line 22 Tue Dec 15 12:04:00 2009 : Info: [files] WARNING: Deprecated conditional expansion ":-". See "man unlang" for details Tue Dec 15 12:04:00 2009 : Info: [files] expand: %{Stripped-User-Name:-%{User-Name}} -> {am=1}1F48C19B43C8C33846FAA9CFC58990F4 Tue Dec 15 12:04:00 2009 : Info: ++[files] returns ok Tue Dec 15 12:04:00 2009 : Info: +- entering group accounting {...} Tue Dec 15 12:04:00 2009 : Info: [detail] expand: /var/log/freeradius/radacct/%{Client-IP-Address}/detail-%Y%m%d -> /var/log/freeradius/radacct/172.16.4.2/detail-20091215 Tue Dec 15 12:04:00 2009 : Info: [detail] /var/log/freeradius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/freeradius/radacct/172.16.4.2/detail-20091215 Tue Dec 15 12:04:00 2009 : Info: [detail] expand: %t -> Tue Dec 15 12:04:00 2009 Tue Dec 15 12:04:00 2009 : Info: ++[detail] returns ok Tue Dec 15 12:04:00 2009 : Info: [radutmp] expand: /var/log/freeradius/radutmp -> /var/log/freeradius/radutmp Tue Dec 15 12:04:00 2009 : Info: [radutmp] expand: %{User-Name} -> {am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com Tue Dec 15 12:04:00 2009 : Debug: rlm_radutmp: No NAS-Port seen. Cannot do anything. Tue Dec 15 12:04:00 2009 : Debug: rlm_radumtp: WARNING: checkrad will probably not work! Tue Dec 15 12:04:00 2009 : Info: ++[radutmp] returns noop Tue Dec 15 12:04:00 2009 : Info: [sql] expand: %{User-Name} -> {am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com Tue Dec 15 12:04:00 2009 : Info: [sql] sql_set_user escaped user --> '{am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com' Tue Dec 15 12:04:00 2009 : Info: [sql] expand: %{Acct-Delay-Time} -> Tue Dec 15 12:04:00 2009 : Info: [sql] expand: INSERT INTO radacct (acctsessionid, acctuniqueid, username, realm, nasipaddress, nasportid, nasporttype, acctstarttime, acctstoptime, acctsessiontime, acctauthentic, connectinfo_start, connectinfo_stop, acctinputoctets, acctoutputoctets, calledstationid, callingstationid, acctterminatecause, servicetype, framedprotocol, framedipaddress, acctstartdelay, acctstopdelay, xascendsessionsvrkey) VALUES ('%{Acct-Session-Id}', '%{Acct-Unique-Session-Id}', '%{SQL-User-Name}', '%{Realm}', '%{NAS-IP-Address}', '%{NAS-Port}', '%{NAS-Port-Type}', '%S', NULL, '0', '%{Acct-Authentic}', '%{Connect-Info}', '', '0', '0', '%{Called-Station-Id}', '%{Calling-Station-Id}', '', '%{Service-Type}', '%{Framed-Protocol}', '%{Framed-IP-Address}', Tue Dec 15 12:04:00 2009 : Debug: rlm_sql (sql): Reserving sql socket id: 3 Tue Dec 15 12:04:00 2009 : Debug: rlm_sql_mysql: MYSQL check_error: 1048 received Tue Dec 15 12:04:00 2009 : Error: [sql] Couldn't insert SQL accounting START record - Column 'AcctStopTime' cannot be null Tue Dec 15 12:04:00 2009 : Info: [sql] expand: %{Acct-Delay-Time} -> Tue Dec 15 12:04:00 2009 : Info: [sql] expand: UPDATE radacct SET acctstarttime = '%S', acctstartdelay = '%{%{Acct-Delay-Time}:-0}', connectinfo_start = '%{Connect-Info}' WHERE acctsessionid = '%{Acct-Session-Id}' AND username = '%{SQL-User-Name}' AND nasipaddress = '%{NAS-IP-Address}' -> UPDATE radacct SET acctstarttime = '2009-12-15 12:04:00', acctstartdelay = '0', connectinfo_start = '' WHERE acctsessionid = '00-12-cf-c3-fb-8c7' AND username = '=7Bam=3D1=7D1F48C19B43C8C33846FAA9CFC58990F4@test.com' AND nasipaddress = '172.16.4.2' Tue Dec 15 12:04:00 2009 : Debug: rlm_sql (sql): Released sql socket id: 3 Tue Dec 15 12:04:00 2009 : Info: ++[sql] returns ok Tue Dec 15 12:04:00 2009 : Info: [attr_filter.accounting_response] expand: %{User-Name} -> {am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com -----Original Message----- From: Arran Cudbard-Bell [mailto:A.Cudbard-Bell@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@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@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
On Tue, Dec 15, 2009 at 01:10:20PM -0500, David Peterson wrote:
What I am not understanding at this point is how the authentication works with the username "hashed" or using "hex stuff" but the accounting doesn't. You can see on this debug that the username looks the same when its authenticated as it does when it's used for accounting yet the username in the database is clear text.
rad_recv: Access-Request packet from host 172.16.4.2 port 1812, id=152, length=192 User-Name = "{am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com" Tue Dec 15 12:03:56 2009 : Info: [sql] sql_set_user escaped user --> '{am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com' Tue Dec 15 12:03:56 2009 : Info: [wimax] WARNING: Not calculating MN-HA keys Tue Dec 15 12:03:56 2009 : Info: ++[wimax] returns updated Sending Access-Accept of id 152 to 172.16.4.2 port 1812 User-Name = "test@test.com" Tue Dec 15 12:03:56 2009 : Info: Finished request 7.
Looks like you get the clear User-Name only after you run the 'wimax' module. Run it earlier?
rad_recv: Accounting-Request packet from host 172.16.4.2 port 1813, id=13, length=239 User-Name = "{am=1}1F48C19B43C8C33846FAA9CFC58990F4@test.com"
It doesn't look like you run the 'wimax' module during the processing of accounting packets. Run it? :) -- 2. That which causes joy or happiness.
David Peterson wrote:
What I am not understanding at this point is how the authentication works with the username "hashed" or using "hex stuff" but the accounting doesn't. You can see on this debug that the username looks the same when its authenticated as it does when it's used for accounting yet the username in the database is clear text.
Because it's using TTLS, and there is *another* name inside of the TLS tunnel. This *should* be clear from the debug output. Read it. *All*. Once you have the inner User-Name, you can write both it, and the outer "hex" stuff to a table for later correlation. You were told this. Now stop trying to understand the problem. Find the "good" User-Name, and then write it and the "hex" version to an SQL table. Use that table to "fix" the accounting records. *Nothing* else will solve the problem. You're stuck on "oh my god, the user name is hex". Get over it. Ignore the hex nonsense, and go fix the problem. Alan DeKok.
I added that attribute in the access-accept and I see it going to the NAS. However the NAS still returns accounting information with the =7Bam=3D1=7Dd333c622e88b4bbf996e8b96c9850967@example.com format. David -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Tuesday, December 15, 2009 9:13 AM To: David Peterson-WirelessConnections; FreeRadius users mailing list Subject: Re: Accounting question David Peterson wrote:
Radius is storing the accounting information using the EAP hashed username.
What's an "EAP hashed username" ?
Is there a way to change it to store the clear text username with the accounting info?
Sure. Send a User-Name attribute in the Access-Accept, and the NAS *should* send that back in the Accounting packets. Alan DeKok.
participants (6)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
David Peterson -
David Peterson -
Josip Rodin