Hopeman, Ward wrote: > This is where I got confused, I missed the foot notes that PEAPv1 was only > available in the experimental build with the eap2 module.
Yes. FR doesn't support PEAPv1 natively. >> Don't use PEAPv1. It's even less documented than PEAPv0. It's used by >> pretty much no one. > > This unfortunately is not by choice on my part. I am required to provide > lab setups for testing our products, based on what is in the product > requirement documents. This falls into what our product managers want to > support. I'm familiar with product managers. Unfortunately, all I can do here is to talk about reality. Product managers live in another world. >> Don't use LEAP. It's insecure. Don't put it into new products, and don't >> allow people to configure it. > > As above, not really my choice, but I can't agree more. Fortunately this > protocol seems to be for legacy support. I have been and continue to make > recommendations to our product managers to remove support for unused and > unsecure protocols. Adding LEAP is like saying "use insecure protocol that allows anyone to access my network." I think that's bad. Product managers don't care. > The client is not falling back to PEAPv0 as one might expect, and when I > questioned the developers on this they told me it was working as designed. > They want to ensure that when it gets configured for a specific protocol, > that it fails unless it meets the requirements. Since our products go into > controlled install environments, they wanted to tighten up the authentication > requirements. Not robust, or quite following the RFC, but as designed. In > this case refer above as the client was expecting v1. That makes sense. But it should be an option. > Again refer above, if I get eap2 module running with PEAPv1 support, it > should support both PEAPv0 and PEAPv1. I am assuming that configuring the > eap2 module should replace the eap module with regards to protocols (ie. > don't configure a protocol in both only in one or the other). It is a matter > of getting FR setup to support a higher level of PEAP using the eap2 module. > The protocol should then negotiate to the lower protocol if the client > requests PEAPv0 instead of PEAPv1. Be aware that the eap2 module has *minimal* integration with the rest of the server. The "inner-tunnel" virtual server won't work, etc. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html