User Guide for Cisco Secure Access Control Server 4.1 - System Configuration: Authentication and Certificates [Cisco Secure Access Control Server for Windows]

Table Of Contents

System Configuration: Authentication and Certificates

About Certification and EAP Protocols

Digital Certificates

EAP-TLS Authentication

About the EAP-TLS Protocol

EAP-TLS and ACS

EAP-TLS Limitations

Enabling EAP-TLS Authentication

PEAP Authentication

About the PEAP Protocol

PEAP and ACS

PEAP and the Unknown User Policy

Enabling PEAP Authentication

EAP-FAST Authentication

About EAP-FAST

About Master Keys

About PACs

Provisioning Modes

Types of PACs

Master Key and PAC TTLs

Replication and EAP-FAST

Enabling EAP-FAST

Stateless Session Server Resume

Global Authentication Setup

Configuring Authentication Options

ACS Certificate Setup

Installing an ACS Server Certificate

Adding a Certificate Authority Certificate

Editing the Certificate Trust List

Managing Certificate Revocation Lists

About Certificate Revocation Lists

Certificate Revocation List Configuration Options

Editing 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 an ACS Certificate

Advanced System Configuration Pages Reference

Global Authentication Setup Page

EAP-FAST Configuration Page

System Configuration: Authentication and Certificates

This chapter addresses authentication and certification features in the System Configuration section of the Cisco Secure Access Control Server Release 4.1, hereafter referred to as ACS.

This chapter contains the following topics:

•About Certification and EAP Protocols

•Global Authentication Setup

•ACS Certificate Setup

•Advanced System Configuration Pages Reference

About Certification and EAP Protocols

ACS uses Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), Extensible Authentication Protocol-Flexible Authentication via Secure Tunnelling (EAP-FAST), and Protected Extensible Authentication Protocol (PEAP) authentication protocols in combination with digital certification to ensure the protection and validity of authentication information.

This section contains the following topics:

•Digital Certificates

•EAP-TLS Authentication

•PEAP Authentication

•EAP-FAST Authentication

Digital Certificates

You use the ACS Certificate Setup pages to install digital certificates to support EAP-TLS, EAP-FAST, and PEAP authentication, as well as to support Secure HyperText Transfer Protocol (HTTPS) protocol for secure access to the ACS web interface. ACS uses the X.509 v3 digital certificate standard. Certificate files must be in Base64-encoded X.509 format or Distinguished Encoding Rules (DER)-encoded binary X.509 format. Also, 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 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, see Installing an ACS Server Certificate, and Using Self-Signed Certificates.

Note Depending on the end-user client involved, the CA certificate for the CA that issued the ACS server certificate is likely to be required in local storage for trusted root CAs on the end-user client computer.

EAP-TLS Authentication

This section contains the following topics:

•About the EAP-TLS Protocol

•EAP-TLS and ACS

•EAP-TLS Limitations

•Enabling EAP-TLS Authentication

Note Modifications to be made to document the way that EAP-TLS works with release 4.1 (RB)

About the EAP-TLS Protocol

EAP and TLS are Internet Engineering Task Force (IETF) RFC standards. The EAP protocol carries initial authentication information, specifically the encapsulation of EAP over LANs (EAPOL) as established by IEEE 802.1X. TLS uses certificates for user authentication and dynamic ephemeral session key generation. The EAP-TLS authentication protocol uses the certificates of ACS and of the end-user client, enforcing mutual authentication of the client and ACS. For more detailed information on EAP, TLS, and EAP-TLS, refer to the following IETF RFCs: Extensible Authentication Protocol (EAP) RFC 3784, The TLS Protocol RFC 2246, and PPP EAP TLS Authentication Protocol RFC 2716.

EAP-TLS authentication involves two elements of trust:

•The EAP-TLS negotiation establishes end-user trust by validating, through RSA signature verifications, that the user possesses a keypair that a certificate signs. This process verifies that the end user is the legitimate keyholder for a given digital certificate and the corresponding user identification in the certificate. However, trusting that a user possesses a certificate only provides a username-keypair binding.

