User Guide for Cisco Secure ACS Appliance 3.2
System Configuration: Authentication and Certificates

Table Of Contents

System Configuration: Authentication and Certificates

About Certification and EAP Protocols

Digital Certificates

EAP-TLS Authentication

PEAP Authentication

EAP-FAST Authentication

Global Authentication Setup

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

Generating a Certificate Signing Request

Updating or Replacing a Cisco Secure ACS Certificate

EAP-FAST PAC Files Generation

PAC File Generation Options

Generating PAC Files

System Configuration: Authentication and Certificates


This chapter addresses authentication and certification features found in the System Configuration section of CiscoSecure ACS Appliance.

This chapter contains the following topics:

About Certification and EAP Protocols

Global Authentication Setup

CiscoSecure ACS Certificate Setup

EAP-FAST PAC Files Generation

About Certification and EAP Protocols

CiscoSecure 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

EAP-TLS Authentication

PEAP Authentication

EAP-FAST Authentication

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 CiscoSecure ACS HTML interface. CiscoSecure 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, CiscoSecure ACS supports manual certificate enrollment.

Digital certificates do not require the sharing of secrets nor 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 CiscoSecure ACS have an installed certificate that can be verified by end-user clients.

EAP-TLS Authentication

This section contains the following topics:

About the EAP-TLS Protocol

EAP-TLS and CiscoSecure ACS

EAP-TLS Limitations

Enabling EAP-TLS Authentication

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 CiscoSecure ACS and of the end-user client, enforcing mutual authentication of the client and of CiscoSecure 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.

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

CiscoSecure 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.

CiscoSecure 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.

CiscoSecure ACS supports domain stripping for EAP-TLS authentication using Windows Active Directory. For more information, see EAP-TLS Domain Stripping.

CiscoSecure 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, CiscoSecure ACS must verify that the claimed identity (presented in the EAP Identity response) corresponds to the certificate presented by the user. CiscoSecure ACS can accomplish this verification in three ways:

Certificate SAN Comparison —Based on the name in the Subject Alternative Name field in the user certificate.

Certificate CN Comparison —Based on the name in the Subject Common Name field in the user certificate.

Certificate Binary Comparison —Based on a binary comparison between the user certificate stored in the user object in the LDAP server or Active Directory and the certificate presented by the user during EAP-TLS authentication. This comparison method cannot be used to authenticate users stored in an ODBC external user database.


Note If you use certificate binary comparison, the user certificate must be stored in a binary format. Also, for generic LDAP and Active Directory, the attribute storing the certificate must be the standard LDAP attribute named "usercertificate".


When you set up EAP-TLS, you can select the criterion (one, two, or all) that CiscoSecure ACS uses. For more information, see Configuring Authentication Options.

CiscoSecure 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, CiscoSecure 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, CiscoSecure ACS uses the cached TLS session, resulting in faster EAP-TLS performance and lessened AAA server load. When CiscoSecure 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 CiscoSecure ACS to trust a user based on the cached TLS session from the original EAP-TLS authentication. Because CiscoSecure 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 Session timeout is based on the time of the initial, full authentication of the session. It is not dependent upon an accounting start message.


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 CiscoSecure 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 CiscoSecure ACS implementation of EAP-TLS has the following limitations:

Server certificate format —Server and CA certificates must be either in Base64-encoded X.509 format or DER-encoded binary X.509 format.

LDAP attribute for binary comparison —If you configure CiscoSecure ACS to perform binary comparison of user certificates, the user certificate must be stored in Active Directory or an LDAP server, using a binary format. Also, the attribute storing the certificate must be named "usercertificate".

Enabling EAP-TLS Authentication

This procedure provides an overview of the detailed procedures required to configure CiscoSecure ACS to support EAP-TLS authentication.


Note End-user client computers must be configured to support EAP-TLS. This procedure is specific to configuration of CiscoSecure ACS only. 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.


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:


Step1 Install a server certificate in CiscoSecure ACS. EAP-TLS requires a server certificate. For detailed steps, see Installing a Cisco Secure ACS Certificate.


Note If you have previously installed a certificate to support EAP-TLS or PEAP user authentication or to support HTTPS protection of remote CiscoSecure ACS administration, you do not need to perform this step. A single server certificate is sufficient to support all certificate-based CiscoSecure ACS services and remote administration; however, EAP-TLS and PEAP require that the certificate be suitable for server authentication purposes.


Step2 Edit the certification trust list so that the certification authority (CA) issuing end-user client certificates is trusted. If you do not perform this step, CiscoSecure ACS only trusts user certificates issued by the same CA that issued the certificate installed in CiscoSecure ACS. For detailed steps, see Editing the Certificate Trust List.

Step3 Enable EAP-TLS on the Global Authentication Setup page. CiscoSecure ACS allows you to complete this step only after you have successfully completed Step 1. For detailed steps, see Configuring Authentication Options.

Step4 Configure a user database. To determine which user databases support EAP-TLS authentication, see Authentication Protocol-Database Compatibility.

CiscoSecure ACS is ready to perform EAP-TLS authentication.


PEAP Authentication

This section contains the following topics:

About the PEAP Protocol

PEAP and CiscoSecure ACS

PEAP and the Unknown User Policy

Enabling PEAP Authentication

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 CiscoSecure ACS. This requires a server certificate and authenticates CiscoSecure 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.

In phase two, CiscoSecure 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 CiscoSecure 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 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

CiscoSecure ACS supports PEAP authentication using either the Cisco Aironet PEAP client or the Microsoft PEAP client included with Microsoft Windows XP Service Pack 1. CiscoSecure 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, CiscoSecure 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, CiscoSecure ACS first attempts PEAP(EAP-GTC) authentication with the end-user client. If the client rejects this protocol (by sending an EAP NAK message), CiscoSecure ACS attempts authentication with PEAP(EAP-MSCHAPv2). For more information about enabling EAP protocols supported within PEAP, see Global Authentication Setup.

CiscoSecure 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.

CiscoSecure ACS supports a session resume feature for PEAP-authenticated user sessions. When this feature is enabled, CiscoSecure 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, CiscoSecure ACS uses the cached TLS session, resulting in faster PEAP performance and lessened AAA server load.


Note Session timeout is based on the time that authentication succeeds. It is not dependent upon accounting.


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.

