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 [email protected], 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 <[email protected]> on behalf of Heikki Vatiainen via radiator <[email protected]> Sent: 15 August 2024 3:16 PM To: [email protected] <[email protected]> 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 [email protected] https://lists.open.com.au/mailman/listinfo/radiator
_______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