•Using a third-party signature, usually from a CA, that verifies the information in a certificate. This third-party binding is similar to the real-world equivalent of the stamp 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 ACS self-signed certificate capability. Depending on the end-user client involved, the CA certificate for the CA that issued the 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 the end client and the Authentication, Authorization, and Accounting (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)

•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 ACS

ACS supports EAP-TLS with any end-user client that supports EAP-TLS, such as Windows XP, Funk (Juniper), or Meetinghouse clients. To learn which user databases support EAP-TLS, see Authentication Protocol-Database Compatibility, page 1-8. 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/en/US/products/hw/wireless/ps430/products_white_paper09186a008009256b.shtml

ACS can use EAP-TLS to support machine authentication to Microsoft Windows Active Directory. The end-user client may limit the protocol for user authentication to the same protocol that is 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, page 12-10.

To permit user access to the network or computer authenticating with EAP-TLS, ACS must verify that the claimed identity (presented in the EAP Identity response) corresponds to the certificate that the user presents. 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 in the user object in the LDAP server or Active Directory and the certificate that the user presents during EAP-TLS authentication. This comparison method cannot be used to authenticate users who are in an ODBC external user database (ACS for Windows only).

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 that stores 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 ACS uses. For more information, see Configuring Authentication Options.

ACS supports a session resume feature for EAP-TLS-authenticated user sessions, which is a particularly useful feature for WLANs, wherein a user may move the client computer to set a different wireless access point. When this feature is enabled, ACS caches the TLS session that is 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, ACS uses the cached TLS session, resulting in faster EAP-TLS performance and lessened AAA server load. When ACS resumes an EAP-TLS session, the user reauthenticates by a secure sockets layer (SSL) handshake only, without a certificate comparison.

In effect, enabling an EAP-TLS session resume allows ACS to trust a user based on the cached TLS session from the original EAP-TLS authentication. Because 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 in the number of minutes that the EAP-TLS session timeout option specified.

Note Session timeout is based on the time of the initial, full authentication of the session. It does not depend on an accounting start message.

The Session resume feature does not enforce changes to the group assignment in an external user database; because group mapping does not occur when a user session is resumed. Instead, the user is mapped to the same ACS group to which the user was mapped at the beginning of the session. At 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, you can restart the CSAuth service or delete the user from the ACS 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 limitations in the ACS implementation of EAP-TLS are:

•Server and CA certificate file format—If you install the ACS server and CA certificates from files, rather than from certificate storage, server and CA certificate files must be in Base64-encoded X.509 format or DER-encoded binary X.509 format.

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

•Windows server type—If you want to use Active Directory to authenticate users with EAP-TLS when ACS runs on a member server, additional configuration is required. For more information, including steps for the additional configuration, see the Installation Guide for Cisco Secure ACS for Windows, Release 4.1 or the Installation Guide for Cisco Secure ACS Solution Engine Release 4.1.

Enabling EAP-TLS Authentication

This explains the procedures that are required to configure ACS to support EAP-TLS authentication.

Note You must configure end-user client computers to support EAP-TLS. This procedure is specific to the configuration of 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 configured a Microsoft certification authority server 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, seethe Microsoft Knowledge Base.

To enable EAP-TLS authentication, follow these steps:

Step 1 Install a server certificate in ACS. EAP-TLS requires a server certificate. For detailed steps, see Installing an ACS Server Certificate.

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

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

Step 3 Establish a certificate revocation list (CRL) for each CA and certificate type in the certificate trust list (CTL). As part of EAP-TLS authentication, ACS validates the status of the certificate presented by the user against the cached CRL to ensure that it has not been revoked. For detailed steps, see Editing the Certificate Trust List.

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

Step 5 Configure a user database. To determine which user databases support EAP-TLS authentication, see Authentication Protocol-Database Compatibility, page 1-8.

ACS is ready to perform EAP-TLS authentication.

PEAP Authentication

This section contains the following topics:

•About the PEAP Protocol

•PEAP and ACS

•PEAP and the Unknown User Policy

•Enabling PEAP Authentication

About the PEAP Protocol