CiscoSecure ACS also supports a fast reconnect feature. When the session resume feature is enabled, the fast reconnection feature causes CiscoSecure ACS to allow a PEAP session to resume without checking user credentials. In effect, enabling this feature allows CiscoSecure ACS to trust a user based on the cached TLS session from the original PEAP authentication. Because CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure 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, CiscoSecure ACS does not attempt to lookup 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 CiscoSecure ACS, CiscoSecure 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, CiscoSecure ACS attempts to authenticate the PEAP user with unknown user processing.

For more information about unknown user processing, see Unknown User Processing.

Enabling PEAP Authentication

This procedure provides an overview of the detailed procedures required to configure CiscoSecure ACS to support PEAP authentication.


Note End-user client computers must be configured to support PEAP. This procedure is specific to configuration of CiscoSecure ACS only.


To enable PEAP authentication, follow these steps:


Step1 Install a server certificate in CiscoSecure ACS. PEAP requires a server certificate. For detailed steps, see Installing a Cisco Secure ACS Certificate.


Note If you have previously installed a certificate to support EAP-TLS or PEAP user authentication or to support HTTPS protection of remote CiscoSecure ACS administration, you do not need to perform this step. A single server certificate is sufficient to support all certificate-based CiscoSecure ACS services and remote administration; however, EAP-TLS and PEAP require that the certificate be suitable for server authentication purposes.


Step2 Enable PEAP on the Global Authentication Setup page. CiscoSecure ACS allows you to complete this step only after you have successfully completed Step 1. For detailed steps, see Configuring Authentication Options.

Step3 Configure a user database. To determine which user databases support PEAP authentication, see Authentication Protocol-Database Compatibility.

CiscoSecure ACS is ready to perform PEAP authentication for most users. For more information, see PEAP and the Unknown User Policy.

Step4 Consider enabling the Unknown User Policy to simplify PEAP authentication. For more information, see PEAP and the Unknown User Policy. For detailed steps, see Configuring the Unknown User Policy.


EAP-FAST Authentication


Note EAP-FAST support is available beginning in CiscoSecure ACS version 3.2.3. Earlier versions of CiscoSecure ACS do not include this feature.


This section contains the following topics:

About EAP-FAST

About Master Keys

About PACs

Automatic PAC Provisioning

Manual PAC Provisioning

Master Key and PAC TTLs

Replication and EAP-FAST

Enabling EAP-FAST

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 CiscoSecure ACS generates using a master key known only to CiscoSecure 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:

Phase zero —Unique to EAP-FAST, phase zero is a tunnel-secured means of providing an EAP-FAST end-user client with a PAC for the user requesting network access (see Automatic PAC Provisioning). Providing a PAC to the end-user client is the sole purpose of phase zero. The tunnel is established based on an anonymous Diffie-Hellman key exchange. If EAP-MSCHAPv2 authentication succeeds, CiscoSecure ACS provides the user a PAC. To determine which databases support EAP-FAST phase zero, see Authentication Protocol-Database Compatibility.


Note Phase zero is optional and PACs can be manually provided to end-user clients (see Manual PAC Provisioning). You control whether CiscoSecure ACS supports phase zero by selecting the Allow automatic PAC provisioning check box in the Global Authentication Configuration page.


No network service is enabled by phase zero of EAP-FAST; therefore, even a successful EAP-FAST phase zero transaction is recorded in the CiscoSecure ACS Failed Attempts log.

Phase one —In phase one, CiscoSecure ACS and the end-user client establish a TLS tunnel based upon the PAC presented by the end-user client. This requires that the end-user client has been provided a PAC for the user attempting to gain network access and that the PAC is based on a master key that has not expired. The means by which PAC provisioning has occurred is irrelevant; either automatic or manual provisioning may be used.

No network service is enabled by phase one of EAP-FAST.

Phase two —In phase two, CiscoSecure ACS authenticates the user credentials with EAP-GTC, which is protected by the TLS tunnel created in phase one. No other EAP types are supported for EAP-FAST. To determine which databases support EAP-FAST phase two, see Authentication Protocol-Database Compatibility.

CiscoSecure 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, CiscoSecure 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. CiscoSecure 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.

CiscoSecure 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 CiscoSecure ACS automatically generates and that only CiscoSecure ACS is aware of. Master keys are never sent to an end-user client. EAP-FAST requires master keys for two purposes:

PAC generation —CiscoSecure ACS generates PACs using the active master key. For details about PACs, see About PACs.

EAP-FAST phase one —CiscoSecure ACS determines whether the PAC presented by the end-user client was generated by one of the master keys it is aware of, either the active master key or a retired master key.

To increase the security of EAP-FAST, CiscoSecure ACS changes the master key that it uses to generate PACs. CiscoSecure 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, CiscoSecure ACS assigns master keys one of the three following states:

Active —An active master key is the master key used by CiscoSecure ACS to generate PACs. The duration that a master key remains active is determined by the Master key TTL setting. At any time, only one master key is active. When you define TTLs for master keys and PACs, CiscoSecure ACS permits only a PAC TTL that is shorter than the active master key TTL. This limitation ensures that a PAC is refreshed at least once before the expiration of the master key used to generate the PAC, provided that EAP-FAST users log in to the network at least once before the master key expires. For more information about how TTL values determine whether PAC refreshing or provisioning is required, see Master Key and PAC TTLs.

When CiscoSecure 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 If EAP-FAST authentication fails because the active and backup master keys have retired and CiscoSecure ACS has not received new master keys in replication, you can force CiscoSecure ACS to generate its own master keys by selecting the EAP-FAST Master Server check box and clicking Submit.


CiscoSecure ACS records the generation of master keys in the logs for the CSAuth service.

Retired —When a master key becomes older than the Master key TTL settings, it is considered retired for as long as specified by the Retired master key TTL settings. CiscoSecure ACS can store up to 255 retired master keys. While a retired master key is not used to generate new PACs, CiscoSecure ACS needs it to authenticate PACs that were generated using it. When you define TTLs for master keys and retired master keys, CiscoSecure ACS permits only TTL settings that require storing 255 or fewer retired master keys. For example, if the master key TTL is 1 hour and the retired master key TTL is 4 weeks, this would require storing up to 671 retired master keys; therefore, CiscoSecure ACS presents an error message and does not allow these settings.

When a user gains network access using a PAC generated with a retired master key, CiscoSecure ACS provides the end-user client a new PAC generated with the active master key. For more information about CiscoSecure ACS with respect to the states of master keys and PACs, see Master Key and PAC TTLs.

