Bjørn Mork <bjorn@mork.no> writes:

"Michael A Carpenter - macarpen@us.ibm.com" <macarpen@us.ibm.com> writes:

...

I'm trying to return the Vendor-Specific attribute with value "H=4,I=4" using the rlm_rest module. I've tried the following authorization response payloads:

{"Attr-26": "0x483d342c493d34"}

{"Vendor-Specific": "H=4,I=4"}

Both resulted in error:

(0) aaa-api: Processing response header (0) aaa-api: Status : 200 (OK) (0) aaa-api: Type : json (application/json) (0) aaa-api: Parsing attribute "Attr-26" (0) aaa-api: EXPAND 0x483d342c493d34 (0) aaa-api: --> 0x483d342c493d34 (0) aaa-api: WARNING: Incompatible value assignment for attribute "Vendor-Specific", skipping...

(1) aaa-api: Processing response header (1) aaa-api: Status : 200 (OK) (1) aaa-api: Type : json (application/json) (1) aaa-api: Parsing attribute "Vendor-Specific" (1) aaa-api: EXPAND H=4,I=4 (1) aaa-api: --> H=4,I=4 (1) aaa-api: WARNING: Incompatible value assignment for attribute "Vendor-Specific", skipping...

Any suggestions for what might be incompatible about the value?

It must be prefixed with a type, length and enterprise number. See https://tools.ietf.org/html/rfc2865#section-5.26

Sorry, that's wrong. It should be enterprise number, vendor type, vendor length. Bjørn

On May 7, 2020, at 2:45 PM, Alan DeKok <aland@deployingradius.com<mailto:aland@deployingradius.com>> wrote: On May 7, 2020, at 2:17 PM, Michael A Carpenter - macarpen@us.ibm.com<mailto:macarpen@us.ibm.com> <macarpen@us.ibm.com<mailto:macarpen@us.ibm.com>> wrote: I'm trying to return the Vendor-Specific attribute with value "H=4,I=4" using the rlm_rest module. I've tried the following authorization response payloads: {"Attr-26": "0x483d342c493d34"} {"Vendor-Specific": "H=4,I=4"} Both resulted in error: Please don't do that. It's terrible. If you need that in order to interoperate with an idiot vendor, fine. But if you're doing something yourself, this is 1000% the wrong thing to do. The former, vendor is SuperMicro You *cannot* and *should not* specify values for the Vendor-Specific attribute. That attribute does not have values like other attributes. Instead, it carries a 32-bit vendor number, followed by encapsulated vendor attributes. So... why are you doing this? I arrived at those values based on http://lists.freeradius.org/pipermail/freeradius-users/2017-November/089770.... and https://www.supermicro.com/support/faqs/faq.cfm?faq=22374 Any suggestions for what might be incompatible about the value? It fails to follow the RFCs. See https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc... Which defines the "vsa" data type, for the Vendor-Specific attribute. As the author of that specification, I feel uniquely qualified to say that your usage of Vendor-Specific is wrong. :) No argument here :)

Which version are you running? # radiusd -v radiusd: FreeRADIUS Version 3.0.20, for host x86_64-alpine-linux-musl, built on Apr 20 2020 at 16:30:06

Hmm... are you sure you didn't add 'Attr-26' to the dictionaries? Because from my reading of the rlm_rest code, it calls:

Dictionaries are all at defaults / # grep Attr-26 /usr/share/freeradius/dictionary* /etc/raddb/dictionary / #

OK. I'll have to take a deeper look into it. I think it can be fixed without too much effort. I just don't want to break anything else.

I spent some time trying to find workarounds, and it looks hard. :( The "users" file allows "Attr-26 := 0x...". But the "unlang" parser doesn't allow that. The reasons are esoteric and a bit hard to fix.

Thanks for taking a look. Would you prefer I created a GitHub issue to track it?

On 07/05/2020 23:21, Alan DeKok wrote:

On May 7, 2020, at 6:15 PM, Michael A Carpenter - macarpen@us.ibm.com <macarpen@us.ibm.com> wrote:

...

Thanks for taking a look. Would you prefer I created a GitHub issue to track it?

Yeah, that's good. Thanks.

The good news is that v4 supports this, at least in "unlang". I don't think it's supported in rlm_rest, tho.

Completely hideous, but this works: users: DEFAULT Attr-26 := "%{Tmp-String-1}", Fall-Through := Yes bob Cleartext-Password := "test" sites-enabled/default: authorize { ... update request { &Tmp-String-1 := "H=4,I=4" } files ... } $ radtest bob test 127.0.0.1 0 testing123 Sent Access-Request Id 170 from 0.0.0.0:53229 to 127.0.0.1:1812 length 73 User-Name = "bob" User-Password = "test" ... Received Access-Accept Id 170 from 127.0.0.1:1812 to 127.0.0.1:53229 length 29 Attr-26 = 0x483d342c493d34 $ $ echo "483d342c493d34" | xxd -r -ps H=4,I=4 -- Matthew

Alan DeKok <aland@deployingradius.com> writes:

On May 7, 2020, at 4:42 PM, Michael A Carpenter - macarpen@us.ibm.com <macarpen@us.ibm.com> wrote:

...

The former, vendor is SuperMicro .. I arrived at those values based on http://lists.freeradius.org/pipermail/freeradius-users/2017-November/089770.... and https://www.supermicro.com/support/faqs/faq.cfm?faq=22374

Arg. I hate this kind of nonsense. It's not like the specs have been *perfectly clear* since 1996 or so. :(

One might consider nonsense docs a feature when it comes to IPMI :) The faq should probably link to this video instead: https://www.youtube.com/watch?v=GZeUntdObCA It goes into far more details on IPMI user-authentication than the SuperMicro manual, so it is almost on-topic here. And it will probably make you reconsider whether RADIUS authentication is worth it at all in this case. There is also a nice transcript at https://lwn.net/Articles/630778/ But I recommend spending the time to view Matthew's presentation. With some popcorn. He is really entertaining, as usual. Bjørn