The PEAP protocol is a client-server security architecture that you use to encrypt EAP transactions; thereby protecting the contents of EAP authentications.

PEAP authentications always involve two phases:

•In the first phase, the end-user client authenticates ACS. This action requires a server certificate and authenticates 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 between the end-user client and the AAA server.

Note Depending on the end-user client involved, the CA certificate for the CA that issued the ACS server certificate is likely to be required in local storage for trusted root CAs on the end-user client computer.

•In the second phase, ACS authenticates the user or machine credentials by using an EAP authentication protocol. The SSL tunnel that was created in phase one protects the EAP authentication. The authentication type that is 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 in parentheses, such as PEAP (EAP-GTC). In phase 2, PEAP supports the following authentication protocols:

–EAP-MSCHAPv2

–EAP-GTC

–EAP-TLS

•One improvement in security that PEAP offers is identity protection. This improvement is the potential of protecting the username in all PEAP transactions. After phase one of PEAP, all data is encrypted, including username information that is 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 clear text in phase one of PEAP authentication.

PEAP and ACS

ACS supports PEAP authentication by using the Cisco Aironet PEAP client or the Microsoft PEAP client that is included with Microsoft Windows XP Service Pack 1. ACS can support the Cisco Aironet PEAP client with PEAP(EAP-GTC) only. For the Microsoft PEAP client in Windows XP Service Pack 1, ACS supports PEAP(EAP-MS-CHAPv2) or PEAP (EAP-TLS). For information about which user databases support PEAP protocols, see Authentication Protocol-Database Compatibility, page 1-8.

PEAP with the Cisco Aironet PEAP Client

When the end-user client is the Cisco Aironet PEAP client, and PEAP(EAP-GTC) and PEAP(EAP-MS-CHAPv2) are enabled on the Global Authentication Setup page, ACS first attempts PEAP(EAP-GTC) authentication with the end-user client. If the client rejects this protocol (by sending an EAP NAK message), ACS attempts authentication with PEAP(EAP-MS-CHAPv2). For more information about enabling EAP protocols that PEAP supports, see Global Authentication Setup.

PEAP and Microsoft Windows Active Directory

ACS can use PEAP(EAP-MS-CHAPv2) to support machine authentication to Microsoft Windows Active Directory. The end-user client may limit the protocol that is used for user authentication to the same protocol that is 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, page 12-10.

The Session Resume Feature

ACS supports a session resume feature for PEAP-authenticated user sessions. When this feature is enabled, ACS caches the TLS session that is 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, 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 does not depend on 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.

ACS also supports a fast reconnect feature. When the session resume feature is enabled, the fast reconnect feature causes ACS to allow a PEAP session to resume without checking user credentials. In effect, ACS can trust a user based on the cached TLS session from the original PEAP authentication when this feature is enabled. Because 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 in the number of minutes that the PEAP session timeout option specifies.

The session resume feature does not enforce changes to group assignment in an external user database; group mapping does not occur when the session resume feature extends a user session. Instead, the user is mapped to the same ACS group that the user was mapped to at the beginning of the session. At 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 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, ACS might not know the real username to be authenticated 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, ACS does not attempt to look up the username that is 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 that the PEAP client presents is unknown to ACS, ACS processes the username in the same way that it processes usernames that are 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, ACS attempts to authenticate the PEAP user with unknown user processing.

For more information about unknown user processing, see About Unknown User Authentication, page 15-3.

Enabling PEAP Authentication

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

Note You must configure end-user client computers to support PEAP. This procedure is specific to configuration of ACS only.

To enable PEAP authentication:

Step 1 Install a server certificate in ACS. PEAP requires a server certificate. For detailed steps, see Installing an ACS Server Certificate.

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

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

Step 3 Configure a user database. To determine which user databases support PEAP authentication, see Authentication Protocol-Database Compatibility, page 1-8.

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

Step 4 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, page 15-8.

EAP-FAST Authentication

This section contains the following topics:

•About EAP-FAST

•About Master Keys

•About PACs

•Provisioning Modes

•Types of PACs

