Replies inline because I'm not insane. ;) On Wed, Mar 10, 2021 at 6:14 AM Matthew Newton <mcn@freeradius.org> wrote:
On 10/03/2021 00:00, Braden McGrath via Freeradius-Users wrote:
When I set "DEFAULT Auth-Type := Kerberos" in the "users" / "authorize" file, this then (obviously) breaks *other* types of authN (and I saw in the "default" site config that it is not recommended to set a default Auth-Type!)
Yes, because you're forcing Auth-Type. Generally you don't want to do that (but Kerberos is one case where you do).
Yeah, I knew that forcing auth-type was going to be a problem, but it's helpful to know that Kerberos is a case where I need to do something special. :)
I'm not sure which file(s) I should be editing and what magic lines I need to make this sort of logic happen. I read up on unlang a bit, but when I tried putting what I thought was a basic unlang statement into "users", radiusd got angry and wouldn't start.
Unlang goes in the virtual server files (sites-{available,enabled}/*), not in the users file (which is the module configuration file for rlm_files).
This is also very helpful... is there an overview of what each file is supposed to do somewhere? There is *a lot* in here.
I'm thinking maybe I need an "if" or two in the "authorize { }" section of the "site" config (I'm just using a copy of the "default" site), but some of the documentation explicitly says NOT to put unlang into that stanza, so I got confused and came here.
I don't know where you read that, but it's completely wrong.
From the comments in the "default" site file, but I fully admit I likely misunderstood this... :-) And I just realized I saw this in the *authenticate* section, not authorize... [sites-available/default]: # Authentication. [...] # Please do not put "unlang" configurations into the "authenticate" # section. Put them in the "post-auth" section instead. That's what # the post-auth section is for. [/end]
Edit sites-enabled/default, go to the authorize{} section. Auth-Type is normally set to "PAP" by the pap module, which looks for the User-Password attribute. So comment out 'pap' (at the end of that section) and instead put
if (&User-Password) { update control { &Auth-Type = Kerberos } }
remove the DEFAULT entry you've put in the users file.
This makes sense, and I went back and re-read some of TFM (https://wiki.freeradius.org/guide/Concepts) and I now understand why it belongs in authorize{}, too. I can confirm this works as expected, so now I'm krb'ing instead of pap'ing, but the MSCHAP junk still functions as well. :-)n
*Second problem*, and this is relatively minor: I want to be able to accept both a "bare" username, or username@REALM.ORG (or username@realm.org, case-insensitive). I'm not sure what to massage to accomplish this either, I'm thinking something in the "hints" file, but that appears to be intended for dial-up modem bank auth...
No, "hints" is old, most people should ignore it.
You can add a realm to proxy.conf, and let the rlm_realm module (see "suffix" in the default virtual server) handle it, e.g.
realm realm.com { }
Alternatively, add "split_username_nai" near the top of authorize{} (from policy.d/canonicalization) which will put the stripped username in Stripped-User-Name, but it will work for any realm, not just ones you've listed.
I don't actually want to proxy to anywhere else, I just want to use it locally... I'm guessing this is just "the way it's done" though? I'm fine with a failure for anything that doesn't match my predefined realm(s), though. Are realms (defined in proxy.conf) case-sensitive? I see the examples in the comments that mention regexp realms are NOT sensitive, but I'm guessing non-regex are? I tried adding: realm foobar.net { } as well as realm FOOBAR.NET { } to proxy.conf, but I'm still getting complaints that the realm doesn't exist: (0) suffix: Checking for suffix after "@" (0) suffix: Looking up realm "foobar.net" for User-Name = "testuser@foobar.net" (0) suffix: No such realm "foobar.net" Do I actually need to populate the realm { } stanzas with ... something (like home_server or similar)? or should they look like the realm LOCAL { } does? I truly appreciate the assistance, thank you again! -- Braden