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

[Braden McGrath]

Replies inline because I'm not insane. ;)

On Wed, Mar 10, 2021 at 6:14 AM Matthew Newton <mcn at 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 at REALM.ORG (or
> > username at 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 at 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