Expired —When a master key becomes older than the sum of the master key TTL and retired master TTL settings, it is considered expired and CiscoSecure ACS deletes it from its records of master keys. For example, if the master key TTL is one hour and the retired master key TTL is one week, a master key expires when it becomes greater than one week and one hour old.

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 CiscoSecure ACS and an EAP-FAST end-user client to authenticate each other and establish a TLS tunnel for use in EAP-FAST phase two. CiscoSecure 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 CiscoSecure ACS at the beginning of the EAP-FAST transaction. CiscoSecure 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 an expired master key 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, CiscoSecure ACS refreshes them as dictated by master key and PAC TTL values. CiscoSecure 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 CiscoSecure 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:

PAC provisioning —Required when an end-user client has no PAC or has a PAC that is based on an expired master key. For more information about how master key and PAC states determine whether PAC provisioning is required, see Master Key and PAC TTLs.

Two means of PAC provisioning are supported:

Automatic provision —Sends a PAC using a secure network connection. For more information, see Automatic PAC Provisioning.

Manual provision —Requires that you use CiscoSecure ACS to generate a PAC file for the user, copy the PAC file to the computer running the end-user client, and import the PAC file into the end-user client. For more information, see Manual PAC Provisioning.

PAC refresh —Occurs automatically when EAP-FAST phase two authentication has succeeded and master key and PAC TTLs dictate that the PAC must be refreshed. For more information about how master key and PAC states determine whether a PAC is refreshed, see Master Key and PAC TTLs.

PACs have the following two states, determined by the PAC TTL setting:

Active —A PAC younger than the PAC TTL is considered active and can be used to complete EAP-FAST phase one, provided that the master key used to generate it has not expired. Regardless of whether a PAC is active, if it is based on an expired master key, PAC provisioning must occur before EAP-FAST phase one can succeed.

Expired —A PAC older than the PAC TTL is considered expired. Provided that the master key used to generate the PAC has not expired, an expired PAC can be used to complete EAP-FAST phase one and, at the end of EAP-FAST phase two, CiscoSecure ACS will generate a new PAC for the user and provide it to the end-user client.

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 CiscoSecure ACS administrator, provided that both CiscoSecure 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, CiscoSecure ACS establishes a Diffie-Hellman tunnel with the end-user client. CiscoSecure 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 CiscoSecure ACS.


Note Because EAP-FAST phase zero and phase two use different authentication methods (EAP-MSCHAPv2 in phase zero versus EAP-GTC in phase two), some databases that support phase two cannot support phase zero. Given that CiscoSecure ACS associates each user with a single user database, the use of automatic PAC provisioning requires that EAP-FAST users are authenticated with a database that is compatible with EAP-FAST phase zero. For the databases with which CiscoSecure ACS can support EAP-FAST phase zero and phase two, see Authentication Protocol-Database Compatibility.


No network service is enabled by phase zero of EAP-FAST; therefore, CiscoSecure 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 Because transmission of PACs in phase zero is secured by MS-CHAPv2 authentication and MS-CHAPv2 is vulnerable to dictionary attacks, we recommend that you limit use of automatic provisioning to initial deployment of EAP-FAST. After a large EAP-FAST deployment, PAC provisioning should be performed manually to ensure the highest security for PACs. For more information about manual PAC provisioning, see Manual PAC Provisioning.


To control whether CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS deployment includes network segmentation wherein access to each network segment is controlled by a separate CiscoSecure 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 CiscoSecure ACSes, you can determine, on a per-employee basis, whether Boston employees visiting the Chicago office can have wireless access.


Note Replicating EAP-FAST master keys and policies affects the ability to require different PACs per CiscoSecure ACS. For more information, see Table10-2.


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. CiscoSecure ACS Appliance 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. Table10-1 summarizes CiscoSecure ACS behavior with respect to PAC and master key states.

Table 10-1 Master Key versus PAC States 

Master key state
PAC active
PAC expired
Master key active

Phase one succeeds.

PAC is not refreshed at end of phase two.

Phase one succeeds.

PAC is refreshed at end of phase two.

Master key retired

Phase one succeeds.

PAC is refreshed at end of phase two.

Phase one succeeds.

PAC is refreshed at end of phase two.

Master key expired

PAC provisioning is required.

If automatic provisioning is enabled, phase zero occurs and a new PAC is sent. The end-user client initiates a new EAP-FAST authentication request using the new PAC.

If automatic provisioning is disabled, phase zero does not occur and phase one fails. You must use manual provisioning to give the user a new PAC.

PAC provisioning is required.

If automatic provisioning is enabled, phase zero occurs and a new PAC is sent. The end-user client initiates a new EAP-FAST authentication request using the new PAC.

If automatic provisioning is disabled, phase zero does not occur and phase one fails. You must use manual provisioning to give the user a new PAC.


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:

On the Database Replication Setup page of the primary CiscoSecure ACS, under Send , you have selected the EAP-FAST master keys and policies check box.

On the Global Authentication Setup page of the primary CiscoSecure ACS, you have enabled EAP-FAST and selected the EAP-FAST master server check box.

On the Database Replication Setup page of the secondary CiscoSecure ACS, under Receive , you have selected the EAP-FAST master keys and policies check box.

On the Global Authentication Setup page of the secondary CiscoSecure ACS, you have enabled EAP-FAST and deselected the EAP-FAST master server check box.

EAP-FAST-related replication occurs for three events:

Generation of master keys —A primary CiscoSecure ACS sends newly generated active and backup master keys to secondary CiscoSecure ACSes. This occurs immediately after master key generation, provided that replication is configured properly and is not affected by replication scheduling on the Database Replication Setup page.

Manual replication —All EAP-FAST components that can be replicated are replicated if you click Replicate Now on the Database Replication Setup page of the primary CiscoSecure ACS. Some of the replicated components are configurable in the HTML interface. Whether an EAP-FAST component is replicated or configurable is detailed in Table10-2.


Note EAP-FAST replication is not included in scheduled replication events.


Changes to EAP-FAST settings —If, on a primary CiscoSecure ACS, you change any EAP-FAST configurable components that are replicated, CiscoSecure ACS begins EAP-FAST replication. Whether an EAP-FAST component is replicated or configurable is detailed in Table10-2.

The Database Replication log on the primary CiscoSecure ACS records replication of master keys. Entries related to master key replication contain the text "MKEYReplicate".

Table 10-2 EAP-FAST Components and Replication 

EAP-FAST Component
Replicated?
Configurable?

EAP-FAST Enable

No