•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 new, publicly accessible IEEE 802.1X EAP type that Cisco developed to support customers that cannot enforce a strong password policy and want to deploy an 802.1X EAP type that does not require digital certificates. EAP-FAST supports a variety of user and password database types, password change and expiration; and is flexible, easy to deploy, and easy to manage. For more information about EAP-FAST and comparison with other EAP types, see:

www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item09186a00802030dc.shtml

The 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 on strong secrets that are unique to users. These secrets are called Protected Access Credentials (PACs), which ACS generates by using a master key known only to ACS. Because handshakes based on shared secrets are intrinsically faster than handshakes based on 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-MS-CHAPv2 authentication succeeds, ACS provides the user with a PAC. To determine which databases support EAP-FAST phase zero, see Authentication Protocol-Database Compatibility, page 1-8.

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

The Allow anonymous in-band PAC provisioning option provisions an end-user client with a PAC by using EAP-FAST phase zero. If this check box is selected, ACS establishes a secured connection with the end-user client for the purpose of providing the client with a new PAC. This option allows an anonymous TLS handshake between the end-user client and ACS. (EAP-MS-CHAP will be used as inner method only.)

The Allow authenticated in-band PAC provisioning option provisions an end-user client with a PAC by using EAP-FAST phase zero with TLS server-side authentication. This option requires that you install a server certificate and a trusted root CA on ACS.

By default, ACS supports TLS server-side authentication; however, if the client sends the user certificate to ACS, mutual TLS authentication is performed and inner methods are bypassed.

Phase zero of EAP-FAST does not enable a network service; therefore, even a successful EAP-FAST phase zero transaction is recorded in the ACS Failed Attempts log.

If the Accept client on authenticated provisioning option is selected, ACS always sends an Access-Reject at the end of the provisioning phase (phase zero), forcing the client to reauthenticate by using the tunnel PAC. This option sends an Access-Accept to the client and can be enabled only when you check the Allow authenticated in-band PAC provisioning check box.

•Phase one—In phase one, ACS and the end-user client establish a TLS tunnel based on the PAC that the end-user client presents. This phase requires that the end-user client has been provided a PAC for the user who is 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; you can use automatic or manual provisioning.

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

•Phase two—In phase two, ACS authenticates the user credentials with EAP-GTC, which is protected by the TLS tunnel that was created in phase one. EAP-GTC, TLS and MS-CHAP are supported as inner methods. No other EAP types are supported for EAP-FAST. To determine which databases support EAP-FAST phase two, see Authentication Protocol-Database Compatibility, page 1-8.

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, ACS may refresh the end-user client PAC, which creates a second entry in the Passed Authentication log for the same phase two transaction.

Note This version of ACS supports EAP-FAST phase two for NAC phase two and is for wired clients only.

EAP-FAST can protect the username in all EAP-FAST transactions. ACS does not perform user authentication based on a username that is presented in phase one; however, whether the username is protected during phase one depends on 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 that is usually sent in clear text.

ACS supports password aging with EAP-FAST for users who are authenticated by Windows user databases. Password aging can work with 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 the ACS Internal Database, page 5-15.

About Master Keys

EAP-FAST master keys are strong secrets that ACS automatically generates and of which only ACS is aware. Master keys are never sent to an end-user client. EAP-FAST requires master keys for two purposes:

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

•EAP-FAST phase one—ACS determines whether the PAC that the end-user client presents was generated by one of the master keys it is aware of: the active master key or a retired master key.

To increase the security of EAP-FAST, ACS changes the master key that it uses to generate PACs. ACS uses time-to-live (TTL) values that you define to determine when it generates a new master key and the age of all master keys. Based on TTL values, ACS assigns master keys one of the these states:

