vendor-specific problem in 3.0.4 vs. 2.1.12
Hi, I'm trying to get super-micro's IPMI to work with freeradius. Their latest docs say to use freeradius 2.1.12, and it does work. Using this in the users file: "radius_admin" Cleartext-Password := "123456" Vendor-Specific = "H=4, I=4" I get the following results: Found Auth-Type = PAP # Executing group from file /usr/local/etc/raddb/sites-enabled/default +- entering group PAP {...} [pap] login attempt with password "123456" [pap] Using clear text password "123456" [pap] User authenticated successfully ++[pap] returns ok # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 0 to 10.50.30.51 port 43540 Vendor-Specific = 0x483d342c20493d34 Finished request 0. But when I try using freeradius 3.0.4 with the same radius-admin user, I get this result: (0) Sending Access-Accept packet to host 10.50.30.51 port 38957, id=0, length=0 (0) Vendor-Specific = UNKNOWN-TYPE Sending Access-Accept Id 0 from 10.10.30.32:1812 <http://10.10.30.32:1812> to 10.50.30.51:38957 <http://10.50.30.51:38957> Vendor-Specific = UNKNOWN-TYPE (0) ERROR: Failed sending reply: ERROR: Unknown attribute type 21 (0) Finished request So, I'm not sure how version 3 differs from version 2.1.12 in handling of the Vendor-specific attributes, but is there a way to make this work in version 3 / something I need to tweak? Rob
On Oct 8, 2015, at 9:44 AM, Rob McKennon <rmckennon@monetra.com> wrote:
I'm trying to get super-micro's IPMI to work with freeradius. Their latest docs say to use freeradius 2.1.12, and it does work.
Using this in the users file:
"radius_admin" Cleartext-Password := "123456" Vendor-Specific = "H=4, I=4"
Uh... that's wrong. That's not just wrong, it's stupid, broken, and violates the RFCs.
But when I try using freeradius 3.0.4 with the same radius-admin user, I get this result:
Use 3.0.10, which was released this week. You can do (sort of) the same thing. But instead of "Vendor-Specific", you'll need to use: Attr-26 = 0xabcdef or whatever hex string corresponds to "H=4, I=4"
So, I'm not sure how version 3 differs from version 2.1.12 in handling of the Vendor-specific attributes, but is there a way to make this work in version 3 / something I need to tweak?
Version 3 deals with malformed attributes much better than 2.1.12. The price of that is that a bare "Vendor-Specific" is considered to be malformed. Tell Super Micro that their products are broken and wrong. That they should update the products to follow the RFCs. See RFC 6158, Section 2.2 among others. Tell Super Micro that the guy who wrote the specs told them they're wrong. And that they're causing pain for all of their customers. Alan DeKok.
Thank you Alan! I will forward this along to them. Rob. On 10/08/2015 10:02 AM, Alan DeKok wrote:
On Oct 8, 2015, at 9:44 AM, Rob McKennon <rmckennon@monetra.com> wrote:
I'm trying to get super-micro's IPMI to work with freeradius. Their latest docs say to use freeradius 2.1.12, and it does work.
Using this in the users file:
"radius_admin" Cleartext-Password := "123456" Vendor-Specific = "H=4, I=4" Uh... that's wrong. That's not just wrong, it's stupid, broken, and violates the RFCs.
But when I try using freeradius 3.0.4 with the same radius-admin user, I get this result: Use 3.0.10, which was released this week. You can do (sort of) the same thing. But instead of "Vendor-Specific", you'll need to use:
Attr-26 = 0xabcdef
or whatever hex string corresponds to "H=4, I=4"
So, I'm not sure how version 3 differs from version 2.1.12 in handling of the Vendor-specific attributes, but is there a way to make this work in version 3 / something I need to tweak? Version 3 deals with malformed attributes much better than 2.1.12. The price of that is that a bare "Vendor-Specific" is considered to be malformed.
Tell Super Micro that their products are broken and wrong. That they should update the products to follow the RFCs. See RFC 6158, Section 2.2 among others.
Tell Super Micro that the guy who wrote the specs told them they're wrong. And that they're causing pain for all of their customers.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Rob McKennon