[RADIATOR] Problems with ntlm_auth for EAP inner auth after upgrade
Jethro Binks
jethro.binks at strath.ac.uk
Wed Jul 31 19:56:48 UTC 2024
Hello,
Long time no write, but that's because Radiator just runs and runs with no issues ...
At least until I lately upgraded my OS and Radiator, from somethingveryold to 4.28.1.
A few config tweaks were needed, but I'm still struggling to get my inner MSCHAP auth working via ntlm_auth. It was all fine for years before the upgrade. I've been through the release notes but cannot pinpoint a Radiator change that might explain why it no longer works.
ntlm_auth from the CLI works fine to test the password of an account, either by doing it the ordinary way with just ntlm_auth --username:
$ ntlm_auth --username=readonly --option='log level=0'
Password:
NT_STATUS_OK: The operation completed successfully. (0x0)
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
-- Contents of query file --
Username: testuser
NT-Domain: mydomain
LANMAN-Challenge: 0000000000000000
NT-Response: 23fb1e018c93bd7527721936bc771fd888f1f31280bf373c
.
-- Output --
Authenticated: Yes
.
-- Done --
And over in the samba logs all looks fine:
[2024/07/31 20:17:32.165389, 5, pid=2356] NTLM CRAP authentication for user [mydomain]\[testuser] returned NT_STATUS_OK
[2024/07/31 20:17:32.165558, 3, pid=2356] Auth: [winbind,NTLM_AUTH, ntlm_auth, 2354] user [mydomain]\[testuser] at [Wed, 31 Jul 2024 20:17:32.165540 BST] with [NTLMv1] status [NT_STATUS_OK] workstation [RADIUSSERVER] remote host [unix:] became []\[] [(NULL SID)]. local host [unix:]
{"timestamp": "2024-07-31T20:17:32.165619+0100", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4624, "logonId": "38bf3a15aba5105f", "logonType": 3, "status": "NT_STATUS_OK", "localAddress": "unix:", "remoteAddress": "unix:", "serviceDescription": "winbind", "authDescription": "NTLM_AUTH, ntlm_auth, 2354", "clientDomain": "mydomain", "clientAccount": "testuser", "workstation": "RADIUSSERVER", "becameAccount": "", "becameDomain": "", "becameSid": null, "mappedAccount": null, "mappedDomain": null, "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv1", "duration": 3013}}
Moving on to Radiator, my inner AuthBy:
<AuthBy NTLM>
Identifier ITSAuthEAPInnerNTLMbackend
NtlmAuthProg /usr/local/bin/ntlm_auth --configfile=/usr/local/etc/smb4.conf --helper-protocol=ntlm-server-1 --option="log level=0"
DefaultDomain MYDOMAIN
EAPType MSCHAP-V2
# Strip off the realm passed by the user
# This may not work any more
UsernameMatchesWithoutRealm
</AuthBy>
And in ps:
20:42 0:00.12 /usr/local/bin/ntlm_auth --configfile=/usr/local/etc/smb4.conf --helper-protocol=ntlm-server-1 --option=log level=0
But I really want to authenticate wireless users. So I try using eapol_test from wpa_supplicant with a config that looks like this:
network={
ssid="example"
key_mgmt=WPA-EAP
eap=PEAP
identity="testuser"
anonymous_identity="anonymous at strath.ac.uk"
password="xxxx"
phase2="auth=MSCHAPV2"
}
Then running eapol_test with this, it will work:
...
ENGINE: engine deinit
MPPE keys OK: 2 mismatch: 0
SUCCESS
And in the samba log:
[2024/07/31 20:29:08.474789, 5, pid=2356] NTLM CRAP authentication for user [MYDOMAIN]\[testuser] returned NT_STATUS_OK
[2024/07/31 20:29:08.474995, 3, pid=2356] Auth: [winbind,NTLM_AUTH, ntlm_auth, 2354] user [MYDOMAIN]\[testuser] at [Wed, 31 Jul 2024 20:29:08.474978 BST] with [NTLMv1] status [NT_STATUS_OK] workstation [RADIUSSERVER] remote host [unix:] became []\[] [(NULL SID)]. local host [unix:]
{"timestamp": "2024-07-31T20:29:08.475092+0100", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4624, "logonId": "38f5d2f87826010b", "logonType": 3, "status": "NT_STATUS_OK", "localAddress": "unix:", "remoteAddress": "unix:", "serviceDescription": "winbind", "authDescription": "NTLM_AUTH, ntlm_auth, 2354", "clientDomain": "MYDOMAIN", "clientAccount": "readonly", "workstation": "RADIUSSERVER", "becameAccount": "", "becameDomain": "", "becameSid": null, "mappedAccount": null, "mappedDomain": null, "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv1", "duration": 3050}}
And in the Radiator log (duplicate lines elided):
Wed Jul 31 19:29:08 2024 475366: DEBUG: Received attribute: Authenticated: Yes
Wed Jul 31 19:29:08 2024 477277: DEBUG: Received attribute: LANMAN-Session-Key: F0F3F1DD822DDC5F
Wed Jul 31 19:29:08 2024 478893: DEBUG: Received attribute: User-Session-Key: 5B1B744D8EC6D6042B213AEBD03F7822
Wed Jul 31 19:29:08 2024 479972: DEBUG: Received attribute: .
Wed Jul 31 19:29:08 2024 481365: DEBUG: Radius::AuthNTLM ACCEPT: : 'testuser' [testuser]
Wed Jul 31 19:29:08 2024 482689: DEBUG: AuthBy NTLM result: ACCEPT,
Wed Jul 31 19:29:08 2024 483694: DEBUG: Access accepted for testuser
Now if I change the eap identity to carry the realm in the eapol_test config:
network={
ssid="example"
key_mgmt=WPA-EAP
eap=PEAP
identity="testuser at strath.ac.uk"
anonymous_identity="anonymous at strath.ac.uk"
password="xxxx"
phase2="auth=MSCHAPV2"
}
We get:
...
ENGINE: engine deinit
MPPE keys OK: 0 mismatch: 2
FAILURE
In samba:
[2024/07/31 20:33:52.130394, 2, pid=2356] NTLM CRAP authentication for user [MYDOMAIN]\[testsuser] returned NT_STATUS_WRONG_PASSWORD
[2024/07/31 20:33:52.130586, 2, pid=2356] Auth: [winbind,NTLM_AUTH, ntlm_auth, 2354] user [MYDOMAIN]\[testuser] at [Wed, 31 Jul 2024 20:33:52.130568 BST] with [NTLMv1] status [NT_STATUS_WRONG_PASSWORD] workstation [RADIUSSERVER] remote host [unix:] mapped to [(null)]\[(null)]. local host [unix:]
{"timestamp": "2024-07-31T20:33:52.130654+0100", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4625, "logonId": "2d268e8de2c2700", "logonType": 3, "status": "NT_STATUS_WRONG_PASSWORD", "localAddress": "unix:", "remoteAddress": "unix:", "serviceDescription": "winbind", "authDescription": "NTLM_AUTH, ntlm_auth, 2354", "clientDomain": "MYDOMAIN", "clientAccount": "readonly", "workstation": "RADIUSSERVER", "becameAccount": "", "becameDomain": "", "becameSid": null, "mappedAccount": null, "mappedDomain": null, "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv1", "duration": 9577}}
And Radiator log:
Wed Jul 31 19:33:52 2024 132932: DEBUG: Received attribute: Authentication-Error: When trying to update a password, this return status indicates that the value provided as the current password is not correct.
Wed Jul 31 19:33:52 2024 134143: DEBUG: Received attribute: .
Wed Jul 31 19:33:52 2024 136081: DEBUG: Radius::AuthNTLM REJECT: AuthBy NTLM Password check failed: 'testuser' [testuser at strath.ac.uk]
Wed Jul 31 19:33:52 2024 137300: DEBUG: AuthBy NTLM result: REJECT, AuthBy NTLM Password check failed
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).
Have I missed something somewhere?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20240731/0c6a7fb2/attachment-0001.html>
More information about the radiator
mailing list