Removing spaces from User-Name

[Daniel Ryšlink]

Hello,

Thank you most kindly, this solution works.

The users are authenticated versus a text "users" file generated and 
exported from a database - I suppose that the spaces will cause problems 
when matching those usernames, right? Could the user name be enclosed in 
quote marks, or can the spaces be escaped somehow? So far, the 
authetication fails, because the users are not yet in the database.

-- 
Best Regards,
Daniel Ryšlink

Dne 11/29/2023 v 3:59 PM Alan DeKok napsal(a):

> On Nov 29, 2023, at 8:03 AM, Daniel Ryšlink <ryslink at dialtelecom.cz> wrote:
>> There are NAS devices (Mikrotik) in our network that generate incorrect User-Names in Access-Request packets containing spaces - example:
>>
>> User-Name = "MK-TRA eth 0/9:269.ether8"
>    Those aren't "incorrect", they're just weird.
>
>> These packets are refused and invalid by the radius server:
>>
>> Invalid user (Rejected: User-Name contains whitespace): [MK-TRA eth 0/9:269.ether8]
>    That check is there because it catches malicious users who log in as "bob" or "bob " or "bob   ", and get 3 logins on one account.
>
>> The question is - is there a way/how to do a preprocessing on the radius server to remove the whitespace characters from the User-Name? I know that the most correct solution would be to generate valid radius packets on the client side, but I already looked into the RouterOS documentation and there seem to be no fine control on how the packet is generated (User-Name is obviously constructed from configuration items, separated by said whitespaces).
>>
>> Any practical advice would be greatly appreciated, thank you very much in advance.
>    Edit the unlang policy to allow these user names.  The configuration files are text for precisely this reason:
>
>    See raddb/policy.conf.  Look for
>
> 		if (&User-Name =~ / /) {
>
>    and change it to
>
> 		if (&User-Name !~ /^MK-TRA/) && (&User-Name =~ / /)) {
>
>    There's no reason to edit the User-Name.  And editing the User-Name generally creates other problems.
>
>    As a related item, how are these users getting authenticated?  Are they in a database?  What is being done with them?  Should the server return accept / reject for these users?
>
>    Alan DeKok.
>
>