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.
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.
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!