[RADIATOR] AuthNTLM feature requests

Heikki Vatiainen hvn at open.com.au
Thu Aug 21 17:09:42 CDT 2014


On 08/21/2014 01:36 AM, Klara Mall wrote:

> I see. So what I planned will not work. I have to use a dedicated
> AuthBy NTLM for every handler, right? Therefore I also don't need
> variables in NtlmAuthProg. I love variables but I cannot use them
> here - got it. :)

Yes, unfortunately variables won't be any good in this case. Multiple
dedicated AuthBy NTLMs should do the trick.

> So I have to make an LDAP
> search to do some guessing what I have and then convert it to the
> corresponding account name. Then I authenticate the account name
> with NTLM.

Thanks, that explains the need for rewrites and also where the correct
username comes from.

> I used RewriteFunction successfully in many handlers to
> realise what I described above. As well in <Handler
> TunnelledByTTLS=1>. But I noticed that it didn't work in my
> <Handler TunnelledByPEAP=1> where I use AuthBy NTLM.

RewriteFunction in Handler is not aware of EAP identity and rewrites
just the User-Name in the inner request. That's fine with TTLS/PAP since
there is no EAP identity and the User-Name is what the DB lookups etc
use. With PEAP/EAP-MSCHAP-V2 especially it's more complex,
unfortunately. See below.

> But anyway this was the reason why I wanted the
> RewriteFunction to be applicable in AuthBy NTLM. I don't know with
> which auth methods one could have similar difficuties to use
> RewriteFunction in the handler. Where one can use it in the handler
> there is IMHO no need to use it in AuthBy.

The additional twist here is that the value of 'LANMAN-Challenge' passed
to ntlm_auth depends on the original username and is calculated by
AuthBY NTLM. The username actually comes over the tunnel twice: as the
inner EAP identity and as a part of a MSCHAPv2 message.

The patch you sent is not in yet, but I thought I'd let you know your
input has been most useful. It's good to hear about the different
requirements there are.

Thanks,
Heikki


-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.


More information about the radiator mailing list