On Wed, Mar 10, 2021 at 5:04 PM Alan DeKok <aland@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@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@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