On 24 Feb 2015, at 09:09, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote:
th EAP-TTLS/PAP, the RADIUS server gets the plaintext password from the client, so can do whatever backend auth mechanism it likes...
I'm not thinking about security concerns handling plain passwords; we can be as protective about the RADIUS server as the Windows guys can be about their DCs, and the NTLM hash is nearly as good as plaintext anyway, hence the reason they may want to kill it off.
IMO, ensuring (as opposed to attempting) proper client setup is just too hard for PKIX-based systems in large organisations unless you spend a lot of money on a supplicant deployment tool. This sucks, and the supplicant/OS vendors need to get their shit together and fix cross-platform provisioning.
Agreed. EAP-TLS would be a lot nicer, but requires a lot more effort for on-boarding. We have enough complaints about the client setup processes as it is (and they really aren't that hard).
Basically, the state of EAP methods and provisioning sucks. It's a
It's the usual story with something "extensible". You end up having to run the lowest common denominator, which is probably
EAP-PWD seems like the perfect solution, except they don't have an extensible framework for password preprocessing. Seems like you either do no processing, NTLM type preprocessing, or UTF8 canonicalisation. There's no support for other hashing scheme. It seems like a massive oversight. Regarding LSA/SSPI, I was lead to believe by the Microsoft docs that LSA plugins could be called via the SSPI interface, with the SSPI interface being accessible from LDAP SASL binds. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2