@baboyero wrote:
If the radius accept does not have any attributes but the radius request does have some attributes...would that be a problem? How do we know what are the basic attributes that the RADIUS server must include in its radius accept message to the controller (is there a command we can type?)? I think there is a missing attribute (although there is no attribute at all coming from the RADIUS server) that is why the EAP SUCCESS message is not generated
Again, the radius server log is the key to most exchanges. To supplement that, I would do a packet capture of the radius traffic between the controller and the radius server. If the controller is not doing EAP termination, only the client and the radius server participate in that discussion, since a tunnel is built from the client to the radius server; that exchange is protected by a tunnel and is not seen by the controller, per se. The client and/or the radius server provide the most valuable clues as to the details of that exchange, which is not available through the controller interface.
Wikipedia: http://en.wikipedia.org/wiki/Protected_EAP
"PEAP is similar in design to EAP-TTLS, requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication, and uses server-side public key certificates to authenticate the server. It then creates an encrypted TLS tunnel between the client and the authentication server. In most configurations, the keys for this encryption are transported using the server's public key. The ensuing exchange of authentication information inside the tunnel to authenticate the client is then encrypted and user credentials are safe from eavesdropping."
This is just a long way of saying that you should try a AAA test server from the Aruba Controller, and if you can get that to work, it is normally a certificate issue that exists on the client/and or radius server.