-
User Guide for Cisco Secure ACS for Windows 4.0
-
Preface
-
Overview
-
Deployment Considerations
-
Interface Configuration
-
Network Configuration
-
Shared Profile Components
-
User Group Management
-
User Management
-
System Configuration: Basic
-
System Configuration: Advanced
-
System Configuration: Authentication and Certificates
-
Logs and Reports
-
Administrators and Administrative Policy
-
User Databases
-
Posture Validation
-
Network Access Profiles
-
Unknown User Policy
-
User Group Mapping and Specification
-
Troubleshooting
-
TACACS+ Attribute-Value Pairs
-
RADIUS Attributes
-
CSUtil Database Utility
-
VPDN Processing
-
RDBMS Synchronization Import Definitions
-
Internal Architecture
-
Index
-
Feedback
Table Of Contents
System Configuration: Authentication and Certificates
About Certification and EAP Protocols
Enabling EAP-TLS Authentication
PEAP and the Unknown User Policy
Stateless Session Server Resume
Configuring Authentication Options
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
System Configuration: Authentication and Certificates
This chapter addresses authentication and certification features in the System Configuration section of Cisco Secure Access Control Server Release 4.0 for Windows, hereafter referred to as ACS.
This chapter contains the following topics:
•
About Certification and EAP Protocols
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. Digital certification, EAP-TLS, PEAP, EAP-FAST, and machine authentication are described in the topics that follow.
This section contains the following topics:
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
EAP-TLS Authentication
This section contains the following topics:
•
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: 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:
•
•
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:
•
•
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. 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/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.
ACS supports domain stripping for EAP-TLS authentication by using Windows Active Directory. For more information, see EAP-TLS Domain Stripping.
ACS also supports three methods of certificate comparison and a session resume feature. This topic discusses these features.
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:
•
•
•
Note
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
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:
•
•
•
Enabling EAP-TLS Authentication
This explains the procedures that are required to configure ACS to support EAP-TLS authentication.
Note
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
Note
Step 2
Step 3
Step 4
Step 5
ACS is ready to perform EAP-TLS authentication.
PEAP Authentication
This section contains the following topics:
•
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. lRSA, Cisco, and Microsoft have posted a PEAP IETF Internet Draft that is available at:
http://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-05.
PEAP authentications always involve two phases:
•
Note
•
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 the Windows XP Service Pack 1, ACS supports only PEAP(EAP-MS-CHAPv2). 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 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.
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.
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
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.
Enabling PEAP Authentication
This procedure provides an overview of the detailed procedures that are required to configure ACS to support PEAP authentication.
Note
To enable PEAP authentication:
Step 1
Note
Step 2
Step 3
ACS is ready to perform PEAP authentication for most users. For more information, see PEAP and the Unknown User Policy.
Step 4
EAP-FAST Authentication
This section contains the following topics:
About EAP-FAST
The EAP Flexible Authentication via Secured Tunnel (EAP-FAST) protocol is a client-server security architecture that encrypts EAP transactions with a TLS tunnel. While similar to PEAP in this respect, it differs significantly in that EAP-FAST tunnel establishment is based 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:
•
Note
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.
•
No network service is enabled by phase one of EAP-FAST.
•
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
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 Users in Windows Databases.
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:
•
•
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:
•
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
ACS records the generation of master keys in the logs for the CSAuth service.
•
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.
•
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:
•
•
•
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:
•
•
•
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:
•
•
•
The various means by which an end-user client can receive PACs are:
•
The two supported means of PAC provisioning are:
–
–
•
PACs have the following two states, which the PAC TTL setting determines:
•
•
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
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
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 Global Authentication Setup 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
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. ACS for Windows Server supports the generation of PAC files with
CSUtil.exe. For more information about generating PACs withCSUtil.exe, see PAC File Generation.Master Key and PAC TTLs
The TTL values for master keys and PACs determine their states, as described in About Master Keys and About PACs. master key and PAC states determine whether someone requesting network access with EAP-FAST requires PAC provisioning or PAC refreshing.
Table 10-1 summarizes ACS behavior with respect to PAC and master key states.
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:
•
•
•
•
EAP-FAST-related replication occurs for three events:
•
•
Note
•
The Database Replication log on the primary ACS records replication of master keys. Entries related to master key replication contain the text
MKEYReplicate.
The EAP-FAST master server setting has a significant effect on EAP-FAST authentication and replication:
•
Actual EAP-FAST server statusisMasterand 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
•
Actual EAP-FAST server statusdisplays the textSlave, 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
Actual EAP-FAST server statusremainsMasteruntil ACS receives replicated EAP-FAST components and then theActual EAP-FAST server statuschanges toSlave. UntilActual EAP-FAST server statuschanges toSlave, 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.
Enabling EAP-FAST
This section explains the procedures to configure ACS to support EAP-FAST authentication.
Note
Before You Begin
The steps in this procedure are a suggested order only. Enabling EAP-FAST at your site may require recursion of these steps or performing these steps in a different order. For example, in this procedure, determining how you want to support PAC provisioning comes after configuring a user database to support EAP-FAST; however, choosing automatic PAC provisioning places different limits on user database support.
To enable ACS to perform EAP-FAST authentication:
Step 1
Note
ACS supports use of the Unknown User Policy and group mapping with EAP-FAST, as well as password aging with Windows external user databases.
Step 2
Also, if you reduce the TTL values 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
Note
Step 4
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:
•
•
•
•
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:
•
•
Caution
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.
You use the Global Authentication Setup Page to set up authentication configuration options.
Note
Before You Begin
For information about the options see the Global Authentication Setup Page.
To configure authentication options:
Step 1
Step 2
The Global Authentications page appears.
Step 3
Step 4
ACS restarts its services and implements the authentication configuration options that you selected.
Step 5
Tip
ACS saves the authentication configuration options that you selected.
Global Authentication Setup Page
This page contains:
PEAP
You can configure the following options for PEAP:
•
•
Note
•
•
Enter your message. The message is limited to 40 characters.•
•
Fast recondition can occur only when ACS allows the session to resume because the session has not timed out. If you disable the PEAP session resume feature by entering zero (0) in the PEAP session timeout (minutes) box, checking the Enable Fast Reconnect check box has no effect on PEAP authentication and phase two of PEAP authentication always occurs.
EAP-FAST
EAP-FAST Configuration—Select to open the EAP-FAST Configuration Page.
Note
EAP-TLS
Check this box to use the EAP TLS Authentication protocol and configure EAP-TLS settings. You can specify how ACS verifies user identity as presented in the EAP Identity response from the end-user client. User identity is verified against information in the certificate presented by the end-user client. This comparison occurs after an EAP-TLS tunnel is established between ACS and the end-user client. Select one of:
Note
Select one or more EAP-TLS comparison methods. If you select more than one comparison type, ACS performs the comparisons in the order listed. If the one comparison type fails, ACS attempts the next enabled comparison type. Comparison stops after the first successful comparison.
•
•
•
EAP-TLS session timeout (minutes)—Enter a value in minutes for that defines the maximum time for the EAP-TLS session.
ACS supports an EAP-TLS session resume feature that caches the TLS session created during a new EAP-TLS authentication. When an EAP-TLS client reconnects, the cached TLS session is used to restore the session without performing a certificate comparison, which improves EAP-TLS performance. ACS deletes cached TLS sessions when they time out. If ACS or the end-user client is restarted, certificate comparison is required even if the session timeout interval has not ended. To disable the session resume feature, set the timeout value to zero (0).
LEAP
The Allow LEAP (For Aironet only) check box controls whether ACS performs LEAP authentication. LEAP is currently used only for Cisco Aironet wireless networking. If you disable this option, Cisco Aironet end-user clients who are 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
EAP-MD5
To enable EAP-based Message Digest 5 hashed authentication, check this check box.
Allow EAP request timeout (seconds)
You use this option to instruct Cisco Aironet Access Points (APs) to use the specified timeout value during EAP conversations. The value that is specified must be the number of seconds after which Cisco Aironet APs should assume that an EAP transaction with ACS has been lost and should be restarted. A value of zero (0) disables this feature.
During EAP conversations, ACS sends the value that is defined in the AP EAP request timeout box by using the IETF RADIUS Session-Timeout (27) attribute.
MS-CHAP Configuration
For RADIUS authentication, ACS supports MS-CHAP versions 1 and 2. You can configure whether ACS authenticates users with MS-CHAP when the AAA protocol is RADIUS and, if so, which versions it uses.
To enable MS-CHAP in RADIUS-based authentication, check the check box corresponding to the MS-CHAP version that you want to use. To allow MS-CHAP to use either version, check both check boxes.
To disable MS-CHAP in RADIUS-based authentication, clear both check boxes.
Note
EAP-FAST Configuration Page
This page contains:
Allow EAP-FAST
Whether ACS permits EAP-FAST authentication.
Active master key TTL
The duration that a master key is used to generate new PACs. Enter a value for the amount of time that a master key is used to generate new Protected Access Credentials (PACs). When the time to live (TTL) that is defined for the Master Key expires, the master key is considered retired and a new master key is generated.The default master key TTL is one month. 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 that are based on the newly expired master keys. For more information about master keys, see About Master Keys.
Retired master key TTL
Enter a value for the amount of time that PACs that are generated by using a retired master key are acceptable for EAP-FAST authentication. When an end-user client gains network access by using a PAC that is based on a retired master key, ACS sends a new PAC to the end-user client. The default retired master key TTL is three months.
Note
Tunnel PAC TTL
The duration that a PAC is used before it expires and must be replaced. Enter a value for the amount of time that a PAC is used before it expires and must be replaced. If the master key that is used to generate the Tunnel PAC has not expired, new PAC creation and assignment is automatic. If the master key used to generate the Tunnel PAC that expired, you must use automatic or manual provisioning to provide the end-user client with a new PAC.
For more information about PACs, see About PACs.
Client initial display message
Specify a message to be sent to users who authenticate with an EAP-FAST client. Maximum length is 40 characters. A user will see the initial message only if the end-user client supports its display.
Authority ID Info
The textual identity of this ACS server, which an end user can user to determine which ACS server to be authenticated against. Filling in this field is mandatory.
Allow anonymous in-band PAC provisioning
ACS provisions an end-user client with a PAC by using EAP-FAST phase zero. If you check this check box, 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 the only inner method in phase zero.
Allow authenticated in-band PAC provisioning
ACS provisions an end-user client with a PAC by using EAP-FAST phase zero with SSL server-side authentication. This option requires that a server certificate and a trusted root CA are installed on ACS. One of the allowed inner methods will then be used to authenticate the user.
In addition, the client may send its certificate to the server, causing the mutual TLS authentication. In this case, ACS skips the inner methods and provisions the PAC.
Accept client on authenticated provisioning
This option is only available when the allow authenticated in-band PAC provisioning option is selected. The server always sends an Access-Reject at the end of the provisioning phase, forcing the client to reauthenticate using the tunnel PAC. This option enables ACS to send an Access-Accept to the client at the end of the provisioning phase.
Require client certificate for provisioning
Allows provisioning PACs based on certificates only. Other inner EAP methods for PAC provisioning are not allowed. If the client does not present its certificate during the first TLS handshake, the server initiates a TLS renegotiation. The renegotiation requests the client to start a new TLS handshake; the cipher that was negotiated in the first handshake protects it. During the second TLS handshake, the server requests the client 's certificate. If the certificate is not sent, the handshake fails and the user is denied access.
Allow Machine Authentication
ACS provisions an end-user client with a machine PAC and performs machine authentication (for end-user clients who do not have the machine credentials). The machine PAC can be provisioned to the client by request (in-band) or by administrator (out-of-band). When ACS receives a valid machine PAC from the end-user client, the machine identity details are extracted from the PAC and verified in the ACS database or external databases. After these details are correctly verified, no further authentication is performed.
Note
Machine PAC TTL
Enter a value for the amount of time that a machine PAC is acceptable for use. When ACS receives an expired machine PAC, it automatically reprovisions the end-user client with a new machine PAC (without waiting for a new machine PAC request from the end-user client).
Allow Stateless session resume
Uncheck this option:
•
•
Authorization PAC TTL
This option determines the expiration time of the user authorization PAC. When ACS receives an expired authorization PAC, Allow Stateless session resume fails and, therefore, phase two EAP-FAST authentication is performed.
Allowed inner methods
This option determines which inner EAP methods can run inside the EAP-FAST TLS tunnel. For anonymous in-band provisioning, you must enable EAP-GTC and EAP-MS-CHAP for backward compatibility. If you selected Allow anonymous in-band PAC provisioning, you must select EAP-MS-CHAP (phase zero) and EAP-GTC (phase two). If you selected Allow authenticated in-band PAC provisioning, the inner method in the authentication phase is negotiable. (EAP-GTC is used by default in phase zero.) Select one or more of the following inner methods:
•
•
•
Note
Select one or more of the following EAP-TLS comparison methods:
Select one or more EAP-TLS comparison methods. If you select more than one comparison type, ACS performs the comparisons in the order listed. If the one comparison type fails, ACS attempts the next enabled comparison type. Comparison stops after the first successful comparison.
•
•
•
EAP-TLS session timeout (minutes)
EAP-TLS session timeout (minutes)—Enter a value in minutes that defines the maximum time for the EAP-TLS session.
ACS supports an EAP-TLS session resume feature that caches the TLS session created during a new EAP-TLS authentication. When an EAP-TLS client reconnects, the cached TLS session is used to restore the session without performing a certificate comparison, which improves EAP-TLS performance. ACS deletes cached TLS sessions when they time out. If ACS or the end-user client is restarted, certificate comparison is required; even if the session timeout interval has not ended. To disable the session resume feature, set the timeout value to zero (0).
EAP-FAST Master Server
Select this check box to determine whether ACS creates its own master keys, and uses its own EAP-FAST settings and Authority ID; or, if it uses the EAP-FAST settings, master keys, and Authority ID received from another (slave or replicated) ACS that has been replicated. If you change this setting, click Submit + Restart.
Actual EAP-FAST server status
This option displays the status of the ACS. If you uncheck the EAP-FAST master server check box, the server status does not change to
Slaveuntil after ACS receives replicated EAP-FAST settings.Note
Masteruntil ACS receives replicated EAP-FAST components.
ACS Certificate Setup
This section contains the following topics:
•
•
•
•
•
•
•
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:
•
•
•
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:
Step 1
Step 2
Step 3
ACS displays the Install ACS Certificate page.
Step 4
•
•
Tip
Step 5
Note
Tip
Step 6
Tip
Step 7
To show that the certificate setup is complete, ACS displays the Installed Certificate Information table, which contains:
•
•
•
•
•
Adding a Certificate Authority Certificate
Use this procedure to add new CA certificates to ACS local certificate storage.
Note
When a user certificate is from an unknown CA (that is, one that is different from the CA that certifies the ACS), you must specifically configure ACS to trust that CA or authentication fails. Until you perform this procedure to explicitly extend trust by adding another CA, ACS only recognizes certificates from the CA that issued its own certificate.
Configuring ACS to trust a specific CA is a two-step process that comprises this procedure of adding a CAs certificate and the procedure in Editing the Certificate Trust List, in which you specify that the particular CA is to be trusted. (ACS comes configured with a list of popular CAs, none of which is enabled until you explicitly specify trustworthiness.)
To add a certificate authority certificate to your local storage:
Step 1
Step 2
Step 3
ACS displays the CA Operations table on the Certification Authorities Setup page.
Step 4
Step 5
The new CA certificate is added to local certificate storage. And, if it is not already there, the name of the CA that issued the certificate is placed on the CTL.
Tip
Editing the Certificate Trust List
ACS uses the CTL to verify the client certificates. For ACS to trust a CA, its certificate must be installed and the ACS administrator must explicitly configure the CA as trusted by editing the CTL. If the ACS server certificate is replaced, the CTL is erased; you must then configure the CTL explicitly each time you install or replace a ACS server certificate.
Note
How you edit your CTL determines the type of trust model that 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 increased security for greater adaptability and scalability.
We recommend that you fully understand the implications of your trust model before editing the CTL in ACS.
Use this procedure to configure CAs on your CTL as trusted or not trusted. Before you can configure a CA 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 ACS to trust, authentication fails.
To edit the CTL:
Step 1
Step 2
Step 3
The Edit the Certificate Trust List (CTL) table appears.
WarningStep 4
Tip
Step 5
ACS configures the specified CA (or CAs) as trusted or not trusted in accordance with checking or unchecking check boxes. The selected Certificate Trust Lists automatically appear on the CRL Issuers page.
Managing Certificate Revocation Lists
Certificate revocation lists (CRLs) are the means by which ACS determines that the certificates employed by users who seek authentication are still valid, according to the CA that issued them.
This section contains the following topics:
•
•
•
About Certificate Revocation Lists
When a digital certificate is issued, you generally expect it to remain valid throughout its predetermined period of validity. However, various circumstances may call for invalidating the certificate earlier than expected. Such circumstances might include compromise or suspected compromise of the corresponding private key, or a change in the CAs issuance program. Under such circumstances, a CRL provides the mechanism by which the CA revokes the legitimacy of a certificate and calls for its managed replacement.
ACS performs certificate revocation by using the X.509 CRL profile. A CRL is a signed and time-stamped with a data structure that a CA (or CRL issuer) issues and which is freely available in a public repository (for example, in an LDAP server). Details on the operation of the X.509 CRL profile are contained in RFC3280.
CRL functionality in ACS includes:
•
•
full. The status, date, and time of the last retrieval appears on the Certificate Revocation List Issuer edit page of the ACS web interface.
Note
•
CRL issuers can only be added in association with trusted CAs (that is, CAs on the CTL). If you install a new server certificate for ACS, your CTL is cleared of all trust relationships. While you must reestablish CAs on the CTL, the associated CRLs that you previously configured remain in place and do not have to be reconfigured.
Certificate Revocation List Configuration Options
The Certificate Revocation List Issuers edit page contains the following configuration options:
•
•
•
CRL distribution pointsparameter, this field will be populated automatically. Otherwise, ensure that you specify a URL for the CRL corresponding to the CA that you selected from the Issuer's Certificate list. You can specify a URL that uses HTTP, LDAP, or FTP. Alternatively, you can specify the URL for the file itself; however, this is only necessary when the repository URL lists multiple files.An example of an HTTP URL is:
http://crl.verisign.com/pca1.1.1.crl.
An example of an LDAP URL is:
ldap://10.36.193.5:388/CN=development-CA,CN=acs-westcoast2,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=cisco,DC=com
Note
CertificateRevocationList).
Tip
•
–
–
Note
Note
•
•
When the Ignore Expiration Date is unchecked, ACS examines the expiration date of the CRL in the Next Update field in the CRL file and continues to use this CRL; even though it has expired. If the expiry date passed, the CRL is not valid and all EAP-TLS authentications will be rejected.
When the Ignore Expiration Date is checked, ACS continues to use the expired CRL and permits or rejects EAP-TLS authentications according to the contents of the CRL.
•
•
When submission succeeds, you must restart ACS to apply the new configuration.
Editing a Certificate Revocation List Issuer
To edit a certificate revocation list issuer:
Step 1
Step 2
Step 3
The CRL Issuers page appears.
Step 4
The system displays the CRL Issuer Edit page for the CRL that you chose.
Step 5
Step 6
The corresponding CRL is changed in ACS to that of the edited issuer (or is scheduled to be changed at the time that you specify in the Retrieve CRL field).
Tip
Generating a Certificate Signing Request
You can use 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
To generate a certificate signing request:
Step 1
Step 2
ACS displays the Generate Certificate Signing Request page.
Step 3
field=value, field=value,. . .where field is the field name, such as CN, and value is the applicable value for the field, such as acs01primary. You can type a maximum of 256 characters in the Certificate subject box. Separate multiple values with commas (,); for example:
CN=acs01primary, O=WestCoast, C=US, S=CaliforniaTable 10-3 defines the valid fields that you can include in the Certificate subject box.
Step 4
c:\privateKeyFile.pem.Step 5
Step 6
Step 7
Tip
Step 8
Step 9
ACS displays a CSR on the right side of the browser.
Step 10
After you receive the certificate from the CA, you can perform the steps in Installing an ACS Server Certificate.
Using Self-Signed Certificates
You can use ACS to generate a self-signed digital certificate to use for the PEAP authentication protocol or HTTPS support of ACS administration. This capability supports TLS/SSL protocols and technologies without the requirement of interacting with a CA.
This section contains the following topics:
•
•
•
About Self-Signed Certificates
ACS supports TLS/SSL-related protocols, including PEAP, EAP-FAST, and HTTPS, that require the use of digital certificates. Employing self-signed certificates is a way for administrators to meet this requirement without having to interact with a CA to obtain and install the certificate for the ACS. The administrator uses the self-signed certificate feature in ACS to generate the self-signed digital certificate, and use it for the PEAP and EAP-FAST authentication protocols or for HTTPS support in web administration service.
Other than the lack of interaction with a CA to obtain the certificate, installing a self-signed certificate requires exactly the same user actions as any other digital certificate. Although ACS does not support the replication of self-signed certificates, you can export a certificate for use on more than one ACS. To do this, you copy the certificate file (.cer format) and the corresponding private key file (.pvk format) to another ACS where you then install the certificate in the standard manner. For information on installing certificates, see Installing an ACS Server Certificate.
To ensure that a self-signed certificate interoperates with the client, refer to your client documentation. You may find that you must import the self-signed server certificate as a CA certificate on your particular client.
Self-Signed Certificate Configuration Options
The Generate Self-Signed Certificate edit page contains the following mandatory configuration fields:
•
–
–
–
–
–
–
For example, the Certificate subject field might appear as:
cn=ACS 11, O=Acme Enterprises, E=admin@acme.com•
•
•
•
•
•
•
Generating a Self-Signed Certificate
All fields on the Generate Self-Signed Certificate page are mandatory. For information on the fields' contents, see Self-Signed Certificate Configuration Options.
To generate a self-signed certificate:
Step 1
Step 2
Step 3
The Generate Self-Signed Certificate edit page appears.
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Note
Tip
Step 12
The specified certificate and private key files are generated and stored. If you selected the Install generated certificate option, the certificate becomes operational, only after you restart ACS services.
Updating or Replacing an ACS Certificate
Use this procedure to update or replace an existing ACS certificate that is out of date or out of order.
Caution
To install a new ACS certificate:
Step 1
Step 2
ACS displays the Installed Certificate Information table on the ACS Certificate Setup page.
Note
Step 3
A confirmation dialog box appears.
Step 4
The existing ACS certificate is removed and your CTL configuration is erased.
Step 5
