-----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}2d0e1fba7e14896968495d723d41a...@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-b...@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-b...@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}33ac5579ce57217426e7434fa60e4...@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:al...@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-b...@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----- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html