User name case insensitivity and eduroam proxying

[Jonathan]

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 at 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 at deployingradius.com> wrote:

> On Jun 11, 2022, at 2:21 PM, Luveh Keraph <1.41421 at 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: replicated_debug.log
Type: application/octet-stream
Size: 20455 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20220613/15e844e3/attachment-0001.obj>