The user database we use in Nethserver (either SAMBA or LDAP) stores passwords encrypted. In order for RADIUS server to perform any validation against an encrypted database the credentials must come to it in clear-text (e.g., the RADIUS clients must provide a method to send credentials in clear text, over an encrypted channel of course). In order to see some advance in this direction it is necessary to simulate an infrastructure with RADIUS clients supporting such methods (e.g., EAP-TTSL + PAP) also considering doing the validation against a common authentication layer like PAM instead of SAMBA or LDAP independently. Nanostation, the devices I used in the tests, don’t support PAP.
Another issue related to user database integration is the relation between MAC addresses and users in it. There is no way to establish such relation if we use the user database and the host MAC address reservation features separately one another. It would be necessary to redesign the plugin interface entirely to provide such relation. That really would be version 1.0 of the nethserver-freeradius plugin. Such integration was my first attempt but was frustrated because the lack of a RADIUS client with such ability of sending clear text passwords (through an encrypted channel). So the plugin is in the way it is now.
Appropriate conditions to carry on the effort. Presently I am in the process of settle down in a new country and this process is demanding most of my energies.
Saying goodbye to this effort? Of course not. It is a good one
The module initially only supported device based authentication. IFAIK account based authentication (Samba 4 / LDAP) was never added to the module.
I think it would be best to start with an installation howto with account based authentication enabled.
If you are willing to try installing it (on a test machine) and document the process, I am sure the rest of the community will chip in with testing and fine tuning the install howto.
When we have a fool-proof install howto, we can try creating a complete module / rpm for easy install.
Here is a more indept post about our community ‘new-feature’ process:
AFAIK or recall, one of the major issues for a usable FreeRadius implementation - WLan comes to mind - is the issue with the outdated PEAP-MSCHAP2 protocoll. This could be considered as the logical bridge, spanning the gap between AD and Radius…
In times of SME-Server / WinXP it worked well on Macs and Windows notebooks, also Linux.
I think it doesn’t even work on Win10 out of the box anymore, but I’m not sure about this.
It would be great if this could work, I’ll be glad to test, having some current Wlan hardware lying around unused…