Your message dated Mon, 10 Feb 2025 22:17:19 +0100
with message-id <[email protected]>
and subject line Closing obsolete FreeRADIUS bugs
has caused the Debian Bug report #896952,
regarding freeradius: NT/LM password check fails, if Calling-Station-Id per 
user check activated
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
896952: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896952
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: freeradius
Version: 3.0.12+dfsg-5+deb
Architecture: amd64

I want to have per user MAC address checking and per user VLAN
assignment. It is possible if:



1/ Requests attributes are copied into inner tunnel by adding

copy_request_to_tunnel = yes

into

eap { peap { } }

in file /etc/freeradius/3.0/mods-enabled/eap



2/ Send inner tunnel attributes to outside by adding

use_tunneled_reply = yes

into

eap { peap { } }

in file /etc/freeradius/3.0/mods-enabled/eap



3/ users are defined like:

username Cleartext-Password := "password" , Calling-Station-ID ==
"00-DE-AD-BE-EF-00"
        Tunnel-Type = VLAN,
        Tunnel-Medium-Type = IEEE-802,
        Tunnel-Private-Group-ID = 100,
        Fall-Through = Yes

in file /etc/freeradius/3.0/users



This works fine and MAC address is checked for Android devices. But if
using Windows 10 device, authentication fails with:

(7) eap_mschapv2: # Executing group from file
/etc/freeradius/3.0/sites-enabled/inner-tunnel
(7) eap_mschapv2:   authenticate {
(7) mschap: WARNING: No Cleartext-Password configured.  Cannot create
NT-Password
(7) mschap: WARNING: No Cleartext-Password configured.  Cannot create
LM-Password
(7) mschap: Creating challenge hash with username: czpzlpwd0006
(7) mschap: Client is using MS-CHAPv2
(7) mschap: ERROR: FAILED: No NT/LM-Password.  Cannot perform authentication
(7) mschap: ERROR: MS-CHAP2-Response is incorrect
(7)     [mschap] = reject
(7)   } # authenticate = reject




But it happens only if Calling-Station-ID is next to
Cleartext-Password in users file. If that line does not have
Calling-Station-ID and user is defined like:

username Cleartext-Password := "password"
        Tunnel-Type = VLAN,
        Tunnel-Medium-Type = IEEE-802,
        Tunnel-Private-Group-ID = 100,
        Fall-Through = Yes

Authentication works and Windows 10 device is authenticated, but no
MAC address is checked.



My other modifications to my configurations:

1/ enabled ntdomain realms in
/etc/freeradius/3.0/sites-enabled/default and
/etc/freeradius/3.0/sites-enabled/inner-tunnel

2/ configured local DOMAIN in /etc/freeradius/3.0/proxy.conf

realm DOMAIN {
}



It looks, like mschap is using NTLM password checking if MS Windows
device is authenticating, but another method (MD5?) if it is Android
device.

It results that users with Android device can be configured including
Calling-Station-ID, but Windows devices must be configured without
Calling-Station-ID, so no MAC address checking for Windows devices.
For me it looks, like mschap NT/LM auth is not parsing correctly the
line, if there is Calling-Station-ID.

I expect, that I can use per user MAC address checking independently
on used end device, so Android and Windows users can be configured
with Calling-Station-ID.



I am using Debian GNU/Linux 9.4, kernel 4.9.0-6-amd64 #1 SMP Debian
4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux and libc6
2.24-11+deb9u3.

--- End Message ---
--- Begin Message ---
Dear submitter,

thanks for submitting a bug report against the Debian FreeRADIUS package. Your bug has been filed for an ancient version of FreeRADIUS (in Debian) that has not been supported anymore for years. I'm sorry we could not take care of it in time.

If you can still reproduce this problem on a current version (at least in 3.2.1 shipped with Debian 12 aka bookworm), please reopen this bug.

Bernhard

--- End Message ---

Reply via email to