This provides the configuration guidelines for the Cisco Secure Access Control Server (ACS).
In case of Protected Extensible Authentication Protocol (PEAP), certificates are used in order to validate the server. The use of the root certificate on the client is only limited to the validation of the server. When the validate server certificate option is unchecked on the client, it does not try to validate the server, and the server is authenticated without any validation. But, when the option is checked, it explicitly checks for the root certificate on the client in order to validate the server.
Once the server is authenticated, the manner in which PEAP works remains the same in both the cases. For example, whether the validate server certificate is checked or unchecked, it is possible to install the root CA on each client or do not do so.
PEAP works in these two phases:
In the first phase, the end-user client authenticates Cisco Secure ACS. This requires a server certificate and authenticates Cisco Secure ACS to the end-user client, which ensures that the user or machine credentials sent in phase two are sent to a AAA server that has a certificate issued by a trusted CA. If the validate server certificate option is checked, the CA certificate for the CA that issued the Cisco Secure ACS server certificate is likely to be required in local storage for trusted root CAs on the end-user client computer. The first phase uses a TLS handshake in order to establish a Secure Socket Layer (SSL) tunnel.
In phase two, Cisco Secure ACS authenticates the user or machine credentials with an EAP authentication protocol. The EAP authentication is protected by the SSL tunnel that is created in phase one.
Since data encryption takes place with the SSL in PEAP, there is no way to see the use of certificates in case of PEAP authentication.
Note: In order to avoid a Man in the middle attack, configure this with validate server certificate checked.
In order to make use of the validate server certificate option, install Root CA and Intermediate CA both on the ACS server and on each client.
While it is installed on the client, save Root CA to the Root CA store and store the Intermediate CA at the Subordinate CA store location.
I've setup "AAA and Certificate" for tunnel group and import Root CA into CA certificate on the ASA.I also setup "CertificateStore" as "Machine" and enable "CertificateStoreOverride" on the client profile. According to the debug result, the VPN ...
I have situation, that on the active device of FMMS the admin context is faulty and it has hell lot configuration missing, can not login to it. On the Secondary Device firewall Admin context is fine. --------------------------------The version is:On ...
For a customer I'm trying to come up with a dynamic solution to configure a fabric switchport with a static access VLAN in support of their Wake-on-LAN based desktop support processes. Specifically, DNAC v126.96.36.199 introduces support for Subnet Directe...
Hi Everybody,Maybe this subject was already discussed and a solution exist, but a could find it in any discussion.I setup a site to site VPN between 2 sites ( HQ_ASA <--- VPN ---> Site_ASA). the inside subnet for each site is nated before reaching t...
Hi community!Faced the issue with connecting into Standby node of FO ASA cluster. The problem description:- when I try to connect via SSH to the Standby node I always getting the message "Remote side unexpectedly closed network connection";- when I c...