Yes, on the Global Authentication Setup page.

Master key TTL

Yes

Yes, on the Global Authentication Setup page.

Retired master key TTL

Yes

Yes, on the Global Authentication Setup page.

PAC TTL

Yes

Yes, on the Global Authentication Setup page.

Authority ID

Yes

No, generated by CiscoSecure ACS.

Authority ID info

Yes

Yes, on the Global Authentication Setup page.

Client initial message

Yes

Yes, on the Global Authentication Setup page.

Master keys

Yes

No, generated by CiscoSecure ACS when TTL settings dictate.

EAP-FAST master server

No

Yes, on the Global Authentication Setup page.

Actual EAP-FAST server status

No

No, determined by CiscoSecure ACS.


The EAP-FAST master server setting has a significant effect upon EAP-FAST authentication and replication, as follows:

Enabled —When the EAP-FAST master server check box is selected, the "Actual EAP-FAST server status" is Master and CiscoSecure ACS ignores the EAP-FAST settings, Authority ID, and master keys it receives from a primary CiscoSecure 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 CiscoSecure ACS that is different than the PAC from the secondary CiscoSecure ACS. Because the primary and secondary CiscoSecure 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 CiscoSecure ACS is not accepted by the secondary CiscoSecure ACS in a replication scheme where the EAP-FAST master server setting is enabled on the secondary CiscoSecure ACS.


Tip In a replicated CiscoSecure ACS environment, use the EAP-FAST master server feature in conjunction with disallowing automatic PAC provisioning to control EAP-FAST access to different segments of your network. Without automatic PAC provisioning, users must request PACs for each network segment.


Disabled —When the EAP-FAST master server check box is not selected, CiscoSecure ACS continues to operate as a EAP-FAST master server until the first time it receives replicated EAP-FAST components from the primary CiscoSecure ACS. When "Actual EAP-FAST server status" displays the text Slave, CiscoSecure ACS uses the EAP-FAST settings, Authority ID, and master keys it receives from a primary CiscoSecure ACS during replication, rather than using master keys it generates and its unique Authority ID.


Note When you deselect the EAP-FAST master server check box, the "Actual EAP-FAST server status" remains Master until CiscoSecure ACS receives replicated EAP-FAST components and then the "Actual EAP-FAST server status" changes to Slave. Until "Actual EAP-FAST server status" changes to Slave, CiscoSecure 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 CiscoSecure ACSes. This is because the primary and secondary CiscoSecure 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 CiscoSecure ACS. Also, a PAC generated for a user by one CiscoSecure ACS in a replication scheme where the EAP-FAST master server setting is disabled is accepted by all other CiscoSecure 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 CiscoSecure ACS to support EAP-FAST authentication.


Note End-user clients must be configured to support EAP-FAST. This procedure is specific to configuring CiscoSecure ACS only.


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 CiscoSecure ACS to perform EAP-FAST authentication, follow these steps:


Step1 Configure a user database that supports EAP-FAST authentication. To determine which user databases support EAP-FAST authentication, see Authentication Protocol-Database Compatibility. For user database configuration, see "User Databases"


Note User database support differs for EAP-FAST phase zero and phase two.


CiscoSecure ACS supports use of the Unknown User Policy and group mapping with EAP-FAST, as well as password aging with Windows external user databases.

Step2 Determine master key and PAC TTL values. While changing keys and PACs more frequently could be considered more secure, it also increases the likelihood that PAC provisioning will be needed for machines left offline so long that the PACs on them are based on expired master keys.

Also, keep in mind that 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.

Step3 Determine whether you want to use automatic or manual PAC provisioning. For more information about the two means of PAC provisioning, see Automatic PAC Provisioning, and Manual PAC Provisioning.


Note We recommend limiting the use of automatic PAC provisioning to initial deployments of EAP-FAST, followed by using manual PAC provisioning for adding small numbers of new end-user clients to your network and for replacing PACs based on expired master keys.


Step4 Using the decisions during Step2 and Step3, enable EAP-FAST on the Global Authentication Setup page. For detailed steps, see Configuring Authentication Options.

CiscoSecure 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 CiscoSecure 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

Configuring Authentication Options

Authentication Configuration Options

The Global Authentication Setup page contains the following configuration options:

PEAP —You can configure the following options for PEAP:

Allow EAP-MSCHAPv2 —Whether CiscoSecure ACS attempts EAP-MSCHAPv2 authentication with PEAP clients.


Note If both the Allow EAP-MSCHAPv2 and the Allow EAP-MSCHAPv2 check boxes are selected, CiscoSecure ACS negotiates the EAP type with the end-user PEAP client.


Allow EAP-GTC —Whether CiscoSecure ACS attempts EAP-GTC authentication with PEAP clients.

Cisco client initial message —The message you want displayed during PEAP authentication. The PEAP client initial display message is the first challenge a user of a Cisco Aironet PEAP client sees when attempting authentication. It should direct the user on what to do next, for example, "Enter your passcode." The message is limited to 60 characters.

PEAP session timeout (minutes) —The maximum PEAP session length you want to allow users, in minutes. A session timeout value greater than 0 (zero) enables the PEAP session resume feature, which caches the TLS session created in phase one of PEAP authentication. When a PEAP client reconnects, CiscoSecure ACS uses the cached TLS session to restore the session, which improves PEAP performance. CiscoSecure ACS deletes cached TLS sessions when they time out. The default timeout value is 120 minutes. To disable the session resume feature, set the timeout value to 0 (zero).

Enable Fast Reconnect —Whether CiscoSecure ACS resumes sessions for PEAP clients without performing phase two of PEAP authentication. Deselecting the Enable Fast Reconnect check box causes CiscoSecure ACS to always perform phase two of PEAP authentication, even when the PEAP session has not timed out.

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.

EAP-FAST —You can configure the following options for EAP-FAST:

Allow EAP-FAST —Whether CiscoSecure ACS permits EAP-FAST authentication.


Note If users access your network using a AAA client defined in the Network Configuration section as a RADIUS (Cisco Aironet) device, one or more of the LEAP, EAP-TLS, or EAP-FAST protocols must be enabled on the Global Authentication Setup page; otherwise, Cisco Aironet users cannot authenticate.


Master Key TTL —The duration that a master key is used to generate new PACs. When the master key becomes older than the master key TTL, CiscoSecure ACS retires the master key and generates a new master key. The default master key TTL is one month.


