User name case insensitivity and eduroam proxying

[Alan DeKok]

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.