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

[Jethro Binks]

Hi Heikki,

I re-tested adding --allow-mschapv2 to NtlmAuthProg but it made no difference; I think I've tried that with and without before but wasn't consistent in what I wrote in my email.

As a cross-check, I also tested the same eapol_test config against a Radiator server that I did not upgrade yet, and that was fine.

The (inner) username (identity) being supplied is generally of the form username at strath.ac.uk, however the directory is SUBDOMAIN.STRATH.AC.UK so I effectively have:

<AuthBy NTLM>
    Identifier      ITSAuthEAPInnerNTLMbackend
    NtlmAuthProg /usr/local/bin/ntlm_auth --allow-mschapv2 --configfile=/usr/local/etc/smb4.conf --helper-protocol=ntlm-server-1 --option="log level=0"
    DefaultDomain SUBDOMAIN.STRATH.AC.UK
    EAPType MSCHAP-V2
    UsernameMatchesWithoutRealm
</AuthBy>

The intention being that UsernameMatchesWithoutRealm strips @strath.ac.uk supplied in the identity, and I think DefaultDomain was there to add the AD domain in.  This seems to work for clients that supply a realm-less inner identity (including if I change my eapol_test config to a realmless identity="username") , but I suspect DefaultDomain is actually redundant here, since Samba knows what the domain is anyway.

I've now added Domain SUBDOMAIN.STRATH.AC.UK explicitly too to the AuthBy, and the samba logs seem to show the right thing being tested:

[2024/08/27 17:38:10.340352,  2, pid=2356]   NTLM CRAP authentication for user [SUBDOMAIN.STRATH.AC.UK]\[username] returned NT_STATUS_WRONG_PASSWORD

I can test the Domain param is being used by changing it, and now I can get:

[2024/08/27 17:42:18.767691,  2, pid=2356]   NTLM CRAP authentication for user [NONSENSE.STRATH.AC.UK]\[username] returned NT_STATUS_NO_SUCH_USER

So I am still puzzled, even when forcing use of Domain, what is different between running ntlm_auth on the CLI, and ntlm_auth through Radiator.

Here's a samba line generated using my same test script sending to the non-upgraded working server:

[2024/08/27 17:46:05.053600,  5, pid=6371]   NTLM CRAP authentication for user [SUBDOMAIN.STRATH.AC.UK]\[username] returned NT_STATUS_OK

Jethro.


.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

Jethro R Binks, Network Manager,

Information Services Directorate, University Of Strathclyde, Glasgow, UK


The University of Strathclyde is a charitable body, registered in Scotland, number SC015263.

________________________________
From: radiator <radiator-bounces at lists.open.com.au> on behalf of Heikki Vatiainen via radiator <radiator at lists.open.com.au>
Sent: 15 August 2024 3:16 PM
To: radiator at lists.open.com.au <radiator at lists.open.com.au>
Subject: Re: [RADIATOR] Problems with ntlm_auth for EAP inner auth after upgrade

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

_______________________________________________
radiator mailing list
radiator at lists.open.com.au
https://lists.open.com.au/mailman/listinfo/radiator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20240827/b06aaabf/attachment.html>