Note Decreasing the master key TTL can cause retired master keys to expire because a master key expires when it is older than the sum of the master key TTL and the retired master key TTL; therefore, decreasing the master key TTL requires PAC provisioning for end-user clients with PACs based on the newly expired master keys.


For more information about master keys, see About Master Keys .

Retired master key TTL —The duration that PACs generated using a retired master key are acceptable for EAP-FAST authentication. In other words, the retired master key TTL defines the length of the grace period during which PACs generated with a master key that is no longer active are acceptable. When an end-user client gains network access using a PAC based on a retired master key, CiscoSecure ACS sends a new PAC to the end-user client. The default retired master key TTL is three months.

When a retired master key ages past the retired master key TTL, it expires and Cisco Secure ACS deletes it.


Note Decreasing the retired master key TTL is likely to cause some retired master keys to expire; therefore, end-user clients with PACs based on the newly expired master keys require PAC provisioning.



Note Decreasing the retired master key TTL can cause retired master keys to expire; therefore, decreasing the retired master key TTL requires PAC provisioning for end-user clients with PACs based on the newly expired master keys.


For more information about master keys, see About Master Keys .

PAC TTL —The duration that a PAC is used before it expires and must be replaced. If the master key used to generate it has not expired, new PAC creation and assignment are automatic. If the master key used to generate it has expired, in-band or out-of-band provisioning must be used to provide the end-user client with a new PAC. The default PAC TTL is one month.

For more information about PACs, see About PACs .

Client initial display message —Specifies a message to be sent to users who authenticate with an EAP-FAST client. Maximum length is 40 characters.


Note A user will see the initial display message only if the end-user client supports its display.


Authority ID Info —A short description of this CiscoSecure ACS, sent along with PACs issued by CiscoSecure ACS. EAP-FAST end-user clients use it to describe the AAA server that issued the PAC. Maximum length is 64 characters.


Note Authority ID information is not the same as the Authority ID, which is generated automatically by CiscoSecure ACS and is not configurable. While the Authority ID is used by end-user clients to determine which PAC to send to CiscoSecure ACS, the Authority ID information is strictly the human-readable label associated with the Authority ID.


Allow automatic PAC provisioning —Whether CiscoSecure ACS will provision an end-user client with a PAC using EAP-FAST phase 0. If this check box is selected, CiscoSecure ACS establishes a secured connection with the end-user client for providing a new PAC. If the check box is not selected, CiscoSecure ACS denies the user access and PAC provisioning must be performed out of band (manually).

EAP-FAST Master Server —When this check box is not selected and when CiscoSecure ACS receives replicated EAP-FAST policies, Authority ID, and master keys, CiscoSecure ACS uses them rather than its own EAP-FAST policies, Authority ID, and master keys.

When this check box is selected, Cisco Secure ACS uses its own EAP-FAST policies, Authority ID, and master keys. For more information, see Table 10-2 .


Note Click Submit + Restart if you change the EAP-FAST master server setting.


Actual EAP-FAST server status —This read-only option displays the state of CiscoSecure ACS with respect to EAP-FAST. If this option displays "Master", CiscoSecure ACS generates its own master keys and Authority ID. If this option displays "Slave", CiscoSecure ACS uses master keys and the Authority ID it receives during replication. For more information, see Table10-2.


Tip If you deselect the EAP-FAST Master Server check box, EAP-FAST server status remains "Master" until CiscoSecure ACS receives replicated EAP-FAST components.


EAP-TLS —You can configure the following options for EAP-TLS:

Allow EAP-TLS —Whether CiscoSecure ACS permits EAP-TLS authentication.


Note If users access your network using a AAA client defined in the Network Configuration section as a RADIUS (Cisco Aironet) device, one or more of the LEAP, EAP-TLS, or EAP-FAST protocols must be enabled on the Global Authentication Setup page; otherwise, Cisco Aironet users cannot authenticate.


Certificate SAN comparison —Whether authentication is performed by comparing the Subject Alternative Name (SAN) of the end-user client certificate to the username in the applicable user database.


Note If you select more than one comparison type, CiscoSecure ACS performs the comparisons in the order listed. If the one comparison type fails, CiscoSecure ACS attempts the next enabled comparison type. Comparison stops after the first successful comparison.


Certificate CN comparison —Whether authentication is performed by comparing the Common Name of the end-user client certificate to the username in the applicable user database.

Certificate Binary comparison —Whether authentication is performed by a binary comparison of the end-user client certificate to the user certificate stored in the applicable user database. This comparison method cannot be used to authenticate users stored in an ODBC external user database.

EAP-TLS session timeout (minutes) —The maximum EAP-TLS session length you want to allow users, in minutes. A session timeout value greater than 0 (zero) enables the EAP-TLS session resume feature. The session resume feature allows users to reauthenticate without a user lookup or certificate comparison provided that the session has not timed out. If the end-user client is restarted, authentication requires a certificate lookup even if the session timeout interval has not ended. The default timeout value is 120 minutes. To disable the session timeout feature, set the timeout value to 0 (zero).

LEAP —The Allow LEAP (For Aironet only) check box controls whether CiscoSecure ACS performs LEAP authentication. LEAP is currently used only for Cisco Aironet wireless networking. If you disable this option, Cisco Aironet end-user clients configured to perform LEAP authentication cannot access the network. If all Cisco Aironet end-user clients use a different authentication protocol, such as EAP-TLS, we recommend that you disable this option.


Note If users access your network using a AAA client defined in the Network Configuration section as a RADIUS (Cisco Aironet) device, either LEAP, EAP-TLS, or both must be enabled on the Global Authentication Setup page; otherwise, Cisco Aironet users cannot authenticate.


EAP-MD5 —The Allow EAP-MD5 check box controls whether CiscoSecure ACS performs EAP-MD5 authentication. If you disable this option, end-user clients configured to perform EAP-MD5 authentication cannot access the network. If no end-user clients use EAP-MD5, we recommend that you disable this option.

AP EAP request timeout (seconds) —Whether Cisco Secure ACS instructs Cisco Aironet Access Points (APs) to use the specified timeout value during EAP conversations. The value specified must be the number of seconds after which Cisco Aironet APs should assume that an EAP transaction with CiscoSecure ACS has been lost and should be restarted. A value of 0 (zero) disables this feature.


Note The AP EAP request timeout feature is available beginning in Cisco Secure ACS version 3.2.3. Earlier versions of Cisco Secure ACS do not include this feature.


