Vsa lookup failure

[bwlang]

Sorry about the poor git practice here... didn't know i should have rebased instead of merging until now... and I'm out of time figure out how to fix things. Hopefully this is still of some help to the project.

I was bitten by this bug in production code for some users authenticating against and MS AD radius server.

[dguerri]

Hi bwlang, could you please articulate on this pull request? Shouldn't the attribute be found only in the VS dictionary if its type is 26 (VSA)?

[bwlang]

Hi David:

Sure... The only relevant commit is afdfdcf

I observed for some users that a type 26 would come back from the server, but the vendor_id reported would not be found in @dict. Then i found that the value could not be found by its id so a nil.name was attempted.

These changes allow authentication to proceed in my environment.

I'm not sure this is the cleanest solution, so maybe the vsa path should just check for 26 and look for a vendor,but return if it can't find it in the dict (and give up on the fallback which may never work)

Brad On Apr 25, 2012, at 7:02 AM, Davide Guerri wrote:

Hi bwlang, could you please articulate on this pull request? Shouldn't the attribute be found only in the VS dictionary if its type is 26 (VSA)?

---

Reply to this email directly or view it on GitHub: https://github.com/pjdavis/radiustar/pull/10#issuecomment-5328663

[dguerri]

Thanks for the explanation Brad, personally I'd prefer the latter approach :-) However the last word is up to maintainer.

It could be interesting to see if this is another Microsoft "standard" interpretation ;)

[erik-megarad]

This is also a problem for us. If attribute resolution fails by Vendor ID it should fail altogether, and not attempt to resolve by attribute ID. Personally I would prefer to simply omit the code at https://github.com/pjdavis/radiustar/blob/master/lib/radiustar/packet.rb#L165 altogether.