•Active—An active master key is the master key used by ACS to generate PACs. The master key TTL setting determines the duration that a master key remains active. At any time, only one master key is active. When you define TTLs for master keys and PACs, 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 you configure ACS 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 ACS has not received new master keys in replication, you can force ACS to generate its own master keys by checking the EAP-FAST Master Server check box and clicking Submit.

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 the duration that the Retired master key TTL settings specify. ACS can store up to 255 retired master keys. While a retired master key is not used to generate new PACs, ACS needs it to authenticate PACs that were generated by using it. When you define TTLs for master keys and retired master keys, ACS permits only TTL settings that require storing 255 or fewer retired master keys. For example, if the master key TTL is one hour and the retired master key TTL is four weeks, this would require storing up to 671 retired master keys; therefore, an error message appears and ACS does not allow these settings.

When a user gains network access by using a PAC that is generated with a retired master key, ACS provides the end-user client with a new PAC that the active master key generated. For more information about ACS 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 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 that an expired master key cannot be used to access your network. An end-user client presenting a PAC that generated an expired master key requires a new PAC by using automatic or manual provisioning before phase one of EAP-FAST can succeed.

About PACs

PACs are strong shared secrets that enable ACS and an EAP-FAST end-user client to authenticate each other and establish a TLS tunnel for use in EAP-FAST phase two. ACS generates PACs by using the active master key and a username.

PAC comprises:

•PAC-Key—Shared secret bound to a client (and client device) and server identity.

•PAC Opaque—Opaque field that the client caches and passes to the server. The server recovers the PAC-Key and the client identity to mutually authenticate with the client.

•PAC-Info—At a minimum includes the server's identify to enable the client to cache different PACs. Optionally, it includes other information such as the PACs expiration time.

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. PACs remove the need for PKI (digital certificates).

During EAP-FAST phase one, the end-user client presents the PAC that it has for the current user and Authority ID that ACS sends at the beginning of the EAP-FAST transaction. ACS determines whether the PAC was generated using one of the master keys it is aware of: active or retired. (A PAC that is generated by using a master key that has since expired can never be used to gain network access.) When an end-user client has a PAC that is 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, ACS refreshes them as that master key and PAC TTL values specify. 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 might require that PAC provisioning occur. For more information about how master key and PAC states determine whether 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 that you define, a user will require PAC provisioning when the user does not use EAP-FAST to access the network before the master key that generated the user's PAC has expired. For example, if the master key TTL is one week old and the retired master key TTL is one week old, each EAP-FAST end-user client used by someone who goes on vacation for two weeks will require PAC provisioning.

Provisioning Modes

ACS supports out-of-band and in-band provisioning modes. The in-band provisioning mode operates inside an Authenticated Diffie-HellmanKey Agreement Protocol (ADHP) tunnel before the peer authenticates the ACS server.

Since an unauthenticated server is provisioned, it is not possible to use a plain text password; so only MS-CHAP credentials can be used inside the tunnel. MS-CHAPv2 is used to prove the peer's identity and receives a PAC for further authentication sessions. This method minimizes the risk of exposing the user's credentials.

EAP-FAST has been enhanced to support an authenticated tunnel (using the server certificate) inside which PAC provisioning occurs. The new cipher suites that are enhancements to EAP-FAST and specifically the server certificate are used.

Since the server is authenticated as part of setting up the tunnel, weaker EAP methods, such EAP-GTC can be used inside the tunnel to provide supplicant authentication.

At the end of a provisioning session that uses an authenticated tunnel, network access can be granted; since the server and user have authenticated each other.

ACS supports the following EAP types inside the tunnel for provisioning:

•EAP-GTC

•EAP-MS-CHAPv2

•EAP-TLS

Types of PACs

ACS provisions supplicants with a PAC that contains a shared secret that is used in building a TLS tunnel between the supplicant and ACS. ACS provisions supplicants with PAC that have a wider contextual use.

The following types of PACs are provisioned to ACS, as per server policies:

•Tunnel (Shared Secret) PAC, user or machine—Distributed shared secret between the peer and ACS that is used to establish a secure tunnel and convey the policy of what must and can occur in the tunnel. The policy can include EAP methods, TLV exchanges, and identities that are allowed in the tunnel. It is up to the server policy to include what's necessary in PAC to enforce the policy in subsequent authentications that use the PAC. For example, in EAP-FAST Protocol Version 1, user identity I-ID is included as the part of the server policy. It limits the inner EAP methods to be carried only on the user identity that is provisioned. Other types of information can also be included, such as which EAP method and which cipher suite is allowed, for example. If the server policy is not included in the PAC, then no validation or limitation on the inner EAP methods or user identities inside the tunnel established by use of this PAC. The PAC user of machine contains a type field. The format for the machine will be host/name of machine.