During EAP conversations, CiscoSecure 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 CiscoSecure 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 Cisco Aironet RADIUS VSA Cisco-Aironet-Session-Timeout (01) is not a true RADIUS VSA; instead, it represents the value that CiscoSecure ACS sends in the IETF RADIUS Session-Timeout attribute when the AAA client sending the RADIUS request is defined in the Network Configuration as authenticating with RADIUS (Cisco Aironet).


MS-CHAP Configuration —The Allow MS-CHAP Version 1 Authentication and Allow MS-CHAP Version 2 Authentication check boxes control whether CiscoSecure ACS performs MS-CHAP authentication for RADIUS requests. The two check boxes allow you to further control which versions of MS-CHAP are permitted in RADIUS requests. If you disable a particular version of MS-CHAP, end-user clients configured to authenticate with that version using RADIUS cannot access the network. If no end-user clients are configured to use a specific version of MS-CHAP with RADIUS, we recommend that you disable that version of MS-CHAP.


Note For TACACS+, CiscoSecure ACS supports only MS-CHAP version 1. TACACS+ support for MS-CHAP version 1 is always enabled and is not configurable.


Configuring Authentication Options

Use this procedure to select and configure how CiscoSecure 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:


Step1 In the navigation bar, click System Configuration .

Step2 Click Global Authentication Setup .

CiscoSecure ACS displays the Global Authentication Setup page.

Step3 Configure options, as applicable. For more information about the significance of the options, see Authentication Configuration Options.

Step4 If you want to immediately implement the settings you have made, click Submit + Restart .

CiscoSecure ACS restarts its services and implements the authentication configuration options you selected.

Step5 If you want to save the settings you have made but implement them later, click Submit .


Tip You can restart CiscoSecure ACS services at any time by using the Service Control page in the System Configuration section.


CiscoSecure 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

Adding a Certificate Authority Certificate

Editing the Certificate Trust List

Generating a Certificate Signing Request

Updating or Replacing a CiscoSecure ACS Certificate

Installing a Cisco Secure ACS Certificate

Perform this procedure to install (that is, enroll) a CiscoSecure ACS certificate. You can perform certificate enrollment to support EAP-TLS and PEAP authentication, as well as HTTPS protocol for GUI access to CiscoSecure ACS.

Before You Begin

You must have a server certificate for your CiscoSecure ACS before you can install it. With CiscoSecure 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 CiscoSecure ACS, follow these steps:


Step1 In the navigation bar, click System Configuration .

Step2 Click ACS Certificate Setup .

Step3 Click Install ACS Certificate .

CiscoSecure ACS displays the Install new certificate table on the Install ACS Certificate page.

Step4 To install a new certificate, select the Read certificate from file option and then click the Download certificate file link.

The Download Certificate File page appears.

Step5 To download the certificate file to CiscoSecure ACS, in the Download File table, follow these steps:

a. In the FTP Server box, type the IP address or hostname of the FTP server that has the certificate file you want to download.


Tip If you specify the hostname, DNS must be working correctly on your network.


b. In the Login box, type a valid username that Cisco Secure ACS can use to access the FTP server.

c. In the Password box, type the password for the username you specified in the Login box.

d. In the Remote FTP Directory box, type relative path from the FTP server root directory to the directory containing the certificate file you want Cisco Secure ACS to download from the FTP server.

e. In the Remote FTP File Name box, type the name of the certificate file you want Cisco Secure ACS to download from the FTP server.

f. Click Submit .

The system downloads the certificate file and displays the file name in Certificate file box of the Install ACS Certificate page.


Tip If the file transfer encounters errors, they appear in the window on the right.


Step6 If you generated the request using CiscoSecure ACS, click the Download private key file link.

The Download Private Key File page appears.

Step7 To download the private key file to the CiscoSecure ACS, in the Download File table follow these steps:

a. In the FTP Server box, type the IP address or hostname of the FTP server that has the private key file you want to download.


Tip If you specify the hostname, DNS must be working correctly on your network.


b. In the Login box, type a valid username that Cisco Secure ACS can use to access the FTP server.

c. In the Password box, type the password for the username you specified in the Login box.

d. In the Remote FTP Directory box, type the relative path from the FTP server root directory to the directory containing the private key file you want Cisco Secure ACS to download from the FTP server.

e. In the Remote FTP File Name box, type the name of the private key file you want Cisco Secure ACS to download from the FTP server.

f. Click Submit .

The system downloads the private key file and displays the filename in Private key file box of the Install ACS Certificate page.


Tip If the file transfer encounters errors, they appear in the window on the right.


Step8 In the Private key password box, type the private key password.


Tip If you used CiscoSecure ACS to generate the certificate signing request, this is the value you entered in Private key password under Generate certificate signing request (CSR). If the private key file is unencrypted, leave this box empty.


Step9 Click Submit .

To show that the certificate setup is complete, CiscoSecure ACS displays the Installed Certificate Information table, which contains the following certificate information:

Issued to: certificate subject

Issued by: CA common name

Valid from:

Valid to:

Validity


Adding a Certificate Authority Certificate

Use this procedure to add new certification authority (CA) certificates to CiscoSecure ACS local certificate storage.


Note If the clients and CiscoSecure ACS are getting their certificates from the same CA, you do not need to perform this procedure because CiscoSecure ACS automatically trusts the CA that issued its certificate.


When a user certificate is from an unknown CA (that is, one that is different from the CA that certifies the CiscoSecure ACS), you must specifically configure CiscoSecure ACS to trust that CA or authentication fails. Until you perform this procedure to explicitly extend trust by adding another CA, CiscoSecure ACS only recognizes certificates from the CA that issued its own certificate.

Configuring CiscoSecure ACS to trust a specific CA is a two-step process that comprises both this procedure of adding a CA certificate and the procedure in Editing the Certificate Trust List, where you signify that the particular CA is to be trusted. (CiscoSecure ACS comes preconfigured with a list of popular CAs, none of which are enabled until you explicitly signify trustworthiness.)

To add a certificate authority certificate to your local storage, follow these steps:


Step1 In the navigation bar, click System Configuration .

Step2 Click ACS Certificate Setup .

Step3 Click ACS Certification Authority Setup .

CiscoSecure ACS displays the CA Operations table on the ACS Certification Authority Setup page.

Step4 Click on the Download CA certificate file link.

The Download CA Certificate File page appears.

Step5 To download the private CA certificate file to the CiscoSecure ACS, in the Download File table, follow these steps:

