[RADIATOR] Problems with ntlm_auth for EAP inner auth after upgrade

[Heikki Vatiainen]

On 31.7.2024 22.56, Jethro Binks via radiator wrote:

> or via an mschap_test perl script that generates the challenge stuff and 
> feeds to helper-protocol=ntlm-server-1:
> 
> $ ./mschap-test -c
> Enter AD account username (no domain or realm) to probe: testuser
> Enter domain: mydomain
> Enter password for mydomain\testuser:
> Invoking ntlm_auth --configfile=/usr/local/etc/smb4.conf --allow- 
> mschapv2 --helper-protocol=ntlm-server-1 --option='log level=0'  < 
> ntlmtest.query

The script adds '--allow-mschapv2' to ntlm_auth parameters. I'd first 
check that ntlm_auth that Radiator launches uses the same flag.

There's more about the flag here:
https://files.radiatorsoftware.com/radiator/ref/AuthByNTLM.html#Domain_AuthByNTLM-3

> Now perhaps my use of eapol_test is wrong, it's been a long time, but I 
> seem to get the same result if I let some real user traffic in.  If the 
> supplicant is configured with a realm on the inner auth, then they fail 
> auth, and for the rare ones who have no realm specified there, it works 
> (I think - it's hard to do this for long as it is disruptive).

The username that ntlm_auth sends should be one that allows the AD to 
find the user record.

Maybe you could try without DefaultDomain AuthBy NTLM parameter or set 
the Windows domain directly with Domain to something that works.

But I'd do that after --allows-mschapv2 flag to see that's not a 
problem. This flag and Domain and DefaultDomain are for different 
reasons, but I'd change just one thing at the time.

Thanks,
Heikki