•User Authorization PAC—Distributed user authentication and authorization result based on a previous authentication. You can use it a with combination of the Tunnel PAC to bypass subsequent user authentication. This result is intended to be short-lived and also controlled by the peer. If any state of the user has changed that will affect the user authentication result (for example, user has logged on or off), the peer should discard it and not use it again. You can use the User Authorization PACs in combination of Tunnel PAC to allow a stateless server session resume as described in Stateless Session Server Resume.

•Posture PAC—Distributed posture checking and authorization result based on a previous posture validation. You can use a posture PAC to optimize posture validation in the case of frequent revalidations. This result is specific to the posture validation application and may be used outside the contents of EAP-FAST.

The various means by which an end-user client can receive PACs are:

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

The two supported means of PAC provisioning are:

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

–Manual provision—Requires that you use ACS to generate a PAC file for the user, copy the PAC file to the computer that is 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, which the PAC TTL setting determines:

•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 that was 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 that is 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, 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 ACS administrator, provided that you configure ACS and the end-user client to support automatic provisioning.

EAP-FAST phase zero requires EAP-MS-CHAPv2 authentication of the user. At successful user authentication, ACS establishes a Diffie-Hellman tunnel with the end-user client. ACS generates a PAC for the user and sends it to the end-user client in this tunnel, along with the Authority ID and Authority ID information about this ACS.

Note Because EAP-FAST phase zero and phase two use different authentication methods (EAP-MS-CHAPv2 in phase zero versus EAP-GTC in phase two), some databases that support phase two cannot support phase zero. Given that 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 ACS can support EAP-FAST phase zero and phase two, see Authentication Protocol-Database Compatibility, page 1-8.

No network service is enabled by phase zero of EAP-FAST; therefore, 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 ACS performs automatic PAC provisioning, you use the options on the Global Authentication Setup page in the System Configuration section. For more information, see EAP-FAST Configuration Page.

Manual PAC Provisioning

Manual PAC provisioning requires an 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 ACS deployment includes network segmentation, wherein access to each network segment is controlled by a separate 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 ACSs, 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 ACS. For more information, see Table 9-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, this type of provisioning is the most secure means for distributing PACs. We recommend that, after a large EAP-FAST deployment, you should manually perform PAC provisioning to ensure the highest security for PACs.

You can generate PAC files for specific usernames, groups of users, lists of usernames, 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.

Note ACS for Windows only: ACS for Windows supports the generation of PAC files with CSUtil.exe. For more information about generating PACs with CSUtil.exe, see PAC File Generation, page D-25.

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

Table 9-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 Database Replication feature supports the replication of EAP-FAST settings, Authority ID, and master keys. Replication of EAP-FAST data occurs only if on the:

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

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

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

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

EAP-FAST-related replication occurs for three events:

•Generation of master keys—A primary ACS sends newly generated active and backup master keys to secondary ACSs. This event occurs immediately after master key generation, provided that you configure the replication properly and it 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 ACS. Some of the replicated components are configurable in the web interface. Table 9-2 shows whether an EAP-FAST component is replicated or configurable.

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

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

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

Table 9-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 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 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 ACS.

The EAP-FAST master server setting has a significant effect on EAP-FAST authentication and replication:

•Enabled—When you check the EAP-FAST master server check box, the Actual EAP-FAST server status is Master and ACS ignores the EAP-FAST settings, Authority ID, and master keys it receives from a primary ACS during replication, preferring instead to use master keys that it generates, its unique Authority ID, and the EAP-FAST settings that are configured in its web interface.

Enabling the EAP-FAST master server setting requires providing a PAC from the primary ACS that is different than the PAC from the secondary ACS for the end-user client. Because the primary and secondary ACSs 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 that the primary ACS generates is not accepted by the secondary ACS in a replication scheme where the EAP-FAST master server setting is enabled on the secondary ACS.

