Must use 'Attr-26 = ...' instead of 'Vendor-Specific = ...' even when setting explicitly Attr-26 (or vendor data type)

[Francesco Di Nucci]

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 at na.infn.it

On 29/04/26 10:02, Bjørn Mork wrote:
> Bjørn Mork via Freeradius-Users <freeradius-users at lists.freeradius.org>
> writes:
>
>> Francesco Di Nucci <francesco.dinucci at 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 at 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
>