User name case insensitivity and eduroam proxying

Jonathan huffelduffel at gmail.com
Mon Jun 13 15:47:18 UTC 2022


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

> On Jun 13, 2022, at 10:52 AM, Jonathan <huffelduffel at 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
>


More information about the Freeradius-Users mailing list