Tip In a replicated 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 you do not check the EAP-FAST master server check box, ACS continues to operate as an EAP-FAST master server until the first time it receives replicated EAP-FAST components from the primary ACS. When Actual EAP-FAST server status displays the text Slave, ACS uses the EAP-FAST settings, Authority ID, and master keys that it receives from a primary ACS during replication; rather than using the master keys that it generates and its unique Authority ID.

Note When you uncheck the EAP-FAST master server check box, the Actual EAP-FAST server status remains Master until 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, ACS acts as a master EAP-FAST server by using master keys that it generates, its unique Authority ID, and the EAP-FAST settings that are configured in its web interface.

Disabling the EAP-FAST master server setting eliminates the need for providing a different PAC from the primary and secondary ACSs. This elimination occurs because the primary and secondary ACSs 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 ACS. Also, a PAC that one ACS generated for a user in a replication scheme where the EAP-FAST master server setting is disabled is accepted by all other ACSs in the same replication scheme.

For more information about replication, see ACS Internal Database Replication, page 8-1.

Enabling EAP-FAST

This section explains the procedures to configure ACS to support EAP-FAST authentication.

Note You must configure the end-user clients to support EAP-FAST. This procedure is specific to configuring 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 on user database support.

To enable ACS to perform EAP-FAST authentication:

Step 1 Configure a user database that supports EAP-FAST authentication. To determine which user databases support EAP-FAST authentication, see Authentication Protocol-Database Compatibility, page 1-8. For user database configuration, see Chapter 12, "User Databases."

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

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 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, if you reduce the TTL values with which you initially deploy EAP-FAST, 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 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 that you limit 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 replacing PACs based on expired master keys.

Step 4 Using the decisions during Step 2 and Step 3, enable EAP-FAST on the Global Authentication Setup page. For detailed steps, see Configuring Authentication Options.

ACS is ready to perform EAP-FAST authentication.

Stateless Session Server Resume

To provide better support for server performance, load balancing and peer roaming to different servers, EAP-FAST supports the stateless-server session resume by using the short-lived Authorization PACs. Once a peer establishes a TLS session and is authenticated, the EAP server can provision it with a Tunnel PAC. The tunnel PAC can be used to establish a TLS session much more quickly than a normal TLS handshake. With the normal TLS session resume, the EAP server must maintain the TLS session cache, as well as the peer's authentication and authorization result. This storage requirement often hinders the server's performance, as well as introduces difficulties with server load balancing and peer roaming to different servers. The use of Tunnel PAC eliminates the server's need to maintain a TLS session cache. The TLS session can be quickly established in a fast and secure way; however, the server still has to cache the peer's previous authentication and authorization state for a quick session resume.

You can further optimize by using the User Authorization PAC in combination with the Tunnel PAC. The server generated key protects User Authorization PACs which store previous authentication and authorization states on the peer. If the peer has the authorization PACs corresponding to the EAP server connected (by matching A-ID), and detects no state change affecting the peer, the peer can piggyback the opaque part of these PACs in the PAC-TLV with Client TLS Finished as TLS application data, which the TLS cipher suite that is negotiated protects. This method prevents attackers from snooping the authorization PACs without introducing an extra round trip. Once the EAP server receives and decrypt the authorization PAC, the EAP server can recreate its previous state information based on the peer's authentication and authorization result. If the state information in these PACs is still valid, based on a server side policy, it might bypass one or all of the inner EAP method authentications. In case inner methods are bypassed, the EAP Server sends the Result TLV only without the Crypto-binding TLV, and the peer responds with Result TLV with Success. The EAP-Server may start a full sequence of EAP authentication or a partial sequence if one or all of the PACs are not present or accepted.

ACS supports the following inner methods and TLV exchange support combinations:

•EAP-MS-CHAP Authentication + Posture Validation TLV exchange

•EAP-GTC Authentication + Posture Validation TLV exchange

•EAP-TLS Authentication + Posture Validation TLV exchange

•Posture Validation TLV exchange without authentication