a. In the FTP Server box, type the IP address or hostname of the FTP server that has the CA certificate file you want to download.

b. In the Login box, type a valid username that Cisco Secure ACS can use to access the FTP server.

c. In the Password box, type the password for the username you specified in the Login box.

d. In the Remote FTP Directory box, type the relative path from the FTP server root directory to the directory containing the CA certificate file you want Cisco Secure ACS to download from the FTP server.

e. In the Remote FTP File Name box, type the name of the CA certificate file you want Cisco Secure ACS to download from the FTP server.

f. Click Submit .

The system downloads the CA certificate file and displays the filename in the CA certificate box of the Install ACS Certificate page.


Tip If the file transfer encounters errors, they appear in the window on the right.


Step6 In the Private key password box, type the private key password.

Step7 Click Submit .

The new CA certificate is added to local certificate storage.


Editing the Certificate Trust List

CiscoSecure ACS uses the CTL to verify the client certificates. For a CA to be trusted by CiscoSecure ACS, its certificate must be installed, and the CiscoSecure ACS administrator must explicitly configure the CA as trusted by editing the CTL. If the CiscoSecure ACS server certificate is replaced, the CTL is erased; you must configure the CTL explicitly each time you install or replace a CiscoSecure ACS server certificate.


Note The single exception to the requirement that a CA must be explicitly signified as trustworthy occurs when the clients and CiscoSecure ACS are getting their certificates from the same CA. You do not need to add this CA to the CTL because CiscoSecure ACS automatically trusts the CA that issued its certificate.


How you edit your CTL determines the type of trust model you have. Many use a restricted trust model wherein very few, privately controlled CAs are trusted. This model provides the highest level of security but restricts adaptability and scalability. The alternative, an open trust model, allows for more CAs or public CAs. This open trust model trades off increased security for greater adaptability and scalability.

We recommend that you fully understand the implications of your trust model before editing the CTL in CiscoSecure ACS.

Use this procedure to configure CAs on your CTL as trusted or not trusted. Before a CA can be configured as trusted on the CTL, you must have added the CA to the local certificate storage; for more information, see Adding a Certificate Authority Certificate. If a user's certificate is from a CA that you have not specifically configured CiscoSecure ACS to trust, authentication fails.

To edit the CTL, follow these steps:


Step1 In the navigation bar, click System Configuration .

Step2 Click CiscoSecure ACS Certificate Setup .

Step3 Click Edit Certificate Trust List .

The Edit the Certificate Trust List (CTL) table appears.


Warning Adding a public CA, which you do not control, to your CTL, may reduce your system security.


Step4 To configure a CA on your CTL as trusted, select the corresponding check box.


Tip You can select, or deselect, as many CAs as you want. Deselecting a CA's check box configures the CA as not trusted.


Step5 Click Submit .

CiscoSecure ACS configures the specified CA (or CAs) as trusted or not trusted in accordance with selecting or deselecting check boxes.


Generating a Certificate Signing Request

You can use CiscoSecure ACS to generate a certificate signing request (CSR). After you generate a CSR, you can submit it to a CA to obtain your certificate. You perform this procedure to generate the CSR for future use with a certificate enrollment tool.


Note If you already have a server certificate, you do not need to use this portion of the ACS Certificate Setup page.


To generate a certificate signing request, follow these steps:


Step1 In the navigation bar, click System Configuration .

Step2 Click ACS Certificate Setup .

Step3 Click Generate Certificate Signing Request .

CiscoSecure ACS displays the Generate new request table on the Generate Certificate Signing Request page.

Step4 In the Certificate subject box, type cn= followed by the name that you would like to use as subject name in this ACS certificate, for example, cn=ACSWireless.

Step5 In the Private key file box, type the full directory path and name of the file in which the private key is saved, for example, c:\privateKeyFile.pem.

Step6 In the Private key password box, type the private key password (that you have invented).

Step7 In the Retype private key password box, retype the private key password.

Step8 From the Key length list, select the length of the key to be used.


Tip The choices for Key length are 512 or 1024 bits. The default and more secure choice is 1024 bits.


Step9 From the Digest to sign with list, select the digest (or hashing algorithm).


Tip The choices for Digest to sign with are MD2, MD5, SHA, and SHA1. The default is SHA1.


Step10 Click Submit .

CiscoSecure ACS displays a CSR in the display area, on the right, under a banner that reads: "Now your certificate signing request is ready. You can copy and paste it into any certification authority enrollment tool."


Tip You can copy and paste this certificate to the online enrollment tool of any CA.



Updating or Replacing a Cisco Secure ACS Certificate

Use this procedure to update or replace an existing CiscoSecure ACS certificate that is out-of-date or out-of-order.


Caution This procedure eliminates your existing CiscoSecure ACS certificate and erases your Certificate Trust List configuration.


To install a new ACS certificate, follow these steps:


Step1 In the navigation bar, click System Configuration .

Step2 Click ACS Certificate Setup .

CiscoSecure ACS displays the Installed Certificate Information table on the ACS Certificate Setup page.


Note If your CiscoSecure ACS has not already been enrolled with a certificate, you do not see the Installed Certificate Information table. Rather, you see the Install new certificate table. If this is the case, you can proceed to Step5.


Step3 Click Enroll New Certificate .

A confirmation dialog box appears.

Step4 To confirm that you intend to enroll a new certificate, click OK .

The existing CiscoSecure ACS certificate is removed and your Certificate Trust List configuration is erased.

Step5 You can now install the replacement certificate in the same manner as an original certificate. For detailed steps, see Installing a Cisco Secure ACS Certificate.


EAP-FAST PAC Files Generation

You can use the EAP-FAST PAC Files Generation page to create PAC files for manual PAC provisioning.

For more information about PACs, see EAP-FAST Authentication.

This section contains the following topics:

PAC File Generation Options

Generating PAC Files

PAC File Generation Options

You have the following options when generating PAC files:

Specific user —CiscoSecure ACS generates a PAC file for the username typed in the User Name box. For example, if you selected this option and typed seaniemop in the User Name box, CiscoSecure ACS would generate a single PAC file, named seaniemop.pac.


Tip You can also specify a domain-qualified username, using the format DOMAIN\username. For example, if you specify ENIGINEERING\augustin, CiscoSecure ACS generates a PAC file name ENGINEERING_augustin.pac.


