On Sep 11, 2019, at 6:22 PM, ngoetz24@gmail.com wrote:
The reason I think the issue is caused by something I misconfigured, and not a supplicant issue, is because the supplicant seems to be getting an access accept from RADIUIS which is why it is letting the user in instead of prompting them for the OTP.
Then that's how the supplicant works. The behaviour of supplicants is magical and mysterious, unlike FreeRADIUS. i.e. supplicants have near-zero debugging output.
When I look at the debug it seems like it is setting the OTP Challenge Message first (as configed is eap config), then pressing the original request through ntlm_auth, and if ntlm_auth succeeds it sends a access accept back to the supplicant. Unless I am misunderstanding something, shouldn't the radius not send an access accept back to the supplicant unless all the auth conditions are met?
EAP-GTC provides for a prompt and a reply, it doesn't provide for multiple rounds of challenge-response.
The part I seem to be missing is where do I configure the radius server to require a second factor? In PAP I set this by returning an Access-Challenge in the authenticate section. Since this doesn't work the same way in PEAP-GTC, I seem to be missing some part of the config that tells it to request the second factor. Am I just misunderstanding how this works?
Nope. EAP-GTC does challenge / response, but not *multiple* rounds of challenge-response. If you want multiple rounds of challenge-response, use PAP. Or, do what everyone else does, and tell people to enter a 6-digit OTP followed by their password, all as one field. FreeRADIUS can then split that into two fields, and check OTP and "real" password separately. The issue is that FreeRADIUS can do just about anything, BUT it's limited by (a) the protocols, and (b) the client implementations (supplicant / whatever). If the protocols and/or supplicants don't support something, then no amount of poking FreeADIUS will make it work. i.e. for a conversation to work, *all* parties to the conversation must cooperate. Your main solution here is to use PAP. Again, tell your "security" people that they're incompetent, and that their fears are not based in reality. Your choices right now are largely; a) not use OTP b) use PAP A naive and dogmatic approach to security is wrong. It's done only by the incompetent and/or inexperienced. Alan DeKok.