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

[Matthew Newton]

On 10/03/2021 00:00, Braden McGrath via Freeradius-Users wrote:
> Obviously, this means I can't use Kerberos everywhere, because MSCHAP
> verification isn't a User-Password attribute (which Kerberos
> requires).

So you can tell the difference between both auth types - if there's a 
User-Password then you want to do Kerberos, otherwise you want to do 
mschap.
> if I set
> DEFAULT Auth-Type := Kerberos
> in the "users" file 
...
> I am able to get
> Access-Accept back from radiusd, and I can see the Kerberos authN
> process happen in the debug output from radiusd.

Which is good as you've shown Kerberos works.


> 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).


> So, I want to use MSCHAP hash checking if that's what the NAS is
> sending, but I want to use Kerberos if the NAS is sending
> User-Password.

Sure

> 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).


> 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.

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.

Then mschap will be called first, which will set Auth-Type if the 
MS-CHAP-* attributes exist, otherwise won't set it. Later on the unlang 
above will set it to Kerberos if a) the User-Password attribute exists, 
and b) it wasn't set before ("=" instead of ":=").


> *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.

-- 
Matthew