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


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,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.

More information about the radiator mailing list