Global Authentication Setup

You use the Global Authentication Setup page to enable or disable some of the authentication protocols that ACS supports. You can also configure other options for some of the protocols on the Global Authentication Setup page.

This section contains the following topics:

•Configuring Authentication Options

•EAP-FAST Configuration Page

Caution Network Access Profile settings override the global authentication settings.

Configuring Authentication Options

Use this procedure to select and configure how 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 MS-CHAP Version 1, 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 about how various databases support various password protocols, see Authentication Protocol-Database Compatibility, page 1-8.

You use the EAP-FAST Configuration Page to set up authentication configuration options.

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

Before You Begin

For information about the options see the EAP-FAST Configuration Page.

To configure authentication options:

Step 1 In the navigation bar, click System Configuration.

Step 2 Click Global Authentication Setup.

The Global Authentications page appears.

Step 3 Configure options, as applicable. For more information about the significance of the options, see EAP-FAST Configuration Page.

Step 4 If you want to immediately implement the settings that you have made, click Submit + Apply.

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

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

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

ACS saves the authentication configuration options that you selected.

ACS Certificate Setup

This section contains the following topics:

•Installing an ACS Server Certificate

•Adding a Certificate Authority Certificate

•Editing the Certificate Trust List

•Managing Certificate Revocation Lists

•Generating a Certificate Signing Request

•Using Self-Signed Certificates

•Updating or Replacing an ACS Certificate

Installing an ACS Server Certificate

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

The three options for obtaining your server certificate are:

•Obtain a certificate from a CA.

•Use an existing certificate from local machine storage.

•Generate a self-signed certificate.

Before You Begin

You must have a server certificate for your ACS before you can install it. With ACS, certificate files must be in Base64-encoded X.509. If you do not already have a server certificate in storage, you can use the procedure in Generating a Certificate Signing Request, or any other means, to obtain a certificate for installation.

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 on your ACS. After you have installed a replacement certificate, you should determine whether you need to reconfigure any CTL or CRL settings.

If you want to use a server certificate from local machine storage, we recommend that you read Extensible Authentication Protocol Transport Layer Security Deployment Guide for Wireless LAN Networks, available on the ACS CD and at http://www.cisco.com/warp/public/cc/pd/sqsw/sq/tech/
index.shtml. This white paper provides information about how to add a certificate to machine storage and how to configure a Microsoft certification authority server for use with ACS.

To install an existing certificate for use on ACS:

ACS for Windows

Step 1 In the navigation bar, click System Configuration.

Step 2 Click ACS Certificate Setup.

Step 3 Click Install ACS Certificate.

ACS displays the Install ACS Certificate page.

Step 4 You must specify whether ACS reads the certificate from a specified file or uses a certificate already on the local machine. To specify that ACS:

•Reads the certificate from a specified file, select the Read certificate from file option, and then type the full directory path and filename of the certificate file in the Certificate file box.

•Uses a particular existing certificate from local machine certificate storage, select the Use certificate from storage option, and then type the certificate CN (common name or subject name) in the Certificate CN box.

Tip Type the certificate CN only; omit the cn= prefix.

Step 5 If you generated the request by using ACS, in the Private key file box, type the full directory path and name of the file that contains the private key.

Note If the certificate was installed in storage with the private key, you do not have the private key file and do not need to type it.

Tip This is the private key that is associated with the server certificate.

Step 6 In the Private key password box, type the private key password.

Tip If you used ACS to generate the certificate signing request, this is the same value that you entered as the Private key password on the Generate Certificate Signing Request page. If the private key file is unencrypted, leave this box empty.

Step 7 Click Submit.

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

•Issued to: certificate subject

•Issued by: CA common name

•Valid from:

•Valid to:

•Validity:

ACS Solution Engine

Step 1 In the navigation bar, click System Configuration.

Step 2 Click ACS Certificate Setup.

Step 3 Click Install ACS Certificate.

ACS displays the Install ACS Certificate page.

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

The Download Certificate File page appears.

Step 5 To download the certificate file to ACS, enter the following information into the Download File table:

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

Tip If you specify the