We have a problem with case-sensitivity because of users not typing their username correctly... *Topology:* client WiFi PEAP -> our network -> country federation proxy -> upstream eduroam home server So we have 2 problems (3 if you count user mixed-case error as root-cause) PROBLEM1: proxying and realm matching are case sensitive today on our side and also on country federation proxy Since many users are randomly typing Uppercase/Lowercase their UserName@ReALm and REALM matching by default is case sensitive, we updated filter_usernames policy to convert full outer User-Name to lowercase, as trying to fix the errors on client/user side didn't work out... students don't really read/listen to the guidelines: # update mixed case to lowercase # e.g. "UseRNaMe" # if (User-Name != "%{tolower:%{User-Name}}") { update request { User-Name := "%{tolower:%{User-Name}}" Reply-Message += "Updated: Username contains mixed upper/lowercase" } updated } else { noop } This resolved REALM matching on our network and also resulted in proper forwarding on the country federation server (being case sensitive as well) to the home server. Changing username to lowercase used to work fine for *most* of our home servers we saw running NPS, until one of our upstream eduroam home servers recently changed from Microsoft NPS to freeradius (validated on 3.0.25, and also checked code of 2.2.10) PROBLEM2 appeared: apparently freeradius verifies outer & inner identity if they match. If the username is case mismatching, the PEAP tunnel setup is rejected. Although IMHO it should be perfectly possible to have different outer/inner because of anonymous outer. Thereby the Upstream eduroam home server radius handling the requests gives the following hardcoded failure: *eap: Identity does not match User-Name, setting from EAP Identity* This comes from src/modules/rlm_eap/eap.c containing the following check: /* * A little more paranoia. If the NAS * *did* set the User-Name, and it doesn't * match the identity, (i.e. If they * change their User-Name part way through * the EAP transaction), then reject the * request as the NAS is doing something * funny. */ if (strncmp(handler->identity, vp->vp_strvalue, MAX_STRING_LEN) != 0) { RDEBUG("Identity (%s) does not match User-Name (%s). Authentication failed.", handler->identity, vp->vp_strvalue); free(*eap_packet_p); *eap_packet_p = NULL; return NULL; } QUESTION1: Is there a way to handle the realm module processing in a case insensitive way? We know freeradius should support regex, so theoretically the following specific realm configuration should work: realm "~ /homeserver\\.country$/i" in proxy.conf where homeserver and country are offcourse something else. QUESTION2: we see that the DEFAULT realm is still matched, even though the more specific homeserver.country is literally in the username... We already tried to help out loading configuration files order in sites-enabled: 00local-realms 01-proxy-more-specific realm "~ /homeserver\\.country$/i" { auth_pool = homeserver.country ... 02-proxy-catchall-to-eduroam realm DEFAULT { auth_pool = federation.proxy ... however freeradius still loads it in different order: 00local-realms 02-proxy-catchall-to-eduroam 01-proxy-more-specific J. On Sun, 12 Jun 2022, 00:22 Alan DeKok, <aland@deployingradius.com> wrote:
On Jun 11, 2022, at 2:21 PM, Luveh Keraph <1.41421@gmail.com> wrote:
I thought I had grasped what is involved in making FreeRADIUS 3.0.* to process user names in a case-insensitive way, but I am not so sure now.
That's a bit of an incorrect understanding. The server is composed of a bunch of modules. Each module has it's own configuration. You should be able to configure a particular module to do lowercase checking.
Here is what I have done:
First, I added the following line in my /etc/raddb/mods-enabled/files:
key = "%{%{Stripped-User-Name}:-%{tolower:%{User-Name}}}"
Or:
key = "%{tolower:%{%{Stripped-Users-Name}:-%{User-Name}}}"
This picks either Stripped-User-Name OR User-Name, and then lowercases the result.
The line you have above only lowercases User-Name, and leaves Stripped-User-Name along.
I launched my FreeRADIUS server after ths.
I have the following entry in my /etc/raddb/users file:
ijk_user1 User-Password != "IJKpassword1" ijk_user1 Cleartext-Password := "IJKpassword1"
Lowercase names there are goo.0
With this, when I try to ssh as IJK_User1 (notice the mixed case) into a system that turns over authentication to my FreeRADIUS server, I get the following debugging information at this server:
Sat Jun 11 11:02:25 2022 : Debug: (0) files: EXPAND %{%{Stripped-User-Name}:-%{tolower:%{User-Name}}} Sat Jun 11 11:02:25 2022 : Debug: (0) files: --> ijk_user1 Sat Jun 11 11:02:25 2022 : Debug: (0) files: users: Matched entry ijk_user1 at line 447
So it matches, that's good.
Sat Jun 11 11:02:25 2022 : Debug: (0) Sent Access-Accept Id 64 from 192.168.0.55. 23:1812 to 192.168.0.66:60600 length 0
Which is fine: the user name gets converted from IJK_User1 to ijk_user1
and
the authentication with password IJKpassword1 succeeds, as expected.
That's good.
I then changed the relevant entry in my /etc/raddb/users file as follows:
IJK_User1 User-Password != "IJKpassword1" IJK_User1 Cleartext-Password := "IJKpassword1"
That won't work.
The "key" configuration is lowercasing the User-Name from the packet. That lowercased name is then used to compare with the names in the "users" file. The comparison there is cases sensitive.
So it won't work.
If I understand things correctly, the key = ... line that I added to the files file does indeed recast the incoming user name to lowercase.
Yes.
However, the FreeRADIUS server still compares incoming user names against those in the users file in a case sensitive way.
That's how it works.
This is fine, but not quite what I was looking for.
The first example works. Why worry about it?
Is it possible to get FreeRADIUS to compare user names (and user names alone - not passwords) in a real case-insensitive way against those in the /etc/raddb/users file?
No.
There's no configuration item, which says "do comparisons in a case insensitive way".
Your first configuration is correct. Use it. Why would you put names into the "users" file in random uppercase / lowercase?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html