On Apr 29, 2021, at 4:22 AM, radius.pkoch@dfgh.net wrote:
I'm new to the RADIUS business and I did my frist FreeRadius installation just two weeks ago. I still might misunderstand some of the concepts. So keep in mind that whenever I make statments about what FreeRadius does or should do - these are all my personal assumptions only and might be totally wrong. So far I only tried to get things working. I did not look at my "solution" from a security perspective.
You've taken the best approach, which is a methodical approach. It's much more efficient (and less frustrating) than making random changes in the hope that something works.
I never heard of solutions that allows an iPhone to use a smart card for authentication. And using smart cards always needs prior installation of smart card middleware. But one time passwords can be used whenever a password has to be entered. Some of our employees have a second token for generation of "guest-passwords". So using passwords generated by our OTP-tokens seemed to be the only way to go.
Most people solve the "guest account" problem by just putting guests into a different SSID / VLAN. It's a lot simpler, and has a better user experience.
Without two-factor authentication our employees must go to a central helpdesk, prove their identity by showing their identity card or passport, just to get a piece of paper with a password that allows WiFi acces for twelve hours only. If they forward this password to a guest, they have to fill out another piece of paper.
That is a terrible process. Likely invented by "security" people. i.e. people who understand enough about security to be dangerous, but not enough to be productive. If it's that important to control access to the network, then the network should be partitioned via VLANs, IPSec, etc. For example, Microsoft has a somewhat open corporate network, in that basic network access is controlled via EAP, etc. But that access doesn't really get you anything other than the ability to access the printers. All critical systems are secured via IPSec. So if someone needs access to a particular server, they create a machine-to-machine IPSec connection. The server can do authorization for that particular user / connection / machine. And that's a trillion-dollar corporation protecting billions of dollars in assets. I doubt that smaller companies need a higher level of security. The kind of "security" you describe here is BS security invented by people who have little to no understanding of real network security. It's about proving that they're doing "something" about security, without actually doing anything useful.
But there's no real reason why the ntlm_auth programm must be the Samba one. So I put
ntlm_auth = "/etc/radius/check_otp '%{mschap:User-Name}' '%{mschap:Challenge}' '%{mschap:NT-Response}' '%{Packet-SRC-IP-Address}'"
into mods-enabled/mschap and wrote my own "ntlm_auth"-style routine. It takes the username, challenge and a correct token values, calculates the response from these values and compares that with the given response.
That works... but it's a lot of effort. You could just set Cleartext-Password to be the value of the password + OTP, if it's cached. Then the mschap module would Just Work.
There are some pitfalls:
Most important: If a one time password turned out to be correct, it will be reused by the supplicant many times. And for obvious reasons you don't want to enter a new token value over and over again. Hence the check_otp routine must accept token values that were successfully used within the past for some amount of time. We use 12 hours for guests and I have to fight with the security staff about wether this can be increased for employees. Their main argument is, that a valid password might be given to other people. So I'm looking for a way to detect wether two supplicants are using the same user/password-combination. iOS MAC-randomization is my enemy here. Maybe someone has an idea how to do this.
Cache it somewhere in your script. But all of this is a huge amount of effort to work around a broken "security" process. No one else uses this kind of process for a reason: it's complex, awkward, has a bad user experience, and does little or nothing for security. Alan DeKok.