03-23-2010 12:11 AM - edited 03-10-2019 05:01 PM
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 |
Solved! Go to Solution.
03-23-2010 02:54 AM
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!
03-24-2010 03:47 AM
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!
03-23-2010 12:19 AM
Heres a screenshot of the group page..
03-23-2010 02:54 AM
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!
03-23-2010 05:46 PM
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:
03-24-2010 03:47 AM
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!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide