(FreeRADIUS 3.0.13 under CentOS) I am trying to deal with a broken device (Aten) which requires an unstructured attribute 26 [^1]. Using the 'files' module this works [^2]: bob Cleartext-Password := "hello" # Vendor-Specific = "su/administrator" Attr-26 = 0x73752f61646d696e6973747261746f72 But in unlang, this is not accepted: update reply { # Vendor-Specific = "su/administrator" &Attr-26 = 0x73752f61646d696e6973747261746f72 } Tue Mar 28 14:01:27 2017 : Error: /etc/raddb/policy.d/localpolicy[155]: Invalid vendor name in attribute name "0x73752f61646d696e6973747261746f72" Here's the only bit of source I can find which generates that error message: if (strncasecmp(p, "Attr-", 5) != 0) { if (strncasecmp(p, "Vendor-", 7) == 0) { ... /* must be vendor name */ } else { char buffer[256]; q = strchr(p, '-'); if (!q) { fr_strerror_printf("Invalid vendor name in attribute name \"%s\"", name); return -1; } I don't understand why it thinks the attribute *name* is "0x73752f61"... rather than "Attr-26" And if I try this: update reply { &Attr-26 = "su/administrator" } Tue Mar 28 14:25:56 2017 : Error: /etc/raddb/policy.d/localpolicy[154]: Must use 'Attr-26 = ...' instead of 'Vendor-Specific = ...' That's an even stranger error: I *am* using Attr-26 like it says!! Any suggestions how I can get this to work, other than switching from unlang to files module? Thanks, Brian. [^1] It is so broken that it doesn't even use a vendor ID in the first four bytes. But I am happy to define a fake vendor which has the correct four bytes. And RFC 2865 *does* permit unstructured data after the 4 bytes of vendor ID. [^2] tcpdump confirms it's as expected: 0x0050: .... 1a12 7375 2f61 646d 696e 6973 7472 ....su/administr 0x0060: 6174 6f72 ator
On Mar 28, 2017, at 10:47 AM, Brian Candler <b.candler@pobox.com> wrote:
(FreeRADIUS 3.0.13 under CentOS)
I am trying to deal with a broken device (Aten) which requires an unstructured attribute 26 [^1].
They deserve to be shamed. There is just no excuse for this kind of stupidity.
Tue Mar 28 14:01:27 2017 : Error: /etc/raddb/policy.d/localpolicy[155]: Invalid vendor name in attribute name "0x73752f61646d696e6973747261746f72"\
That's... bizarre. I've tracked it down and pushed a fix to the error message. But the underlying issue is still the same. The LHS is being converted from Attr-26 to Vendor-Specific, and then tries to parse the RHS as a VSA... which doesn't work. We've put some time into fixing this in v4: https://github.com/FreeRADIUS/freeradius-server/issues/1883
And if I try this:
update reply { &Attr-26 = "su/administrator" }
Tue Mar 28 14:25:56 2017 : Error: /etc/raddb/policy.d/localpolicy[154]: Must use 'Attr-26 = ...' instead of 'Vendor-Specific = ...'
That's an even stranger error: I *am* using Attr-26 like it says!!
That's due to the auto-conversion again. I'll take a look...
Any suggestions how I can get this to work, other than switching from unlang to files module?
Use the files module for now. The unlang fixes may take a day or so. Alan DeKok.
Alan DeKok <aland@deployingradius.com> writes:
On Mar 28, 2017, at 10:47 AM, Brian Candler <b.candler@pobox.com> wrote:
(FreeRADIUS 3.0.13 under CentOS)
I am trying to deal with a broken device (Aten) which requires an unstructured attribute 26 [^1].
They deserve to be shamed. There is just no excuse for this kind of stupidity.
Yes, you should worry a bit about the part of their radius client implementation you don't see... Wonder how secure the code is if they cannot even get the basic stuff right? Power off and return seems like the best option.
Tue Mar 28 14:01:27 2017 : Error: /etc/raddb/policy.d/localpolicy[155]: Invalid vendor name in attribute name "0x73752f61646d696e6973747261746f72"\
That's... bizarre. I've tracked it down and pushed a fix to the error message.
But the underlying issue is still the same. The LHS is being converted from Attr-26 to Vendor-Specific, and then tries to parse the RHS as a VSA... which doesn't work.
We've put some time into fixing this in v4:
https://github.com/FreeRADIUS/freeradius-server/issues/1883
And if I try this:
update reply { &Attr-26 = "su/administrator" }
Tue Mar 28 14:25:56 2017 : Error: /etc/raddb/policy.d/localpolicy[154]: Must use 'Attr-26 = ...' instead of 'Vendor-Specific = ...'
That's an even stranger error: I *am* using Attr-26 like it says!!
That's due to the auto-conversion again. I'll take a look...
Any suggestions how I can get this to work, other than switching from unlang to files module?
Use the files module for now. The unlang fixes may take a day or so.
Another hackish workaround is to define your own "26" attribute in the dictionary. Just tried this using the Debian sid freeradius package, which is based on 3.0.12, and it seems to "work": frtest3:~# tail /etc/freeradius/3.0/dictionary # # These attributes are examples # #ATTRIBUTE My-Local-String 3000 string #ATTRIBUTE My-Local-IPAddr 3001 ipaddr #ATTRIBUTE My-Local-Integer 3002 integer ATTRIBUTE AtenIsCrazy 26 octets frtest3:~# cat /etc/freeradius/3.0/policy.d/foo foo { update reply { # Vendor-Specific = "su/administrator" &Attr-26 = 0x73752f61646d696e6973747261746f72 } } frtest3:~# echo -e "User-Name=foo\nUser-Password=bar"|radclient -x 127.0.0.1 auth testing123 Sent Access-Request Id 45 from 0.0.0.0:41151 to 127.0.0.1:1812 length 43 User-Name = "foo" User-Password = "bar" Cleartext-Password = "bar" Received Access-Accept Id 45 from 127.0.0.1:1812 to 0.0.0.0:0 length 38 AtenIsCrazy = 0x73752f61646d696e6973747261746f72 Ready to process requests (0) Received Access-Request Id 224 from 127.0.0.1:41327 to 127.0.0.1:1812 length 43 (0) User-Name = "foo" (0) User-Password = "bar" (0) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default (0) authorize { (0) policy filter_username { (0) if (&User-Name) { (0) if (&User-Name) -> TRUE (0) if (&User-Name) { (0) if (&User-Name =~ / /) { (0) if (&User-Name =~ / /) -> FALSE (0) if (&User-Name =~ /@[^@]*@/ ) { (0) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (0) if (&User-Name =~ /\.\./ ) { (0) if (&User-Name =~ /\.\./ ) -> FALSE (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (0) if (&User-Name =~ /\.$/) { (0) if (&User-Name =~ /\.$/) -> FALSE (0) if (&User-Name =~ /@\./) { (0) if (&User-Name =~ /@\./) -> FALSE (0) } # if (&User-Name) = notfound (0) } # policy filter_username = notfound (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop (0) [digest] = noop (0) suffix: Checking for suffix after "@" (0) suffix: No '@' in User-Name = "foo", looking up realm NULL (0) suffix: No such realm "NULL" (0) [suffix] = noop (0) eap: No EAP-Message, not doing EAP (0) [eap] = noop (0) files: users: Matched entry foo at line 91 (0) [files] = ok (0) policy foo { (0) update reply { (0) AtenIsCrazy = 0x73752f61646d696e6973747261746f72 (0) } # update reply = noop (0) } # policy foo = noop (0) [expiration] = noop (0) [logintime] = noop (0) [pap] = updated (0) } # authorize = updated (0) Found Auth-Type = PAP (0) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (0) Auth-Type PAP { (0) pap: Login attempt with password (0) pap: Comparing with "known good" Cleartext-Password (0) pap: User authenticated successfully (0) [pap] = ok (0) } # Auth-Type PAP = ok (0) # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default (0) post-auth { (0) update { (0) No attributes updated (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) } # post-auth = noop (0) Sent Access-Accept Id 224 from 127.0.0.1:1812 to 127.0.0.1:41327 length 0 (0) AtenIsCrazy = 0x73752f61646d696e6973747261746f72 (0) Finished request Waking up in 4.9 seconds. (0) Cleaning up request packet ID 224 with timestamp +13 Ready to process requests But I assume you break all other vendor attributes, so it is not a godd idea if you are using the server for multi-vendor equipment Bjørn
On 28/03/2017 16:59, Bjørn Mork wrote:
Another hackish workaround is to define your own "26" attribute in the dictionary.
Genius! Added: ATTRIBUTE Aten-Vendor-Specific 26 string And as far as I can see, it doesn't mess up other vendor-specific attributes. Users file: bob Cleartext-Password := "hello" Cisco-AVPair += "foo", Aten-Vendor-Specific += "su/administrator" Policy: foo { update reply { Cisco-AVPair += "bar" Aten-Vendor-Specific += "su/readonly" } } radtest: Received Access-Accept Id 133 from 127.0.0.1:1812 to 0.0.0.0:0 length 73 Cisco-AVPair = "foo" Attr-26 = 0x73752f61646d696e6973747261746f72 Cisco-AVPair = "bar" Attr-26 = 0x73752f726561646f6e6c79 tcpdump: 0x0030: 1a0b 0000 0009 0105 666f 6f1a 1273 752f ........foo..su/ 0x0040: 6164 6d69 6e69 7374 7261 746f 721a 0b00 administrator... 0x0050: 0000 0901 0562 6172 1a0d 7375 2f72 6561 .....bar..su/rea 0x0060: 646f 6e6c 79 donly Cheers! Brian.
On Mar 29, 2017, at 10:15 AM, Brian Candler <b.candler@pobox.com> wrote:
On 28/03/2017 16:59, Bjørn Mork wrote:
Another hackish workaround is to define your own "26" attribute in the dictionary.
Genius! Added:
ATTRIBUTE Aten-Vendor-Specific 26 string
And as far as I can see, it doesn't mess up other vendor-specific attributes. Users file:
It doesn't. If the numbers conflict, the "main" one is used for incoming packets. But you can still use the name "Aten-Vendor-Specific" to create the Aten-specific data. After looking into this in v3, it's just too hard to fix perfectly.. I corrected the error messages, which should help. We put a lot of work into v4, in order to be able to use &Attr-26 and similar "raw" attributes. Back-porting that to v3 would change a lot. So, it's better to leave well enough alone. Alan DeKok
participants (3)
-
Alan DeKok -
Bjørn Mork -
Brian Candler