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

We did read the whole documentation, but I'm not going to copy/paste it here... With regards to DEFAULT matching, there wasn't anymore info in the DEBUG log then this: [suffix] Looking up realm "HoMeServer.Country" for User-Name = "UserName@HoMeServer.Country" [suffix] Found realm "DEFAULT" [suffix] Adding Realm = "DEFAULT" We just solved the regex realm problem, apparently when you only have a regex realm statement, it doesn't work... When you additionally add the normal non-regex realm it will correctly match the regex to the normal non-regex statement. I don't think this behavior is in the documentation. NOT WORKING: only the regex statement: realm "~/homeserver\.country/i" WORKING: realm "homeserver.country" combined with realm "~/homeserver\.country/i" J. On Mon, Jun 13, 2022 at 5:09 PM Alan DeKok <aland@deployingradius.com> wrote:

On Jun 13, 2022, at 10:52 AM, Jonathan <huffelduffel@gmail.com> wrote:

...

We have a problem with case-sensitivity because of users not typing their username correctly...

The bests approach is to get the users to type it correctly. Once they've entered it once, it should be cached, and there's no issue.

Or, use automated software to configure their systems.

...

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

That's depressing. To be honest, you should just reject them. If they can't follow the simplest of instructions, too bad for them.

And who randomly hits the <shift> key while entering their name? It's crazy.

...

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.

Yes, differing inner/outer identities is OK. What isn't OK is different *realms* for inner and outer identities.

I am quite aware of how FreeRADIUS works, and your description here is simply not correct.

...

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*

Because you can't just randomly change the various identity fields and have things work. There are a number of cryptographic fields derived from those identities. So using the wrong identity means that those fields will be calculated incorrectly, and the user will be rejected.

i.e. this message is a *helpful* message telling you that you broke your configuration. If you try to work around it, you will get a *less* helpful message when the user is rejected for various magic cryptographic reasons.

The solution is to leave the names alone, but to do case-insensitive lookups on realms, and names in the database. That will work.

...

This comes from src/modules/rlm_eap/eap.c containing the following check:

We do have access to the source code... there's no reason to cut & paste it here.

...

QUESTION1: Is there a way to handle the realm module processing in a case insensitive way?

Edit the source code, or use regexes. But it likely won't help.

...

QUESTION2: we see that the DEFAULT realm is still matched, even though the more specific homeserver.country is literally in the username...

Because you configured it that way? See the debug log for why this happens.

...

We already tried to help out loading configuration files order in sites-enabled:

The process to find a realm is documented in proxy.conf. Please read it.

There is nothing which depends on the order of the configuration files.

Read the documentation to see how things work. Don't invent behavior, and then get surprised when the server doesn't work as you expect.

As for the upper / lowercase issue, the best fix is to get the students to enter their names correctly. If you mangle the names when the server receives a packet, it won't work. Or, change the configuration to do case-insensitive lookups for realms and user names. That will work.

Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html