Cisco Acs 5x User Guide

							B-31
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  CHAP
Windows Machine Authentication Against AD
EAP-MSCHAPv2 can be used for machine authentication. EAP-MSCHAPv2 Windows machine 
authentication is the same as user authentication. The difference is that you must use the Active 
Directory of a Windows domain, since a machine password can be generated automatically on the 
machine and the AD, as a function of time and other parameters. The password generated cannot be 
stored in other types of credential databases.
EAP- MSCHAPv2 Flow in ACS 5.3
Components involved in the 802.1x and MSCHAPv2 authentication process are the: 
Host—The end entity, or end user’s machine.
AAA client—The network access point.
Authentication server—ACS. 
The MSCHAPv2 protocol is described in RFC 2759.
Related Topic
Authentication Protocol and Identity Store Compatibility, page B-35
CHAP
CHAP uses a challenge-response mechanism with one-way encryption on the response. CHAP enables 
ACS to negotiate downward from the most secure to the least secure encryption mechanism, and it 
protects passwords that are transmitted in the process. CHAP passwords are reusable.
If you are using the ACS internal database for authentication, you can use PAP or CHAP. CHAP does 
not work with the Windows user database. Compared to RADIUS PAP, CHAP allows a higher level of 
security for encrypting passwords when communicating from an end-user client to the AAA client.
LEAP
ACS currently uses LEAP only for Cisco Aironet wireless networking. If you do not enable 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.
NoteIf users who access your network by using a AAA client that is defined in the Network Configuration 
section as a RADIUS (Cisco Aironet) device, then you must enable LEAP, EAP-TLS, or both; otherwise, 
Cisco Aironet users cannot authenticate. 
						

							B-32
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  Certificate Attributes
Certificate Attributes
ACS parses the following client certificate’s attributes:
Certificate serial-number (in binary format)
Encoded certificate (in binary DER format)
Subject’s CN attribute
Subject’s O attribute (Organization)
Subject’s OU attribute (Organization Unit)
Subject’s L attribute (Location)
Subject’s C attribute (Country)
Subject’s ST attribute (State Province)
Subject’s E attribute (eMail)
Subject’s SN attribute (Subject Serial Number)
SAN (Subject Alternative Name)
You can define a policy to set the principle username to use in the TLS conversation, as an attribute that 
is taken from the received certificate.
The attributes that can be used as the principle username are:
Subject CN
Subject Serial-Number (SN)
SAN
Subject
SAN—Email
SAN—DNS
SAN—otherName
If the certificate does not contain the configured attribute, authentication fails.
NoteACS 5.3 supports short hard-coded attributes and certificate attribute verification for the only the 
EAP-TLS protocol.
Certificate Binary Comparison
You can perform binary comparison against a certificate that ACS receives from an external identity 
store and determine the identity stores parameters that will be used for the comparison.
NoteIn ACS 5.3, LDAP is the only external identity store that holds certificates.
ACS uses the configured principle username to query for the users certificate and then perform binary 
comparison between the certificate received from external identity store and the one received from the 
client. The comparison is performed on a DER certificate format. 
						

							B-33
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  Certificate Attributes
Rules Relating to Textual Attributes
ACS collects client certificate textual attributes and places them in the ACS context dictionary. ACS can 
apply any rule based policy on these attributes as with any rule attributes in ACS.
The attribute that can be used for rule verification are:
Subjects CN attribute
Subjects O attribute (Organization)
Subjects OU attribute (Organization Unit)
Subjects L attribute (Location)
Subjects C attribute (Country)
Subjects ST attribute (State Province)
Subjects E attribute (eMail)
Subjects SN attribute (Subject Serial Number)
SAN (Subject Alternative Name)
Subject
SAN—Email
SAN—DNS
SAN—otherName
Certificate Revocation
Every client certificate that ACS receives is verified with a Certificate Revocation List (CRL) according 
to a policy that is defined.
The CRL mechanism verifies whether or not you can still rely on a client certificate. This is done by 
checking the serial number of the certificate, and that of each member of the corresponding certificate 
chain, against a list of certificates that are known to have been revoked. 
Possible reasons for revocation of a certificate include suspicion that the associated private key has been 
compromised or the realization that the certificate was issued improperly. If either of these conditions 
exist, the certificate is rejected.
ACS supports a static-CRL that contains a list of URLs used to acquire the CRL files that are configured 
in ACS database.
NoteACS does not support delta CRLs in certificate revocation validation.
You can configure a set of URLs used for CRL update for each trusted CA certificate,. By default, when 
adding a CA certificate, ACS automatically sets all the URLs stored in the certificate 
crlDistributionPoint as the initial static CRL for that CA. In most cases, the crlDistributionPoint is used 
to point to the CRL location used to revoke the CA certificate, but you can edit the URL to point to the 
CRL file issued by this CA. You can only configure a single HTTP based URL for each CA. 
You can configure the parameters for each CA, which will apply to all the URLs that are configured to 
the CA. ACS supports two download modes, one for periodic download, and the other for downloading 
the next CRL update just before the previous is about to expire. 
For the periodic download, you can define the download periods.  
						

							B-34
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  Machine Authentication
For automatic downloading, you define the amount of time before the CRL file expires, should ACS 
download it. The CRL expiration time is taken from the CRL nextUpdate field. 
For both modes, if the download somehow fails, you can define the amount of time that ACS will wait 
before trying to redownload the CRL file.
ACS verifies that the downloaded CRL file is signed correctly by any one of the CAs in the trust store, 
for each downloaded CRL file and whether they are trusted. ACS uses the CRL file only if the signature 
verification passes. The verified CRL file replaces the previous CRL file issued by the same CA. 
NoteCRL files are not kept persistent, and should be re-downloaded when you restart ACS.
The configuration of URLs and their association to CAs is distributed to the entire ACS domain. The 
downloaded CRLs are not distributed and are autonomously populated in parallel in each ACS server.
Machine Authentication
ACS supports the authentication of computers that are running the Microsoft Windows operating 
systems that support EAP computer authentication. Machine authentication, also called computer 
authentication, allows networks services only for computers known to Active Directory. 
This feature is especially useful for wireless networks, where unauthorized users outside the physical 
premises of your workplace can access your wireless access points.
When machine authentication is enabled, there are three different types of authentications. When starting 
a computer, the authentications occur in this order:
Machine authentication—ACS authenticates the computer prior to user authentication. ACS 
checks the credentials that the computer provides against the Windows identity store. 
If you use Active Directory and the matching computer account in AD has the same credentials, the 
computer gains access to Windows domain services.
User domain authentication—If machine authentication succeeded, the Windows domain 
authenticates the user. If machine authentication failed, the computer does not have access to 
Windows domain services and the user credentials are authenticated by using cached credentials that 
the local operating system retains. 
In this case, the user can log in to only the local system. When a user is authenticated by cached 
credentials, instead of the domain, the computer does not enforce domain policies, such as running 
login scripts that the domain dictates.
TipIf a computer fails machine authentication and the user has not successfully logged in to the 
domain by using the computer since the most recent user password change, the cached 
credentials on the computer will not match the new password. Instead, the cached credentials 
will match an older password of the user, provided that the user once successfully logged in to 
the domain from this computer.
User network authentication—ACS authenticates the user, allowing the user to have network 
connectivity. If the user exists, the identity store that is specified is used to authenticate the user. 
While the identity store is not required to be the Windows identity store, most Microsoft clients can 
be configured to automatically perform network authentication by using the same credentials used 
for user domain authentication. This method allows for a single sign-on. 
						

							B-35
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  Authentication Protocol and Identity Store Compatibility
NoteMicrosoft PEAP clients may also initiate machine authentication whenever a user logs off. This feature 
prepares the network connection for the next user login. Microsoft PEAP clients may also initiate 
machine authentication when a user shuts down or restarts the computer rather than just logging off.
ACS supports EAP-TLS, EAP-FAST, PEAP (EAP-MSCHAPv2), and PEAP (EAP-GTC) for machine 
authentication. You can enable each separately on the Active Directory: General Page, which allows a 
mix of computers that authenticate with EAP-TLS, EAP-FAST, or PEAP (EAP-MSCHAPv2). 
Microsoft operating systems that perform machine authentication might limit the user authentication 
protocol to the same protocol that is used for machine authentication.
Related Topics
Microsoft AD, page 8-41
Managing External Identity Stores, page 8-22
Authentication Protocol and Identity Store Compatibility
ACS supports various authentication protocols to authenticate against the supported identity stores.
Ta b l e B - 4 specifies non-EAP authentication protocol support.
Table B-4 Non-EAP Authentication Protocol and User Database Compatibility
Identity Store ASCII/PAP MSCHAPv1/MSCHAPv2 CHAP
ACS Yes Yes Yes
Windows AD Yes Yes No
LDAP Yes No No
RSA Identity 
StoreYe s N o N o
RADIUS 
Identity StoreYe s N o N o 
						

							B-36
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix B      Authentication in ACS 5.3
  Authentication Protocol and Identity Store Compatibility
