RDBMS vendor addition results in invalid packet

Answered Question
Mar 23rd, 2010
User Badges:

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



SequenceIdPriorityUserNameGroupNameActionValueNameValue1Value2Value3DateTimeMessageNoComputerNamesAppIdStatus
18350Juniper-ERXAUTO_ASSIGN_SLOT487423/03/2010 13:000
2035523/03/2010 13:00



SequenceIdPriorityUserNameGroupNameActionValueNameValue1Value2Value3DateTimeMessageNoComputerNamesAppIdStatus
14352Juniper-ERX-Primary-DNS48744ipaddr23/03/2010 13:000
23352Juniper-ERX-Secondary-DNS48745ipaddr23/03/2010 13:000
32352Juniper-ERX-Primary-WINS48746ipaddr23/03/2010 13:000
41352Juniper-ERX-Secondary-WINS48747ipaddr23/03/2010 13:000
5035523/03/2010 13:000



vendor attribute.JPG

Correct Answer by darpotter about 7 years 2 months ago

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!

Correct Answer by darpotter about 7 years 2 months ago

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
darpotter Tue, 03/23/2010 - 02:54
User Badges:
  • Silver, 250 points or more

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 Tue, 03/23/2010 - 17:46
User Badges:

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:

Correct Answer
darpotter Wed, 03/24/2010 - 03:47
User Badges:
  • Silver, 250 points or more

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!

Actions

This Discussion

Related Content