Users from specific ACS group —CiscoSecure ACS generates a PAC file for each user in the user group specified by the ACS Group list. CiscoSecure ACS has 500 groups, numbered from 0 (zero) to 499. For example, assume group 7 has 43 users. If you selected this option and selected <Group 7> from the ACS Group list, CiscoSecure ACS would generate 43 PAC files, one for each user who is a member of group 7. Each PAC file is named in the following format:


username.pac

Note Generating PAC files for users in a specific group restarts the CSAuth service. No users are authenticated while CSAuth is unavailable.



Tip To generate PAC files for more than one group of users, generate PAC files for each group separately. For example, to generate PAC files for users in groups 7 through 10, generate PAC files four times, once each for groups 7, 8, 9, and 10.


All users in ACS internal DB —CiscoSecure ACS generates a PAC file for each user in the CiscoSecure user database. For example, if you have 3278 users in the CiscoSecure user database and select this option, CiscoSecure ACS would generate 3278 PAC files, one for each user. Each PAC file is named in the following format:

username.pac

Note Generating PAC files for all users in the CiscoSecure user database restarts the CSAuth service. No users are authenticated while CSAuth is unavailable.


Users from list —CiscoSecure ACS generates a PAC file for each username contained in the file retrieved from the FTP server you specify.

Lists of usernames should contain one username per line with no additional spaces or other characters.

For example, if a list retrieved from an FTP server contains the following usernames:

seaniemop
jwiedman
echamberlain

CiscoSecure ACS generates three PAC files: seaniemop.pac, jwiedman.pac, and echamberlain.pac.


Tip You can also specify domain-qualified usernames, using the format DOMAIN\username. For example, if you specify ENIGINEERING\augustin, CiscoSecure ACS generates a PAC file name ENGINEERING_augustin.pac.


The options for retrieving a username list are as follows:

FTP Server —The IP address or hostname of the FTP server where the file specified in the User list file box is. If you specify a hostname, DNS must be enabled on your network and must be configured correctly on the CiscoSecure ACS Appliance console. For more information about IP configuration of CiscoSecure ACS, see Installation and Setup Guide for CiscoSecure ACS Appliance.

Login —A valid username to enable CiscoSecure ACS to access the FTP server.


Tip The Login box accepts domain-qualified usernames in the format DOMAIN\username, which may be required if you are using a Microsoft FTP server.


Password —The password for the username provided in the Login box.

Remote Directory —The directory containing the file of usernames specified in the Users list file box. The directory must be specified relative to the FTP root directory. For example, if the username file is in a directory named paclist, which is a subdirectory of the FTP root directory, you should type paclist in the Remote Directory box.


Tip To specify the FTP root directory, enter a single period or "dot".


Users list file —The filename of the username list. For example, if the name of the username file is eapfastusers.txt, type eapfastusers.txt in the User list filebox.

Encrypt PAC file(s) with —Each PAC file is always encrypted using a password, either the default password known to CiscoSecure ACS and the end-user clients or a password that you specify. Encrypting PAC files helps prevent use of stolen PAC files for access to your network by unauthorized persons. Although the default password is a strong password, it is used by all CiscoSecure ACSes and all EAP-FAST end-user clients.


Note We recommend that you use a password that you devise rather than the default password.


Default password —CiscoSecure ACS uses the default password to protect the PAC files it generates.


Note We recommend that you use a password you devise rather than the default password.


This password —CiscoSecure ACS uses the password specified, rather than the default password, to protect the PAC files it generates. The password you specify is required when the PACs that CiscoSecure ACS protects are loaded into an EAP-FAST end-user client.

PAC passwords are alphanumeric, between four and 128 characters long, and case sensitive. While Cisco Secure ACS does not enforce strong password rules, we recommend that you use a strong password, that is, your PAC password should:

Be very long.

Contain uppercase and lowercase letters.

Contain numbers in addition to letters.

Contain no common words or names.

Generating PAC Files

Each time you instruct CiscoSecure ACS to generate PAC files, CiscoSecure ACS produces a single cabinet file named PACFiles.cab that you download to a location available to the browser you use to access the HTML interface. Use the file compression utility of your choice to extract the .pac files from the PACFiles.cab file. For example, WinZip can extract files from cabinet files.

Before You Begin

CiscoSecure ACS allows you to generate PAC files only if EAP-FAST is enabled. For information about enabling EAP-FAST, see Enabling EAP-FAST.

Determine which users you want to generate PAC files for. If you want to specify the users in a text file, create the text file and place it in a directory under the FTP root directory on an FTP server accessible from CiscoSecure ACS Appliance. For information about using a username list, see PAC File Generation Options.

For information about the options on the EAP-FAST PAC Generation page, see PAC File Generation Options.

To generate PAC files, follow these steps:


Step1 In the navigation bar, click System Configuration .

Step2 Click EAP-FAST PAC Files Generation .

CiscoSecure ACS displays the EAP-FAST PAC Files Generation page.

Step3 Use one of the four options to specify which users CiscoSecure ACS should generate PAC files for. For more information about the significance of the options, see PAC File Generation Options.


Note If you choose to generate PAC files for all users in the CiscoSecure user database in a specific group, the CSAuth service restarts. No user authentication occurs while CSAuth is unavailable.


Step4 Click Submit .

CiscoSecure ACS begins generating PAC files for the user or users specified. If you use the Users from list option, CiscoSecure ACS first retrieves the list from the FTP server specified.

On the EAP-FAST PAC Files Generation page, CiscoSecure ACS displays a "Current PAC CAB file generation status" message.

Step5 If the "Current PAC CAB file generation status" display is:

CAB file generation is in progress

click Refresh occasionally until the "Current PAC CAB file generation status" display is:

CAB file is ready. Press 'Download' to retrieve the file.

Depending upon how many users you specified, CiscoSecure ACS requires from a few seconds to a few minutes to generate PAC files.

Step6 When the "Current PAC CAB file generation status" display is

CAB file is ready. Press 'Download' to retrieve the file.

click Download .


Note The file download options provided by your web browser may differ; however, the fundamental process should be similar to these steps.


The File Download dialog box appears.

Step7 On the File Download dialog box, click Save .

The Save As dialog box appears.

Step8 Use the Save As dialog box to specify where and with what filename you want to save the PACFiles.cab file. Then click Save .

CiscoSecure ACS sends the PACFiles.cab file to your web browser, which saves the file where you specified. When the download is complete, a Download Complete dialog box appears.

Step9 Make note of the location of the PACFiles.cab file, and then click Close .

Step10 You can use the file compression utility of your choice to extract the PAC files from the PACFiles.cab file.