If MSCHAP attributes exist, use for AuthN, otherwise, force Kerberos? Also, gracefully accepting @domain in username?

[Braden McGrath]

On Wed, Mar 10, 2021 at 5:04 PM Alan DeKok <aland at deployingradius.com> wrote:
>   In short, if the documentation says you can do something, then it works.  If the document *doesn't* say that you can do something, then it won't work.
Roger. For the most part everything is behaving as I expect, and the
debug output of radiusd is definitely very helpful. I've figured out a
bunch of things before having to bug the list. :-)

>   Realms are "known domain names".  i.e. "user at example.com".  You don't put that string into LDAP, tho.  It's usually just "user".
>
>   So the config:
>
> realm example.com {
> }
>
>   tells the server that it's a local domain name / realm, and it's safe to split "user at example.com" into "user".
>
>  This is all *extensively* documented in proxy.conf.  It explains what the differences are between local realms, and proxied realms.
Make sense, I hadn't poked through proxy.conf until Matthew suggested
it (because I figured I wasn't trying to proxy anything anywhere...)

>   You can have an empty realm definition, as Matthew and the documentation suggest.
>
>   If it's not working for you, then something is configured incorrectly.  Run the server in debug mode to see what.
I'm following the guidance on the site and have been running in debug
mode, and the first thing I do after a test auth is go read the
scrollback in that tmux buffer. ;)

Your comment got me to re-inspect more carefully, and I found where
the problem was. I read through much of radiusd.conf when first
setting things up, and I thought, "I don't need to proxy anything to
other servers, this is all local!" so I changed "proxy_requests" to
"no" and commented out "$INCLUDE proxy.conf", and I did this a week
ago. I just now saw that the debug output wasn't reading proxy.conf,
and after I poked around I realized I shot myself in the foot. Insert
facepalm.jpg here.

Presumably I *could* be setting up realms in a separate (dedicated)
file and just $INCLUDE'ing that instead? But for future maintenance's
sake / standardization, I'll just stick to this... it's not really
hurting me to leave things close to default state.

One minor thing I did run into though:
> > Are realms (defined in proxy.conf) case-sensitive?
> Yes.
If *non-regex* realm names are *supposed* to be case-sensitive within
proxy.conf, they certainly aren't behaving that way.
If I just use a single (lowercase) instance of the realm, this catches
and splits correctly on both ucase and lcase realm names when fed from
a NAS/radtest.

If the same realm is included _twice_ in proxy.conf, once uppercase
and a second time lowercase, the server dies immediately after hitting
the second copy of the realm in the debug output, with no real
explanation as to why it quit.

~~~~ snippet of freeradius -X output, reading proxy.conf section
realm example.com {
        auth_pool = my_auth_failover
 }
 realm FOOBAR.NET {
 }
 realm foobar.net {
 } # realm foobar.net
~~~~
That is exactly how it dies - a # and then a copy of the duplicated
"realm X" line, and the process is gone.
If I change the order (put lowercase first, then uppercase), the death
message contains the uppercase realm name instead (it seems to just
die with "# realm secondinstance")
Comments in proxy.conf itself do imply that the realm name *is* case
sensitive in the steps describing the search ordering ("non-regex
realm with an *exact* match for the name"), but it seems like
non-regex realms are actually NOT sensitive.

Again, I truly appreciate the help you've both provided, hopefully
this will be the end of my trouble, at least for a while. ;)
Cheers,
Braden