4

I'm struggling to use a Windows-based RADIUS setup (Network Policy Server) with SuperMicro IPMI interfaces.

I've found that I need to add vendor-specific attribute H=4, I=4 (Appendix C in the SuperMicro IPMI manual), but I'm not sure about some of the settings needed to configure the NPS policy:

enter image description here

I think I'm missing the either the Vendor Code or the vendor-assigned attribute number, which both should be a numerical value. The attribute value itself is the H=4, I=4 string.

HopelessN00b
  • 54,273
Joep Piscaer
  • 41

3 Answers3

2

I found this article looking for advice on how to configure this in NPS. I was able to figure this out, no thanks to SuperMicro support:

Service-Type: Login
Vendor Specific Attribute > Add
Vendor Code: 10876
Yes. It Conforms >
Vendor-assigned attribute number: 1
Attribute format: string
Attribute value: H=4, I=4

Justin Redenbach
  • 21
  • 2
1

the answer from Justin Redenbach helped me to resolve this issue. We use FortiAuthenticator as the RADIUS Server. I've created a new dictionary for the IPMI and imported it as a file:

VENDOR  IPMI    10876
BEGIN-VENDOR    IPMI
ATTRIBUTE   Permissions 1   string  BOTH
END-VENDOR  IPMI

Then I configured the user to have the attribute values H=4, I=4.

user config in FortiAuthenticator

With this configuration it worked like a charm

Theoretically it should also be possible to add the attribute values directly into the dictionary but for some reason it didn't work. The dictionary should look something like that:

VENDOR  IPMI    10876
BEGIN-VENDOR    IPMI
ATTRIBUTE   Permissions 1   string  BOTH
VALUE   UserPermissions H=4, I=4    1
END-VENDOR  IPMI

I didn't investigate further this problem as adding the values directly to the user worked for me

brunofernandez
  • 11
  • 1
0

Even with vendor ID 0 I doubt it'd work, as it's going to stick 0x00000000 in front of the string value... unless that "It does not conform" option allows you to specify a raw value for attribute 26.

Supermicro have used a non-standard, non-rfc-compliant encoding scheme for their authorization attribute.

If you look at the format of Vendor-Specific 

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Length       |            Vendor-Id
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor-Id (cont)           |  String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

There's meant to be a 32bit PEN at the start of the attribute. But they've just inserted a string value there.

The only way you could get this working (If the "It does not conform" option doesn't help) would to be use another RADIUS server as a gateway, translating an RFC attribute like Service-Type to the malformed Supermicro attribute.

FreeRADIUS and radiator could likely be configured to do this.

FreeRADIUS >= 3.0.0 has explicit provisions for dealing with malformed attributes. They get marked up as unknown octet types when received from an external server, so they can be passed through when proxying.

You can also create them in the configuration using the attribute OID syntax (Attr-<TLV/OID string>).

In this case you want Attr-26 for a raw vendor type VSA. You then need one of a few magic string values:

  • Callback "H=1, I=1" - Attr-26 = 0x483D312C20493D31
  • User "H=2, I=2" - Attr-26 = 0x483D322C20493D32
  • Operator "H=3, I=3" - Attr-26 = 0x483D332C20493D33
  • Administrator "H=4, I=4" - Attr-26 = 0x483D342C20493D34
Arran Cudbard-Bell
  • 1,659