Ta b l e B - 5 specifies EAP authentication protocol support.
Table B-5 EAP Authentication Protocol and User Database Compatibility
Identity Store EAP-MD5 EAP-TLS1
1. In EAP-TLS authentication, the user is authenticated by cryptographic validation of the certificate. Additionally, ACS 5.3 
optionally allows a binary comparison of the user’s certificate sent by the end-user client against the certificate located in the 
user’s record in the LDAP identity store.
PEAP 
EAP-MSCHAPv2EAP-FAST 
MSCHAPv2 PEAP-GTC EAP-FAST-GTC
ACS Yes Yes
2
2. ACS Identity Store cannot store the certificates.
Ye s Ye s Ye s Ye s
W i n d o w s  A D N o Ye s Ye s Ye s Ye s Ye s
L D A P N o Ye s N o N o Ye s Ye s
RSA Identity 
StoreNo No No No Yes Yes
RADIUS 
Identity StoreNo No No No Yes Yes 
						

							C-1
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
APPENDIXC
Open Source License Acknowledgments
See http://www.cisco.com/en/US/products/ps9911/products_licensing_information_listing.html for all 
the Open Source and Third Party Licenses used in Cisco Secure Access Control System, 5.3.
Notices
The following notices pertain to this software license.
OpenSSL/Open SSL Project
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit 
(http://www.openssl.org/).
This product includes cryptographic software written by Eric Young ([email protected]).
This product includes software written by Tim Hudson ([email protected]).
License Issues
The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the 
original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses 
are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact 
[email protected].
OpenSSL License:
Copyright © 1998-2007 The OpenSSL Project. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided 
that the following conditions are met:
1.Redistributions of source code must retain the copyright notice, this list of conditions and the 
following disclaimer.
2.Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and 
the following disclaimer in the documentation and/or other materials provided with the distribution.
3.All advertising materials mentioning features or use of this software must display the following 
acknowledgment: “This product includes software developed by the OpenSSL Project for use in the 
OpenSSL Toolkit (http://www.openssl.org/)”. 
						

							C-2
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix C      Open Source License Acknowledgments
  Notices
4.The names “OpenSSL Toolkit” and “OpenSSL Project” must not be used to endorse or promote 
products derived from this software without prior written permission. For written permission, please 
contact [email protected].
5.Products derived from this software may not be called “OpenSSL” nor may “OpenSSL” appear in 
their names without prior written permission of the OpenSSL Project.
6.Redistributions of any form whatsoever must retain the following acknowledgment:
“This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit 
(http://www.openssl.org/)”.
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT “AS IS” AND ANY EXPRESSED OR 
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES 
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN 
NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY 
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.
This product includes cryptographic software written by Eric Young ([email protected]). This product 
includes software written by Tim Hudson ([email protected]).
Original SSLeay License:
Copyright © 1995-1998 Eric Young ([email protected]). All rights reserved.
This package is an SSL implementation written by Eric Young ([email protected]).
The implementation was written so as to conform with Netscapes SSL.
This library is free for commercial and non-commercial use as long as the following conditions are 
adhered to. The following conditions apply to all code found in this distribution, be it the RC4, RSA, 
lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is 
covered by the same copyright terms except that the holder is Tim Hudson ([email protected]).
Copyright remains Eric Young’s, and as such any Copyright notices in the code are not to be removed. 
If this package is used in a product, Eric Young should be given attribution as the author of the parts of 
the library used. This can be in the form of a textual message at program startup or in documentation 
(online or textual) provided with the package.
Redistribution and use in source and binary forms, with or without modification, are permitted provided 
that the following conditions are met:
1.Redistributions of source code must retain the copyright notice, this list of conditions and the 
following disclaimer.
2.Redistributions in binary form must reproduce the above copyright notice, this list of conditions and 
the following disclaimer in the documentation and/or other materials provided with the distribution.
3.All advertising materials mentioning features or use of this software must display the following 
acknowledgement:
“This product includes cryptographic software written by Eric Young ([email protected])”.
The word ‘cryptographic’ can be left out if the routines from the library being used are not 
cryptography-related. 
						

							C-3
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix C      Open Source License Acknowledgments
  
4.If you include any Windows specific code (or a derivative thereof) from the apps directory 
(application code) you must include an acknowledgement: “This product includes software written 
by Tim Hudson ([email protected])”.
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG “AS IS” AND ANY EXPRESS OR IMPLIED 
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 
EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, 
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The license and distribution terms for any publicly available version or derivative of this code cannot be 
changed. i.e. this code cannot simply be copied and put under another distribution license [including the 
GNU Public License]. 
						

							C-4
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Appendix C      Open Source License Acknowledgments