Hi Alan, Thanks for the reply and helpful information. After further in-depth investigation, we had found the root cause. The user name sent by RD gateway server is good. It sends username in Domain\\UserName format. The problem is our filter setting. The problematic filters are update request { User-Name := "%{tolower:%{User-Name}}" } if (&User-Name !~ /@/) { update request { User-Name := "%{User-Name}@UPN_domain" } } The first tolower function had changed user-name from domain\\test_acct to domain\test_acct the second filter had changed user-name from domain\test_acct to domain est_acct The problem is fixed by replacing the filters by if ((&User-Name !~ /@/) && (&User-Name !~ /(.+)\\(.+)/)) { update request { User-Name := "%{User-Name}@UPN_domain" } } thanks again and appreciate your help Regards, Eric On Tue, Jan 2, 2024 at 9:58 PM Alan DeKok <aland@deployingradius.com> wrote:
On Jan 2, 2024, at 3:26 AM, Eric Lin <pirate585@gmail.com> wrote:
On the freeradius, normal accounts will be proxied to the NPS server and special accounts will be proxied to another radius server. The whole workflow looks good and only issue is the escaping characters (\n, \r, and \t). The username sent by RD Gateway server is DomainA\\username format
The issue: for account without escape characters, it works fine as follows. ----------------------------------- Ready to process requests (0) Received Access-Request Id 3 from 10.88.18.245:56346 to 10.88.18.212:1812 length 153 (0) Service-Type = Sip-session (0) User-Name = "domainA\\eric"
This User-Name has a backslash in it.
but accounts starting with r, t and n will encounter escape character issue ----------------------------------- Ready to process requests (0) Received Access-Request Id 3 from 10.88.18.245:56346 to 10.88.18.212:1812 length 153 (0) Service-Type = Sip-session (0) User-Name = "domainA\tee"
This User-Name does not have a backslash in it. It has a literal tab character (0x09)
If that User-Name has a backslash in it, you would see it printed as:
... User-Name = "domainA\\tee"
(0) ntdomain: Checking for prefix before "\" (0) ntdomain: No '\' in User-Name = "domainA ee", looking up realm NULL
See that space after "domainA"? That's a literal tab character.
The ntdomain module looks for the backslash by looking for the exact character. If it says there's no backslash in the string, then there's no backslash in the string,
I had done my google search and found only one similar case https://lists.freeradius.org/pipermail/freeradius-users/2017-February/086635... I also tried different config/tests on freeradius, but no luck.
Try using wireshark to see the raw RADIUS packets. The first one will have a backslash. The second one will have a literal tab (0x09).
Is there a way to not escaping characters in user-name on freeradius?
It's not a FreeRADIUS issue. The client is sending a tab character instead of a literal \ followed by a "t"
I am seeking if there is a more simple solution on freeradius. Can someone help?
Fix the client so that it actually sends a backslash and then "t" instead of a tab character.
I'd suggest looking at the raw RADIUS packets using Wireshark. Do this at every RADIUS server / proxy. For proxies, look at both input packets and output packets.
This will let you know exactly where the User-Name is coming from. Is the bad User-Name coming from the client? In which case you have to fix the client.
Or is the client creating the correct User-Name, and then a proxy is mashing "\t" into tab?
FreeRADIUS handles backslashes, and "\t" correctly. It doesn't mangle "\t" --> tab when it receives a User-Name. It doesn't modify the User-Name unless you tell it to.
FreeRADIUS is just telling you what the problem is. The cause of the problem is somewhere else.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
