Removing spaces from User-Name
Hello, 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" These packets are refused and invalid by the radius server: Invalid user (Rejected: User-Name contains whitespace): [MK-TRA eth 0/9:269.ether8] 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. -- Regards, Daniel Ryšlink
On Nov 29, 2023, at 8:03 AM, Daniel Ryšlink <ryslink@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.
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@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.
On Nov 29, 2023, at 11:35 AM, Daniel Ryšlink <ryslink@dialtelecom.cz> wrote:
Thank you most kindly, this solution works.
That's good.
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.
The "users" file doesn't support spaces in the usernames. But the database queries support spaces just fine. Alan DeKok.
participants (2)
-
Alan DeKok -
Daniel Ryšlink