-
User Guide for Cisco Secure ACS Solution Engine Version 3.3
-
Preface
-
Overview
-
Deployment Considerations
-
Interface Configuration
-
Network Configuration
-
Shared Profile Components
-
User Group Management
-
User Management
-
System Configuration: Basic
-
System Configuration: Advanced
-
System Configuration: Authentication and Certificates
-
Logs and Reports
-
Administrators and Administrative Policy
-
User Databases
-
Network Admission Control
-
Unknown User Policy
-
User Group Mapping and Specification
-
Troubleshooting
-
TACACS+ Attribute-Value Pairs
-
RADIUS Attributes
-
VPDN Processing
-
RDBMS Synchronization Import Definitions
-
Internal Architecture
-
Table Of Contents
System Configuration: Authentication and Certificates
About Certification and EAP Protocols
Enabling EAP-TLS Authentication
PEAP and the Unknown User Policy
Authentication Configuration Options
Configuring Authentication Options
Cisco Secure ACS Certificate Setup
Installing a Cisco Secure ACS Certificate
Adding a Certificate Authority Certificate
Editing the Certificate Trust List
Managing Certificate Revocation Lists
About Certificate Revocation Lists
Certificate Revocation List Configuration Options
Adding a Certificate Revocation List Issuer
Editing a Certificate Revocation List Issuer
Deleting a Certificate Revocation List Issuer
Generating a Certificate Signing Request
Using Self-Signed Certificates
About Self-Signed Certificates
Self-Signed Certificate Configuration Options
Generating a Self-Signed Certificate
Updating or Replacing a Cisco Secure ACS Certificate
System Configuration: Authentication and Certificates
This chapter addresses authentication and certification features found in the System Configuration section of Cisco Secure ACS Solution Engine.
This chapter contains the following topics:
•
About Certification and EAP Protocols
•
•
About Certification and EAP Protocols
Cisco Secure ACS uses EAP-TLS and PEAP authentication protocols in combination with digital certification to ensure the protection and validity of authentication information. Digital certification, EAP-TLS, PEAP, and machine authentication are described in the topics that follow.
This section contains the following topics:
Digital Certificates
The ACS Certificate Setup pages enable you to install digital certificates to support EAP-TLS and PEAP authentication, as well as to support HTTPS protocol for secure access to the Cisco Secure ACS HTML interface. Cisco Secure ACS uses the X.509 v3 digital certificate standard. Certificate files must be in either Base64-encoded X.509 format or DER-encoded binary X.509 format. Also, Cisco Secure ACS supports manual certificate enrollment and provides the means for managing a certificate trust list (CTL) and certificate revocation lists (CRL).
Digital certificates do not require the sharing of secrets or stored database credentials. They can be scaled and trusted over large deployments. If managed properly, they can serve as a method of authentication that is stronger and more secure than shared secret systems. Mutual trust requires that Cisco Secure ACS have an installed certificate that can be verified by end-user clients. This server certificate may be issued from a certification authority (CA) or, if you choose, may be a self-signed certificate. For more information seeInstalling a Cisco Secure ACS Certificate, and Using Self-Signed Certificates.
Note
EAP-TLS Authentication
This section contains the following topics:
•
About the EAP-TLS Protocol
EAP and TLS are both IETF RFC standards. The EAP protocol carries initial authentication information, specifically EAPOL (the encapsulation of EAP over LANs as established by IEEE 802.1X). TLS uses certificates both for user authentication and for dynamic ephemeral session key generation. The EAP-TLS authentication protocol uses the certificates of Cisco Secure ACS and of the end-user client, enforcing mutual authentication of the client and of Cisco Secure ACS. For more detailed information on EAP, TLS, and EAP-TLS, refer to the following IETF RFCs: PPP Extensible Authentication Protocol (EAP) RFC 2284, The TLS Protocol RFC 2246, and PPP EAP TLS Authentication Protocol RFC 2716.
EAP-TLS authentication involves two elements of trust. The first element of trust is when the EAP-TLS negotiation establishes end-user trust by validating, through RSA signature verifications, that the user possesses a keypair signed by a certificate. This verifies that the end user is the legitimate keyholder for a given digital certificate and the corresponding user identification contained in the certificate. However, trusting that a user possesses a certificate only provides a username/keypair binding. The second element of trust is to use a third-party signature, usually from a certification authority (CA), that verifies the information in a certificate. This third-party binding is similar to the real world equivalent of the seal on a passport. You trust the passport because you trust the preparation and identity checking that the particular country's passport office made when creating that passport. You trust digital certificates by installing the root certificate CA signature.
Some situations do not require this "second element of trust" that is provided by installing the root certificate CA signature. When such external validation of certificate legitimacy is not required, you can use the Cisco Secure ACS self-signed certificate capability. Depending on the end-user client involved, 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. For more information, see About Self-Signed Certificates.
EAP-TLS requires support from both the end client and the AAA client. An example of an EAP-TLS client includes the Microsoft Windows XP operating system; EAP-TLS-compliant AAA clients include Cisco 802.1x-enabled switch platforms (such as the Catalyst 6500 product line) and Cisco Aironet Wireless solutions. To accomplish secure Cisco Aironet connectivity, EAP-TLS generates a dynamic, per-user, per-connection, unique session key.
EAP-TLS and Cisco Secure ACS
Cisco Secure ACS supports EAP-TLS with any end-user client that supports EAP-TLS, such as Windows XP. To learn which user databases support EAP-TLS, see Authentication Protocol-Database Compatibility. For more information about deploying EAP-TLS authentication, see Extensible Authentication Protocol Transport Layer Security Deployment Guide for Wireless LAN Networks at http://www.cisco.com/warp/public/cc/pd/sqsw/sq/tech/
acstl_wp.htm.Cisco Secure ACS can use EAP-TLS to support machine authentication to Microsoft Windows Active Directory. The end-user client may limit the protocol used for user authentication to the same protocol used for machine authentication; that is, use of EAP-TLS for machine authentication may require the use of EAP-TLS for user authentication. For more information about machine authentication, see Machine Authentication.
Cisco Secure ACS supports domain stripping for EAP-TLS authentication using Windows Active Directory. For more information, see EAP-TLS Domain Stripping.
Cisco Secure ACS also supports three methods of certificate comparison and a session resume feature. This topic discusses these features.
To permit access to the network by a user or computer authenticating with EAP-TLS, Cisco Secure ACS must verify that the claimed identity (presented in the EAP Identity response) corresponds to the certificate presented by the user. Cisco Secure ACS can accomplish this verification in three ways:
•
•
•
Note
When you set up EAP-TLS, you can select the criterion (one, two, or all) that Cisco Secure ACS uses. For more information, see Configuring Authentication Options.
Cisco Secure ACS supports a session resume feature for EAP-TLS-authenticated user sessions, a particularly useful feature for WLANs, wherein a user may move the client computer so that a different wireless access point is in use. When this feature is enabled, Cisco Secure ACS caches the TLS session created during EAP-TLS authentication, provided that the user successfully authenticates. If a user needs to reconnect and the original EAP-TLS session has not timed out, Cisco Secure ACS uses the cached TLS session, resulting in faster EAP-TLS performance and lessened AAA server load. When Cisco Secure ACS resumes an EAP-TLS session, the user reauthenticates by SSL handshake only, without a certificate comparison.
In effect, enabling EAP-TLS session resume allows Cisco Secure ACS to trust a user based on the cached TLS session from the original EAP-TLS authentication. Because Cisco Secure ACS only caches a TLS session when a new EAP-TLS authentication succeeds, the existence of a cached TLS session is proof that the user has successfully authenticated within the number of minutes defined by the EAP-TLS session timeout option.
Note
Changes to group assignment in an external user database are not enforced by the session resume feature. This is because group mapping does not occur when a user session is resumed. Instead, the user is mapped to the same Cisco Secure ACS group that the user was mapped to upon the beginning of the session. Upon the start of a new session, group mapping enforces the new group assignment.
To force an EAP-TLS session to end before the session timeout is reached, either restart the CSAuth service or delete the user from the CiscoSecure user database CiscoSecure user database. Disabling or deleting the user in an external user database has no effect because the session resume feature does not involve the use of external user databases.
You can enable the EAP-TLS session resume feature and configure the timeout interval on the Global Authentication Setup page. For more information about enabling this feature, see Global Authentication Setup.
EAP-TLS Limitations
The Cisco Secure ACS implementation of EAP-TLS has the following limitations:
•
•
Enabling EAP-TLS Authentication
This procedure provides an overview of the detailed procedures required to configure Cisco Secure ACS to support EAP-TLS authentication.
Note
acstl_wp.htm.Before You Begin
For EAP-TLS machine authentication, if you have a Microsoft certification authority server configured on the domain controller, you can configure a policy in Active Directory to produce a client certificate automatically when a computer is added to the domain. For more information, see Microsoft Knowledge Base
Article 313407, HOW TO: Create Automatic Certificate Requests with Group
Policy in Windows.To enable EAP-TLS authentication, follow these steps:
Step 1
Note
Step 2
Step 3
Step 4
Step 5
Cisco Secure ACS is ready to perform EAP-TLS authentication.
PEAP Authentication
This section contains the following topics:
•
About the PEAP Protocol
The PEAP (Protected EAP) protocol is a client-server security architecture that provides a means of encrypting EAP transactions, thereby protecting the contents of EAP authentications. PEAP has been posted as an IETF Internet Draft by RSA, Cisco, and Microsoft and is available at http://www.ietf.org/internet-drafts/
draft-josefsson-pppext-eap-tls-eap-05.txt.PEAP authentications always involve 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, ensuring 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. The first phase uses a TLS handshake to establish an SSL tunnel.
Note
In phase two, Cisco Secure ACS authenticates the user or machine credentials using an EAP authentication protocol. The EAP authentication is protected by the SSL tunnel created in phase one. The authentication type negotiated during the second conversation may be any valid EAP type, such as EAP-GTC (for Generic Token Card). Because PEAP can support any EAP authentication protocol, individual combinations of PEAP and EAP protocols are denoted with the EAP protocol within parentheses, such as PEAP(EAP-GTC). For the authentication protocols that Cisco Secure ACS supports in phase two of PEAP, see Authentication Protocol-Database Compatibility.
One improvement in security offered by PEAP is identity protection. This is the potential of protecting the username in all PEAP transactions. After phase one of PEAP, all data is encrypted, including username information usually sent in clear text. The Cisco Aironet PEAP client sends user identity through the SSL tunnel only. The initial identity, used in phase one and which is sent in the clear, is the MAC address of the end-user client with "PEAP_" as a prefix. The Microsoft PEAP client does not provide identity protection; the Microsoft PEAP client sends the username in the clear in phase one of PEAP authentication.
PEAP and Cisco Secure ACS
Cisco Secure ACS supports PEAP authentication using either the Cisco Aironet PEAP client or the Microsoft PEAP client included with Microsoft Windows XP Service Pack 1. Cisco Secure ACS can support the Cisco Aironet PEAP client with PEAP(EAP-GTC) only. For the Microsoft PEAP client included with Windows XP Service Pack 1, Cisco Secure ACS supports only PEAP(EAP-MSCHAPv2). For information about which user databases support PEAP protocols, see Authentication Protocol-Database Compatibility.
When the end-user client is the Cisco Aironet PEAP client and both PEAP(EAP-GTC) and PEAP(EAP-MSCHAPv2) are enabled on the Global Authentication Setup page, Cisco Secure ACS first attempts PEAP(EAP-GTC) authentication with the end-user client. If the client rejects this protocol (by sending an EAP NAK message), Cisco Secure ACS attempts authentication with PEAP(EAP-MSCHAPv2). For more information about enabling EAP protocols supported within PEAP, see Global Authentication Setup.
Cisco Secure ACS can use PEAP(EAP-MSCHAPv2) to support machine authentication to Microsoft Windows Active Directory. The end-user client may limit the protocol used for user authentication to the same protocol used for machine authentication; that is, use of PEAP for machine authentication requires the use of PEAP for user authentication. For more information about machine authentication, see Machine Authentication.
Cisco Secure ACS supports a session resume feature for PEAP-authenticated user sessions. When this feature is enabled, Cisco Secure ACS caches the TLS session created during phase one of PEAP authentication, provided that the user successfully authenticates in phase two of PEAP. If a user needs to reconnect and the original PEAP session has not timed out, Cisco Secure ACS uses the cached TLS session, resulting in faster PEAP performance and lessened AAA server load.
Note
You can enable the PEAP session resume feature and configure the timeout interval on the Global Authentication Setup page. For more information about enabling this feature, see Global Authentication Setup.
Cisco Secure ACS also supports a fast reconnect feature. When the session resume feature is enabled, the fast reconnection feature causes Cisco Secure ACS to allow a PEAP session to resume without checking user credentials. In effect, enabling this feature allows Cisco Secure ACS to trust a user based on the cached TLS session from the original PEAP authentication. Because Cisco Secure ACS only caches a TLS session when phase two of PEAP authentication succeeds, the existence of a cached TLS session is proof that the user has successfully authenticated within the number of minutes defined by the PEAP session timeout option.
Changes to group assignment in an external user database are not enforced by the session resume feature. This is because group mapping does not occur when a user session is extended by the session resume feature. Instead, the user is mapped to the same Cisco Secure ACS group that the user was mapped to upon the beginning of the session. Upon the start of a new session, group mapping enforces the new group assignment.
The fast reconnect feature is particularly useful for wireless LANs, wherein a user may move the client computer so that a different wireless access point is in use. When Cisco Secure ACS resumes a PEAP session, the user reauthenticates without entering a password, provided that the session has not timed out. If the end-user client is restarted, the user must enter a password even if the session timeout interval has not ended.
You can enable the PEAP fast reconnect feature on the Global Authentication Setup page. For more information about enabling this feature, see Global Authentication Setup.
PEAP and the Unknown User Policy
During PEAP authentication, the real username to be authenticated may not be known by Cisco Secure ACS until phase two of authentication. While the Microsoft PEAP client does reveal the actual username during phase one, the Cisco PEAP client does not; therefore, Cisco Secure ACS does not attempt to look up the username presented during phase one and the use of the Unknown User Policy is irrelevant during phase one, regardless of the PEAP client used.
When phase two of PEAP authentication occurs and the username presented by the PEAP client is unknown to Cisco Secure ACS, Cisco Secure ACS processes the username in the same way that it processes usernames presented in other authentication protocols. If the username is unknown and the Unknown User Policy is disabled, authentication fails. If the username is unknown and the Unknown User Policy is enabled, Cisco Secure ACS attempts to authenticate the PEAP user with unknown user processing.
For more information about unknown user processing, see About Unknown User Authentication.
Enabling PEAP Authentication
This procedure provides an overview of the detailed procedures required to configure Cisco Secure ACS to support PEAP authentication.
Note
To enable PEAP authentication, follow these steps:
Step 1
Note
Step 2
Step 3
Cisco Secure ACS is ready to perform PEAP authentication for most users. For more information, see PEAP and the Unknown User Policy.
Step 4
EAP-FAST Authentication
This section contains the following topics:
About EAP-FAST
The EAP Flexible Authentication via Secured Tunnel (EAP-FAST) protocol is a client-server security architecture that encrypts EAP transactions with a TLS tunnel. While similar to PEAP in this respect, it differs significantly in that EAP-FAST tunnel establishment is based upon strong secrets that are unique to users. These secrets are called Protected Access Credentials (PACs), which Cisco Secure ACS generates using a master key known only to Cisco Secure ACS. Because handshakes based upon shared secrets are intrinsically faster than handshakes based upon PKI, EAP-FAST is the significantly faster of the two solutions that provide encrypted EAP transactions. No certificate management is required to implement EAP-FAST.
EAP-FAST occurs in three phases:
•
Note
No network service is enabled by phase zero of EAP-FAST; therefore, even a successful EAP-FAST phase zero transaction is recorded in the Cisco Secure ACS Failed Attempts log.
•
No network service is enabled by phase one of EAP-FAST.
•
Cisco Secure ACS authorizes network service with a successful user authentication in phase two of EAP-FAST and logs the authentication in the Passed Authentications log, if it is enabled. Also, if necessary, Cisco Secure ACS may refresh the end-user client PAC, which creates a second entry in the Passed Authentication log for the same phase two transaction.
EAP-FAST can protect the username in all EAP-FAST transactions. Cisco Secure ACS does not perform user authentication based on a username presented in phase one; however, whether the username is protected during phase one depends upon the end-user client. If the end-user client does not send the real username in phase one, the username is protected. The Cisco Aironet EAP-FAST client protects the username in phase one by sending
FAST_MAC address in place of the username. After phase one of EAP-FAST, all data is encrypted, including username information usually sent in clear text.Cisco Secure ACS supports password aging with EAP-FAST for users authenticated by Windows user databases. Password aging can work with either phase zero or phase two of EAP-FAST. If password aging requires a user to change passwords during phase zero, the new password would be effective in phase two. For more information about password aging for Windows user databases, see Enabling Password Aging for Users in Windows Databases.
About Master Keys
EAP-FAST master keys are strong secrets that Cisco Secure ACS automatically generates and that only Cisco Secure ACS is aware of. Master keys are never sent to an end-user client. EAP-FAST requires master keys for two purposes:
•
•
To increase the security of EAP-FAST, Cisco Secure ACS changes the master key that it uses to generate PACs. Cisco Secure ACS uses time-to-live (TTL) values you define to determine when it generates a new master key and to determine the age of all master keys. Based on TTL values, Cisco Secure ACS assigns master keys one of the three following states:
•
When Cisco Secure ACS is configured to receive replicated EAP-FAST policies and master keys, a backup master key is among the master keys received. The backup master key is used only if the active master key retires before the next successful master key replication. If the backup master key also retires before the next successful master key replication, EAP-FAST authentication fails for all users requesting network access with EAP-FAST.
Tip
Cisco Secure ACS records the generation of master keys in the logs for the CSAuth service.
•
When a user gains network access using a PAC generated with a retired master key, Cisco Secure ACS provides the end-user client a new PAC generated with the active master key. For more information about Cisco Secure ACS with respect to the states of master keys and PACs, see Master Key and PAC TTLs.
•
PACs generated by an expired master key cannot be used to access your network. An end-user client presenting a PAC that was generated with an expired master key must be provided a new PAC using automatic or manual provisioning before phase one of EAP-FAST can succeed.
About PACs
PACs are strong shared secrets that enable Cisco Secure ACS and an EAP-FAST end-user client to authenticate each other and establish a TLS tunnel for use in EAP-FAST phase two. Cisco Secure ACS generates PACs using the active master key and a username. An EAP-FAST end-user client stores PACs for each user accessing the network with the client. Additionally, a AAA server that supports EAP-FAST has a unique Authority ID. An end-user client associates a user's PACs with the Authority ID of the AAA server that generated them.
During EAP-FAST phase one, the end-user client presents the PAC that it has for the current user and for the Authority ID sent by Cisco Secure ACS at the beginning of the EAP-FAST transaction. Cisco Secure ACS determines whether the PAC was generated using one of the master keys it is aware of, either active or retired (a PAC generated using a master key that has since expired can never be used to gain network access). When an end-user client has a PAC generated with an expired master key, the end-user client must receive a new PAC before EAP-FAST phase one can succeed. The means of providing PACs to end-user clients, known as PAC provisioning, are discussed in Automatic PAC Provisioning, and Manual PAC Provisioning.
After end-user clients are provided PACs, Cisco Secure ACS refreshes them as dictated by master key and PAC TTL values. Cisco Secure ACS generates and sends a new PAC as needed at the end of phase two of EAP-FAST; however, if you shorten the master key TTL, you may in effect be requiring PAC provisioning to occur. For more information about how master key and PAC states determine whether Cisco Secure ACS sends a new PAC to the end-user client at the end of phase two, see Master Key and PAC TTLs.
Regardless of the master key TTL values you define, a user will require PAC provisioning when the user does not use EAP-FAST to access the network before the master key used to generate the user's PAC has expired. For example, if the master key TTL is one week and the retired master key TTL is one week, each EAP-FAST end-user client used by someone who goes on vacation for two weeks will require PAC provisioning.
The following list contrasts the various means by which an end-user client can receive PACs:
•
Two means of PAC provisioning are supported:
–
–
•
PACs have the following two states, determined by the PAC TTL setting:
•
•
Automatic PAC Provisioning
Automatic PAC provisioning sends a new PAC to an end-user client over a secured network connection. Automatic PAC provisioning requires no intervention of the network user or a Cisco Secure ACS administrator, provided that both Cisco Secure ACS and the end-user client are configured to support automatic provisioning.
EAP-FAST phase zero requires EAP-MSCHAPv2 authentication of the user. Upon successful user authentication, Cisco Secure ACS establishes a Diffie-Hellman tunnel with the end-user client. Cisco Secure ACS generates a PAC for the user and sends it to the end-user client within this tunnel, along with the Authority ID and Authority ID information about this Cisco Secure ACS.
Note
No network service is enabled by phase zero of EAP-FAST; therefore, Cisco Secure ACS logs a EAP-FAST phase zero transaction in the Failed Attempts log, including an entry that PAC provisioning occurred. After the end-user client has received a PAC through a successful phase zero, it sends a new EAP-FAST request to begin phase one.
Note
To control whether Cisco Secure ACS performs automatic PAC provisioning, you use the options on the Global Authentication Setup page in the System Configuration section. For more information, see Authentication Configuration Options.
Manual PAC Provisioning
Manual PAC provisioning requires a Cisco Secure ACS administrator to generate PAC files, which must then be distributed to the applicable network users. Users must configure end-user clients with their PAC files. For example, if your EAP-FAST end-user client is the Cisco Aironet Client Utility (ACU), configuring the ACU to support EAP-FAST requires that you import a PAC file. For more information about configuring a Cisco ACU, see the applicable configuration guide for your ACU.
You can use manual PAC provisioning to control who can use EAP-FAST to access your network. If you disable automatic PAC provisioning, any EAP-FAST user denied a PAC cannot access the network. If your Cisco Secure ACS deployment includes network segmentation wherein access to each network segment is controlled by a separate Cisco Secure ACS, manual PAC provisioning enables you to grant EAP-FAST access on a per-segment basis. For example, if your company uses EAP-FAST for wireless access in its Chicago and Boston offices and the Cisco Aironet Access Points at each of these two offices are configured to use different Cisco Secure ACSes, you can determine, on a per-employee basis, whether Boston employees visiting the Chicago office can have wireless access.
Note
While the administrative overhead of manual PAC provisioning is much greater than automatic PAC provisioning, it does not include the risk of sending the PAC over the network. When you first deploy EAP-FAST, using manual PAC provisioning would require a lot of manual configuration of end-user clients; however, it is the most secure means for distributing PACs. We recommend that, after a large EAP-FAST deployment, PAC provisioning should be performed manually to ensure the highest security for PACs.
You can generate PAC files for specific users, groups of users, lists of users, or all users. When you generate PAC files for groups of users or all users, the users must be known or discovered users and cannot be unknown users. Cisco Secure ACS Solution Engine supports the generation of PAC files in its HTML interface. For more information about generating PAC files, see EAP-FAST PAC Files Generation.
Master Key and PAC TTLs
The TTL values for master keys and PACs determine their states, as described in About Master Keys, and About PACs. Master key and PAC states determine whether someone requesting network access with EAP-FAST requires PAC provisioning or PAC refreshing. Table 10-1 summarizes Cisco Secure ACS behavior with respect to PAC and master key states.
Replication and EAP-FAST
The CiscoSecure Database Replication feature supports the replication of EAP-FAST settings, Authority ID, and master keys. Replication of EAP-FAST data occurs only if the following are true:
•
•
•
•
EAP-FAST-related replication occurs for three events:
•
•
Note
•
The Database Replication log on the primary Cisco Secure ACS records replication of master keys. Entries related to master key replication contain the text "MKEYReplicate".
The EAP-FAST master server setting has a significant effect upon EAP-FAST authentication and replication, as follows:
•
Masterand Cisco Secure ACS ignores the EAP-FAST settings, Authority ID, and master keys it receives from a primary Cisco Secure ACS during replication, preferring instead to use master keys it generates, its unique Authority ID, and the EAP-FAST settings configured in its HTML interface.Enabling the EAP-FAST master server setting requires providing for the end-user client a PAC from the primary Cisco Secure ACS that is different than the PAC from the secondary Cisco Secure ACS. Because the primary and secondary Cisco Secure ACSes send different Authority IDs at the beginning of the EAP-FAST transaction, the end-user client must have a PAC for each Authority ID. A PAC generated by the primary Cisco Secure ACS is not accepted by the secondary Cisco Secure ACS in a replication scheme where the EAP-FAST master server setting is enabled on the secondary Cisco Secure ACS.
Tip
•
Slave, Cisco Secure ACS uses the EAP-FAST settings, Authority ID, and master keys it receives from a primary Cisco Secure ACS during replication, rather than using master keys it generates and its unique Authority ID.
Note
Masteruntil Cisco Secure ACS receives replicated EAP-FAST components and then the "Actual EAP-FAST server status" changes toSlave. Until "Actual EAP-FAST server status" changes toSlave, Cisco Secure ACS acts as a master EAP-FAST server, using master keys it generates, its unique Authority ID, and the EAP-FAST settings configured in its HTML interface.Disabling the EAP-FAST master server setting eliminates the need for providing a different PAC from the primary and secondary Cisco Secure ACSes. This is because the primary and secondary Cisco Secure ACSes send the end-user client the same Authority ID at the beginning of the EAP-FAST transaction; therefore, the end-user client uses the same PAC in its response to either Cisco Secure ACS. Also, a PAC generated for a user by one Cisco Secure ACS in a replication scheme where the EAP-FAST master server setting is disabled is accepted by all other Cisco Secure ACSes in the same replication scheme.
For more information about replication, see CiscoSecure Database Replication.
Enabling EAP-FAST
This procedure provides an overview of the detailed procedures required to configure Cisco Secure ACS to support EAP-FAST authentication.
Note
Before You Begin
The steps in this procedure are a suggested order only. Enabling EAP-FAST at your site may require recursion of these steps or performing these steps in a different order. For example, in this procedure, determining how you want to support PAC provisioning comes after configuring a user database to support EAP-FAST; however, choosing automatic PAC provisioning places different limits upon user database support.
To enable Cisco Secure ACS to perform EAP-FAST authentication, follow these steps:
Step 1
Note
Cisco Secure ACS supports use of the Unknown User Policy and group mapping with EAP-FAST, as well as password aging with Windows external user databases.
Step 2
Also, if you reduce the TTL values that you initially deploy EAP-FAST with, you may force PAC provisioning to occur because users would be more likely to have PACs based on expired master keys.
For information about how master key and PAC TTL values determine whether PAC provisioning or PAC refreshing is required, see Master Key and PAC TTLs.
Step 3
Note
Step 4
Cisco Secure ACS is ready to perform EAP-FAST authentication.
Global Authentication Setup
The Global Authentication Setup page provides a means to enable or disable some of the authentication protocols supported by Cisco Secure ACS. You can also configure other options for some of the protocols represented on the Global Authentication Setup page.
This section contains the following topics:
•
•
Authentication Configuration Options
The Global Authentication Setup page contains the following configuration options:
•
–
Note
–
–
–
–
Fast reconnection can occur only when Cisco Secure ACS allows the session to resume because the session has not timed out. If you disable the PEAP session resume feature by entering 0 (zero) in the PEAP session timeout (minutes) box, selecting the Enable Fast Reconnect check box has no effect on PEAP authentication and phase two of PEAP authentication always occurs.
•
–
Note
–
Note
For more information about master keys, see About Master Keys.
–
When a retired master key ages past the retired master key TTL, it expires and Cisco Secure ACS deletes it.
Note
Note
For more information about master keys, see About Master Keys.
–
For more information about PACs, see About PACs.
–
Note
–
Note
–
–
When this check box is selected, Cisco Secure ACS uses its own EAP-FAST policies, Authority ID, and master keys. For more information, see Replication and EAP-FAST.
Note
–
Tip
•
–
Note
–
Note
–
–
–
•
Note
•
•
During EAP conversations, Cisco Secure ACS sends the value defined in the AP EAP request timeout box using the IETF RADIUS Session-Timeout (27) attribute; however, in the RADIUS Access-Accept packet at the end of the conversation, the value that Cisco Secure ACS sends in the IETF RADIUS Session-Timeout (27) attribute is the value specified in the Cisco Aironet RADIUS VSA Cisco-Aironet-Session-Timeout (01) or, if that attribute is not enabled, the IETF RADIUS Session-Timeout (27) attribute.
Note
•
Note
Configuring Authentication Options
Use this procedure to select and configure how Cisco Secure ACS handles options for authentication. In particular, use this procedure to specify and configure the varieties of EAP that you allow, and to specify whether you allow either MS-CHAP Version 1 or MS-CHAP Version 2, or both.
For more information on the EAP-TLS Protocol, see EAP-TLS Authentication. For more information on the PEAP protocol, see PEAP Authentication. For more information on the PEAP protocol, see EAP-FAST Authentication. For details regarding how various password protocols are supported by the various databases, see Authentication Protocol-Database Compatibility.
Before You Begin
For information about the options on the Global Authentication Setup page, see Authentication Configuration Options.
To configure authentication options, follow these steps:
Step 1
Step 2
Cisco Secure ACS displays the Global Authentication Setup page.
Step 3
Step 4
Cisco Secure ACS restarts its services and implements the authentication configuration options you selected.
Step 5
Tip
Cisco Secure ACS saves the authentication configuration options you selected.
Cisco Secure ACS Certificate Setup
This section contains the following topics:
•
•
•
•
•
•
•
Installing a Cisco Secure ACS Certificate
Perform this procedure to install (that is, enroll) a Cisco Secure ACS certificate. You can perform certificate enrollment to support EAP-TLS and PEAP authentication, as well as HTTPS protocol for GUI access to Cisco Secure ACS.
If you are installing a server certificate that replaces an existing server certificate, the installation could affect the configuration of the CTL and CRL settings your Cisco Secure ACS. After you have installed a replacement certificate, you should determine whether you need to reconfigure any CTL or CRL settings.
Before You Begin
You must have a server certificate for your Cisco Secure ACS before you can install it. With Cisco Secure ACS, certificate files must be in Base64-encoded X.509. You can use the procedure in Generating a Certificate Signing Request, or any other means to obtain a certificate for installation.
To install an existing certificate for use on Cisco Secure ACS, follow these steps:
Step 1
Step 2
Step 3
Cisco Secure ACS displays the Install new certificate table on the Install ACS Certificate page.
Step 4
The Download Certificate File page appears.
Step 5
a.
Tip
