Must use 'Attr-26 = ...' instead of 'Vendor-Specific = ...' even when setting explicitly Attr-26 (or vendor data type)
Hi, I am using FreeRADIUS 3.0.27 on EL9, and I'm trying to set a Vendor Attribute in replies. For context, I am trying to authenticate SuperMicro BMCs with LDAP (see thread https://lists.freeradius.org/pipermail/freeradius-users/2018-March/091085.ht...) So in my enabled site I edited the post-auth section post-auth { update { reply:Attr-26 := "0x483D342C20493D34" } } This results in "Cannot parse RHS hex as the data type of the attribute Vendor-Specific" As it's missing Vendor ID, I tried to add it. Super Micro PEN on IANA is 10876, so full vendor attribute should be 1A1200002A7C483D342C20493D34 if I am correct: post-auth { update { reply:Attr-26 := "1A1200002A7C483D342C20493D34" } } And here the result is Must use 'Attr-26 = ...' instead of 'Vendor-Specific = ...' , even if I am setting reply:Attr-26 Does anyone have a suggestion? I'd like to add it to post-auth (and not to mods-enabled/ldap) to then add a conditional on NAS-Identifier = "SUPERMICRO BMC" Thanks in advance Francesco -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci@na.infn.it
On Apr 24, 2026, at 6:06 AM, Francesco Di Nucci <francesco.dinucci@na.infn.it> wrote:
I am using FreeRADIUS 3.0.27 on EL9, and I'm trying to set a Vendor Attribute in replies.
For context, I am trying to authenticate SuperMicro BMCs with LDAP (see thread https://lists.freeradius.org/pipermail/freeradius-users/2018-March/091085.ht...)
So in my enabled site I edited the post-auth section
post-auth { update { reply:Attr-26 := "0x483D342C20493D34"
That's a double quoted string. The "0x" text is part of the string.
This results in "Cannot parse RHS hex as the data type of the attribute Vendor-Specific"
Exactly it can't parse it as hex, because it's not hex. It's a double quoted string.
As it's missing Vendor ID, I tried to add it. Super Micro PEN on IANA is 10876, so full vendor attribute should be 1A1200002A7C483D342C20493D34 if I am correct:
post-auth { update { reply:Attr-26 := "1A1200002A7C483D342C20493D34"
Drop the quotes. Use: reply:Attr-26 := 0x1A1200002A7C483D342C20493D34 The server has tests for this, so it should work. Alan DeKok.
Thank you, tried and reply:Attr-26 := 0x483D342C20493D34 /without quotes/ still returns Cannot parse RHS hex as the data type of the attribute Vendor-Specific. Same for reply:Attr-26 := 0x1A1200002A7C483D342C20493D34 without quotes... Cannot parse RHS hex as the data type of the attribute Vendor-Specific What else could be wrong? Best regards Francesco -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it On 24/04/26 14:01, Alan DeKok via Freeradius-Users wrote:
On Apr 24, 2026, at 6:06 AM, Francesco Di Nucci<francesco.dinucci@na.infn.it> wrote:
I am using FreeRADIUS 3.0.27 on EL9, and I'm trying to set a Vendor Attribute in replies.
For context, I am trying to authenticate SuperMicro BMCs with LDAP (see threadhttps://lists.freeradius.org/pipermail/freeradius-users/2018-March/091085.ht...)
So in my enabled site I edited the post-auth section
post-auth { update { reply:Attr-26 := "0x483D342C20493D34" That's a double quoted string. The "0x" text is part of the string.
This results in "Cannot parse RHS hex as the data type of the attribute Vendor-Specific" Exactly it can't parse it as hex, because it's not hex. It's a double quoted string.
As it's missing Vendor ID, I tried to add it. Super Micro PEN on IANA is 10876, so full vendor attribute should be 1A1200002A7C483D342C20493D34 if I am correct:
post-auth { update { reply:Attr-26 := "1A1200002A7C483D342C20493D34" Drop the quotes. Use:
reply:Attr-26 := 0x1A1200002A7C483D342C20493D34
The server has tests for this, so it should work.
Alan DeKok.
- List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html
On Apr 24, 2026, at 8:17 AM, Francesco Di Nucci <francesco.dinucci@na.infn.it> wrote:
tried and reply:Attr-26 := 0x483D342C20493D34 /without quotes/ still returns Cannot parse RHS hex as the data type of the attribute Vendor-Specific.
Same for reply:Attr-26 := 0x1A1200002A7C483D342C20493D34 without quotes... Cannot parse RHS hex as the data type of the attribute Vendor-Specific
What else could be wrong?
I'm not sure. I'll take a look. Alan DeKok.
Additional info - I also tried the same configuration on a more recent FreeRADIUS version (3.2.7 on Debian 13 instead of 3.0.27 on EL9), the error is the same Francesco Di Nucci On 28/04/26 18:18, Alan DeKok via Freeradius-Users wrote:
On Apr 24, 2026, at 8:17 AM, Francesco Di Nucci <francesco.dinucci@na.infn.it> wrote:
tried and reply:Attr-26 := 0x483D342C20493D34 /without quotes/ still returns Cannot parse RHS hex as the data type of the attribute Vendor-Specific.
Same for reply:Attr-26 := 0x1A1200002A7C483D342C20493D34 without quotes... Cannot parse RHS hex as the data type of the attribute Vendor-Specific
What else could be wrong? I'm not sure. I'll take a look.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Francesco Di Nucci <francesco.dinucci@na.infn.it> writes:
Additional info - I also tried the same configuration on a more recent FreeRADIUS version (3.2.7 on Debian 13 instead of 3.0.27 on EL9), the error is the same
Francesco Di Nucci
On 28/04/26 18:18, Alan DeKok via Freeradius-Users wrote:
On Apr 24, 2026, at 8:17 AM, Francesco Di Nucci <francesco.dinucci@na.infn.it> wrote:
tried and reply:Attr-26 := 0x483D342C20493D34 /without quotes/ still returns Cannot parse RHS hex as the data type of the attribute Vendor-Specific.
Same for reply:Attr-26 := 0x1A1200002A7C483D342C20493D34 without quotes... Cannot parse RHS hex as the data type of the attribute Vendor-Specific
Not sure what you are trying to save by not defining a dictionary. Looks like FR insists on matching Attr-26 against the known dictionaries anyway. I did a quick test with the Debian 13 package, adding to /etc/freeradius/3.0/dictionary (you will of course add this to a spearate file when done testing): VENDOR SUPERMICRO 10876 format=1,0 BEGIN-VENDOR SUPERMICRO ATTRIBUTE Foo 72 octets END-VENDOR SUPERMICRO Only then would FR accept something like this: Attr-26 := 0x00002A7C483D342C20493D34 But it will only accept 0x48 (72) as the first byte of the value. Seems you have to define every possible first byte this way. There is no "format=0". But worst case, just create 256 dummy VSAs... Bjørn
Bjørn Mork via Freeradius-Users <freeradius-users@lists.freeradius.org> writes:
Francesco Di Nucci <francesco.dinucci@na.infn.it> writes:
Additional info - I also tried the same configuration on a more recent FreeRADIUS version (3.2.7 on Debian 13 instead of 3.0.27 on EL9), the error is the same
Francesco Di Nucci
On 28/04/26 18:18, Alan DeKok via Freeradius-Users wrote:
On Apr 24, 2026, at 8:17 AM, Francesco Di Nucci <francesco.dinucci@na.infn.it> wrote:
tried and reply:Attr-26 := 0x483D342C20493D34 /without quotes/ still returns Cannot parse RHS hex as the data type of the attribute Vendor-Specific.
Same for reply:Attr-26 := 0x1A1200002A7C483D342C20493D34 without quotes... Cannot parse RHS hex as the data type of the attribute Vendor-Specific
Not sure what you are trying to save by not defining a dictionary. Looks like FR insists on matching Attr-26 against the known dictionaries anyway.
I did a quick test with the Debian 13 package, adding to /etc/freeradius/3.0/dictionary (you will of course add this to a spearate file when done testing):
VENDOR SUPERMICRO 10876 format=1,0
BEGIN-VENDOR SUPERMICRO ATTRIBUTE Foo 72 octets END-VENDOR SUPERMICRO
Only then would FR accept something like this:
Attr-26 := 0x00002A7C483D342C20493D34
But it will only accept 0x48 (72) as the first byte of the value. Seems you have to define every possible first byte this way. There is no "format=0". But worst case, just create 256 dummy VSAs...
Forget it. FR accepts the config, but it doesn't actually work. Trying to return that attribute results in (1) ERROR: Failed sending reply: ERROR: Unknown attribute type 21 And type 21 is PW_TYPE_VSA if I'm not mistaken. Rewriting to Attr-26.10876.72 := 0x3D342C20493D34 makes it "work". But that's ugly. Anyway, with that I see these bytes returned from FR: 1a 0e 00 00 2a 7c 48 3d 34 2c 20 49 3d 34 and I guess that was what you wanted? Bjørn
Thanks
Not sure what you are trying to save by not defining a dictionary. Tbh I'm just approaching to RADIUS, so not trying to save anything, apparently didn't know the proper way for this use case :D
and I guess that was what you wanted? More or less, the server starts and answers include the custom attribute:
(0) # Executing section post-auth from file /etc/raddb/sites-enabled/default (0) post-auth { (0) update { (0) reply::Foo := 0x483d342c20493d34 (0) } # update = noop (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) { (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) -> FALSE (0) update { (0) No attributes updated for RHS &session-state: (0) } # update = noop (0) } # post-auth = noop (0) Sent Access-Accept Id 0 from XXX:1812 to XXX:59903 length 53 (0) Foo := 0x483d342c20493d34 But the BMC on the other side does not consider it as valid, so it authenticates the user but without privileges (for reference https://www.supermicro.com/en/support/faqs/faq.php?faq=22374). If I manually define the user in the users file: testing Cleartext-Password := "password" Attr-26 = 0x483D342C20493D34 the answer is different (0) # Executing section post-auth from file /etc/raddb/sites-enabled/default (0) post-auth { (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) { (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) -> FALSE (0) update { (0) No attributes updated for RHS &session-state: (0) } # update = noop (0) [exec] = noop (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else { (0) [noop] = noop (0) } # else = noop (0) } # policy remove_reply_message_if_eap = noop (0) if (EAP-Key-Name && &reply:EAP-Session-Id) { (0) if (EAP-Key-Name && &reply:EAP-Session-Id) -> FALSE (0) } # post-auth = noop (0) Sent Access-Accept Id 0 from XXX:1812 to XXX:58921 length 48 (0) Attr-26 = 0x483d342c20493d34 And the BMC authenticates the user with the correct privileges So I guess it's not exactly the same Francesco -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci@na.infn.it On 29/04/26 10:02, Bjørn Mork wrote:
Bjørn Mork via Freeradius-Users <freeradius-users@lists.freeradius.org> writes:
Francesco Di Nucci <francesco.dinucci@na.infn.it> writes:
Additional info - I also tried the same configuration on a more recent FreeRADIUS version (3.2.7 on Debian 13 instead of 3.0.27 on EL9), the error is the same
Francesco Di Nucci
On 28/04/26 18:18, Alan DeKok via Freeradius-Users wrote:
On Apr 24, 2026, at 8:17 AM, Francesco Di Nucci <francesco.dinucci@na.infn.it> wrote:
tried and reply:Attr-26 := 0x483D342C20493D34 /without quotes/ still returns Cannot parse RHS hex as the data type of the attribute Vendor-Specific.
Same for reply:Attr-26 := 0x1A1200002A7C483D342C20493D34 without quotes... Cannot parse RHS hex as the data type of the attribute Vendor-Specific
Not sure what you are trying to save by not defining a dictionary. Looks like FR insists on matching Attr-26 against the known dictionaries anyway.
I did a quick test with the Debian 13 package, adding to /etc/freeradius/3.0/dictionary (you will of course add this to a spearate file when done testing):
VENDOR SUPERMICRO 10876 format=1,0
BEGIN-VENDOR SUPERMICRO ATTRIBUTE Foo 72 octets END-VENDOR SUPERMICRO
Only then would FR accept something like this:
Attr-26 := 0x00002A7C483D342C20493D34
But it will only accept 0x48 (72) as the first byte of the value. Seems you have to define every possible first byte this way. There is no "format=0". But worst case, just create 256 dummy VSAs... Forget it. FR accepts the config, but it doesn't actually work. Trying to return that attribute results in
(1) ERROR: Failed sending reply: ERROR: Unknown attribute type 21
And type 21 is PW_TYPE_VSA if I'm not mistaken.
Rewriting to
Attr-26.10876.72 := 0x3D342C20493D34
makes it "work". But that's ugly. Anyway, with that I see these bytes returned from FR:
1a 0e 00 00 2a 7c 48 3d 34 2c 20 49 3d 34
and I guess that was what you wanted?
Bjørn
participants (3)
-
Alan DeKok -
Bjørn Mork -
Francesco Di Nucci