Solved: RDBMS vendor addition results in invalid packet

charg_in1 · ‎03-23-2010

Hello,

I have recently added a vendor specific radius AV pair via RDBMS. This resulted in 4 fields appearing under my group, which I then populated with the IP addresses of my DNS servers.

It appears that ACS is not composing the access-accept radius response resulting in it being rejeced by the peer device. Specifically, ACS appears to not be defining the specific VSA properly, resulting in the field being interpretted as being merged with the next fields.

I am trying to respond to a request from an authentication request from a Juniper E series.

Please advise if there is a fix for this.

Many Thanks,

David

SequenceId

Priority

UserName

GroupName

Action

ValueName

Value1

Value2

Value3

DateTime

MessageNo

ComputerNames

AppId

Status

1

8

350

Juniper-ERX

AUTO_ASSIGN_SLOT

4874

23/03/2010 13:00

0

2

0

355

23/03/2010 13:00

SequenceId	Priority	UserName	GroupName	Action	ValueName	Value1	Value2	Value3	DateTime	MessageNo	ComputerNames	AppId	Status
1	4			352	Juniper-ERX-Primary-DNS	4874	4	ipaddr	23/03/2010 13:00				0
2	3			352	Juniper-ERX-Secondary-DNS	4874	5	ipaddr	23/03/2010 13:00				0
3	2			352	Juniper-ERX-Primary-WINS	4874	6	ipaddr	23/03/2010 13:00				0
4	1			352	Juniper-ERX-Secondary-WINS	4874	7	ipaddr	23/03/2010 13:00				0
5	0			355					23/03/2010 13:00				0

darpotter · ‎03-23-2010

Something does look odd (I wrote most of CSRadius originally, in a different life)

The VSA bytes are

type = 1a (26 - VSA)

len = 0a (10)

vendor id = 00 00 13 0a (4874)

vsa id = 06 (ERX-Primary-WINS)

value = hidden

Looks on the face of it that the attribute len should have been 0b (11) or the last byte of the ipaddr was not included.

What comes after is odd, attr 0x15 (21) is Password-Expiration. Could this be the last byte of the VSA? After that is 0x08 which could be Framed-IP-Address. Not being able to see the full packet I cant say.

If you have the s/w ACS, you can run CSRadius -z -p at the command line to see what ACS *thinks* its sending attribute-by-attribute.

Blimey I miss de-constructing binary packets!

View solution in original post

darpotter · ‎03-24-2010

Looks to me like the attribute was encoded correctly, but the length value is one byte short. The 0x15 value is actually the last byte of the ip address, followed by 0x08 which is the start of the next Framed-IP-Address atribute.

I'd be kind of surpried if this was my bug as I wrote that over 5yrs ago and presumably someone would have complained before now.

You'll need to contact the TAC and tell them the problem is in the CSRadius function that serialises attributes just prior to sending out responses.

Good luck!

View solution in original post

charg_in1 · ‎03-23-2010

Heres a screenshot of the group page..

darpotter · ‎03-23-2010

Something does look odd (I wrote most of CSRadius originally, in a different life)

The VSA bytes are

type = 1a (26 - VSA)

len = 0a (10)

vendor id = 00 00 13 0a (4874)

vsa id = 06 (ERX-Primary-WINS)

value = hidden

Looks on the face of it that the attribute len should have been 0b (11) or the last byte of the ipaddr was not included.

What comes after is odd, attr 0x15 (21) is Password-Expiration. Could this be the last byte of the VSA? After that is 0x08 which could be Framed-IP-Address. Not being able to see the full packet I cant say.

If you have the s/w ACS, you can run CSRadius -z -p at the command line to see what ACS *thinks* its sending attribute-by-attribute.

Blimey I miss de-constructing binary packets!

charg_in1 · ‎03-23-2010

Hi Darpotter,

Its nice to hear from someone that knows ACS!!

I gave the debug a try - ACS thinks that its sending the correct response

Sending response code 2, id 44 to 144.130.4.5 on port 47802
[026] Vendor-Specific vsa id: 4874
[004] Juniper-ERX-Primary-DNS value: 10.0.0.1

[008] Framed-IP-Address value: 10.0.1.10

[025] Class value: CACS:4/5591a/90820405/2262
61352

It appears the ACS is messing up the length of the AVP, which should be 12, then the length of the VSA which should be 6. I will try upgrading to the latest version of ACS and see how that goes. I am currently running 4.2 build 128 on windows. The latest is 4.2.1 build 15.

Here is a debug from Microsoft IAS, which is working:

darpotter · ‎03-24-2010

Looks to me like the attribute was encoded correctly, but the length value is one byte short. The 0x15 value is actually the last byte of the ip address, followed by 0x08 which is the start of the next Framed-IP-Address atribute.

I'd be kind of surpried if this was my bug as I wrote that over 5yrs ago and presumably someone would have complained before now.

You'll need to contact the TAC and tell them the problem is in the CSRadius function that serialises attributes just prior to sending out responses.

Good luck!