10-05-2010 05:42 AM - edited 03-10-2019 05:28 PM
I have a test WLAN that I want to make domain users log onto with a domain user/pass but also force them to use the public key of a self-signed cert from the AAA server. At present I can get this to work, so for instance a windows client will connect to the WLAN if you set it to authenticate the server cert in the PEAP options. Unfortunatley I can't seem to prevent clients connecting who have a valid user/pass but don't set or can't set the cert to authenticate. This would enable staff who have say, an android or iPhone just to type in their user/pass combo and get an IP on the WLAN.
Can ACS be setup to refuse to service any clients who have not connected with the certificate?
Solved! Go to Solution.
10-05-2010 05:51 AM
The server side authentication by certificate done by PEAP is completely client side. This is an unfortunate reality and a good reason to implement things like group policy on desktops to prevent users from bypassing this security check. The problem is actually common to all technologies that rely on the certificate trust system. Who do you trust? What is the basis of your trust? It is all based on your list of trusted root certificate authorities which, in a Active Directory environment, can be controlled by policy.
The primary objective of the server authentication in PEAP is to validate the client is sending credentials to someone it trusts. If the client blindly decides to trust everyone, there is not much you can do. I am not sure of policy enforcement mechanisms similar to those available with active directory on iphone or other mobile devices.
Because PEAP primarily protects users from disclosing their passwords to a man in the middle, you could implement a security mechanism incorporating RSA tokens or some other technology that ensures the password will be useless if intercepted. Another option would be to provide a more open wireless connection that then require these devices to establish a VPN connection.
10-05-2010 05:51 AM
The server side authentication by certificate done by PEAP is completely client side. This is an unfortunate reality and a good reason to implement things like group policy on desktops to prevent users from bypassing this security check. The problem is actually common to all technologies that rely on the certificate trust system. Who do you trust? What is the basis of your trust? It is all based on your list of trusted root certificate authorities which, in a Active Directory environment, can be controlled by policy.
The primary objective of the server authentication in PEAP is to validate the client is sending credentials to someone it trusts. If the client blindly decides to trust everyone, there is not much you can do. I am not sure of policy enforcement mechanisms similar to those available with active directory on iphone or other mobile devices.
Because PEAP primarily protects users from disclosing their passwords to a man in the middle, you could implement a security mechanism incorporating RSA tokens or some other technology that ensures the password will be useless if intercepted. Another option would be to provide a more open wireless connection that then require these devices to establish a VPN connection.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide