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