Cisco Acs 5x User Guide

							4-7
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Password-Based Network Access
Password-Based Network Access Configuration Flow
This topic describes the end-to-end flow for password-based network access and lists the tasks that you 
must perform. The information about how to configure the tasks is located in the relevant task chapters. 
To configure password-based network access:
Step 1Configure network devices and AAA clients. 
a.In the Network Devices and AAA Clients, page 7-5, configure the Authentication Setting as 
RADIUS.
b.Enter the Shared Secret.
See Network Devices and AAA Clients, page 7-5, for more information. 
Step 2Configure the users and identity stores. For more information, see Chapter 8, “Managing Users and 
Identity Stores.”
Step 3Define policy conditions and authorization profiles. For more information, see Chapter 9, “Managing 
Policy Elements.”
Step 4Define an access service. For more information, see Creating, Duplicating, and Editing Access Services, 
page 10-12. 
a.Set the Access Service Type to Network Access.
b.Select one of the ACS-supported protocols in the Allowed Protocols Page and follow the steps in 
the Action column in Ta b l e 4 - 1.
Step 5Add the access service to your service selection policy. For more information, see Creating, Duplicating, 
and Editing Service Selection Rules, page 10-8.
Step 6Return to the service that you created and in the Authorization Policy Page, define authorization rules. 
For more information, see Configuring Access Service Policies, page 10-21.
Table 4-1 Network Access Authentication Protocols
Protocol Action
Process Host Lookup 
(MAB)In the Allowed Protocols Page, choose Process Host Lookup.
RADIUS PAP In the Allowed Protocols Page, choose Allow PAP/ASCII.
RADIUS CHAP In the Allowed Protocols Page, choose Allow CHAP.
RADIUS MSCHAPv1 In the Allowed Protocols Page, choose Allow MS-CHAPv1.
RADIUS MSCHAPv2 In the Allowed Protocols Page, choose Allow MS-CHAPv2.
EAP-MD5 In the Allowed Protocols Page, choose Allow EAP-MD5.
LEAP In the Allowed Protocols Page, choose Allow LEAP. 
						

							4-8
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Password-Based Network Access
For RADIUS, non-EAP authentication methods (RADIUS/PAP, RADIUS/CHAP, 
RADIUS/MS-CHAPv1, RADIUS/MSCHAPv2), and simple EAP methods (EAP-MD5 and LEAP), you 
need to configure only the protocol in the Allowed Protocols page as defined in Ta b l e 4 - 1.
Some of the complex EAP protocols require additional configuration:
For EAP-TLS, you must also configure:
–The EAP-TLS settings under System Administration > Configuration > EAP-TLS Settings.
–A local server certificate under System Administration > Configuration > Local Server 
Certificates > Local Certificates.
–A CA certificate under Users and Identity Stores > Certificate Authorities.
For PEAP, you must also configure:
–The inner method in the Allowed Protocols page and specify whether password change is 
allowed.
–The PEAP settings under System Administration > Configuration > PEAP Settings.
–Local server certificates under System Administration > Configuration > Local Server 
Certificates > Local Certificates.
For EAP-FAST, you must also configure:
–The inner method in the Allowed Protocols page and specify whether password change is 
allowed.
–Whether or not to use PACs and if you choose to use PACs, you must also specify how to allow 
in-band PAC provisioning.
–The EAP-FAST settings under System Administration > Configuration > EAP-FAST > 
Settings.
–A local server certificate under System Administration > Configuration > Local Server 
Certificates > Local Certificates (Only if you enable authenticated PAC provisioning). PEAP In the Allowed Protocols Page, choose PEAP. For the PEAP inner method, choose 
EAP-MSCHAPv2 or EAP-GTC or both.
EAP-FAST
1.In the Allowed Protocols Page, choose Allow EAP-FAST to enable the EAP-FAST settings.
2.For the EAP-FAST inner method, choose EAP-MSCHAPv2 or EAP-GTC or both.
3.Select Allow Anonymous In-Band PAC Provisioning or Allow Authenticated In-Band PAC 
Provisioning or both.
For Windows machine authentication against Microsoft AD and for the change password feature:
1.Click the Use PACS radio button. For details about PACs, see About PACs, page B-21.
2.Check Allow Authenticated In-Band PAC Provisioning.
3.Check Allow Machine Authentication. 
4.Enter the Machine PAC Time to Live.
Table 4-1 Network Access Authentication Protocols
Protocol Action 
						

							4-9
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Certificate-Based Network Access
Related Topics
Authentication in ACS 5.3, page B-1
Network Devices and AAA Clients, page 7-5
Managing Access Policies, page 10-1
Creating, Duplicating, and Editing Access Services, page 10-12
About PACs, page B-21
Certificate-Based Network Access
This section contains the following topics:
Overview of Certificate-Based Network Access, page 4-9
Using Certificates in ACS, page 4-10
Certificate-Based Network Access for EAP-TLS, page 4-10
For more information about certificate-based protocols, see Appendix B, “Authentication in ACS 5.3.”
Overview of Certificate-Based Network Access
Before using EAP-TLS, you must install a computer certificate on ACS. The installed computer 
certificate must be issued from a CA that can follow a certificate chain to a root CA that the access client 
trusts. 
Additionally, in order for ACS to validate the user or computer certificate of the access client, you must 
install the certificate of the root CA that issued the user or computer certificate to the access clients.
ACS supports certificate-based network access through the EAP-TLS protocol, which uses certificates 
for server authentication by the client and for client authentication by the server. 
Other protocols, such as PEAP or the authenticated-provisioning mode of EAP-FAST also make use of 
certificates for server authentication by the client, but they cannot be considered certificate-based 
network access because the server does not use the certificates for client authentication.
ACS Public Key Infrastructure (PKI) certificate-based authentication is based on X509 certificate 
identification. The entity which identifies itself with a certificate holds a private-key that correlates to 
the public key stored in the certificate. 
A certificate can be self-signed or signed by another CA. A hierarchy of certificates can be made to form 
trust relations of each entity to its CA. The trusted root CA is the entity that signs the certificate of all 
other CAs and eventually signs each certificate in its hierarchy.
ACS identifies itself with its own certificate. ACS supports a certificate trust list (CTL) for authorizing 
connection certificates. ACS also supports complex hierarchies that authorize an identity certificate 
when all of the chain certificates are presented to it. 
ACS supports several RSA key sizes used in the certificate that are 512, 1024, 2048, or 4096 bits. Other 
key sizes may be used. ACS 5.3 supports RSA. ACS does not support the Digital Signature Algorithm 
(DSA). However, in some use cases, ACS will not prevent DSA cipher suites from being used for 
certificate-based authentication.
All certificates that are used for network access authentication must meet the requirements for X.509 
certificates and work for connections that use SSL/TLS. After this minimum requirement is met, the 
client and server certificates have additional requirements. 
						

							4-10
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Certificate-Based Network Access
You can configure two types of certificates in ACS:
Trust certificate—Also known as CA certificate. Used to form CTL trust hierarchy for verification 
of remote certificates.
Local certificate—Also known as local server certificate. The client uses the local certificate with 
various protocols to authenticate the ACS server. This certificate is maintained in association with 
its private key, which is used to prove possession of the certificate.
NoteDuring certificate-based access (or password-based access), the user is not only authenticated but also 
authorized according to the ACS configuration. And if NAS sends accounting requests, the user is also 
accounted.
Related Topics
Configuring CA Certificates, page 8-68
Configuring Local Server Certificates, page 18-14
Using Certificates in ACS, page 4-10
Using Certificates in ACS
The three use cases for certificates in ACS 5.3 are:
Certificate-Based Network Access for EAP-TLS, page 4-10
Authorizing the ACS Web Interface from Your Browser Using a Certificate, page 4-11
Validating an LDAP Secure Authentication Connection, page 4-12
Certificate-Based Network Access for EAP-TLS
For TLS- related EAP protocols, you must set up a server certificate from the local certificate store and 
a trust list certificate to authenticate the client. You can choose the trust certificate from any of the 
certificates in the local certificate store.
To use EAP-TLS, you must obtain and install trust certificates. The information about how to perform 
the tasks is located in the relevant task chapters.
Before you Begin:
Set up the server by configuring:
EAP-TLS.
The local certificate. See Configuring Local Server Certificates, page 18-14.
To configure certificate-based network access for EAP-TLS:
Step 1Configure the trust certificate list. See Configuring CA Certificates, page 8-68, for more information.
Step 2Configure the LDAP external identity store. You might want to do this to verify the certificate against a 
certificate stored in LDAP. See Creating External LDAP Identity Stores, page 8-26, for details.
Step 3Set up the Certificate Authentication Profile. See Configuring Certificate Authentication Profiles, 
page 8-72, for details. 
						

							4-11
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Certificate-Based Network Access
Step 4Configure policy elements. See Managing Policy Conditions, page 9-1, for more information.
You can create custom conditions to use the certificate’s attributes as a policy condition. See Creating, 
Duplicating, and Editing a Custom Session Condition, page 9-5, for details.
Step 5Create an access service. See Configuring Access Services, page 10-11, for more information.
Step 6In the Allowed Protocols Page, choose EAP-TLS.
Step 7Configure identity and authorization policies for the access service. See Configuring Access Service 
Policies, page 10-21, for details.
NoteWhen you create rules for the identity policy, the result may be the Certificate Authentication 
Profile or an Identity Sequence. See Viewing Identity Policies, page 10-21, for more 
information.
Step 8Configure the Authorization Policies. See Configuring a Session Authorization Policy for Network 
Access, page 10-29.
Step 9Configure the Service Selection Policy. See Configuring the Service Selection Policy, page 10-5.
Related Topics
Configuring Local Server Certificates, page 18-14
Configuring CA Certificates, page 8-68
Authentication in ACS 5.3, page B-1
Overview of EAP-TLS, page B-6
Authorizing the ACS Web Interface from Your Browser Using a Certificate
You use the HTTPS certificate-based authentication to connect to ACS with your browser. The Local 
Server Certificate in ACS is used to authorize the ACS web interface from your browser. ACS does not 
support browser authentication (mutual authentication is not supported).
A default Local Server Certificate is installed on ACS so that you can connect to ACS with your browser. 
The default certificate is a self-signed certificate and cannot be modified during installation.
Related Topics
Using Certificates in ACS, page 4-10
Configuring Local Server Certificates, page 18-14 
						

							4-12
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Agentless Network Access
Validating an LDAP Secure Authentication Connection 
You can define a secure authentication connection for the LDAP external identity store, by using a CA 
certificate to validate the connection.
To validate an LDAP secure authentication connection using a certificate:
Step 1Configure an LDAP external identity store. See Creating External LDAP Identity Stores, page 8-26.
Step 2In the LDAP Server Connection page, check Use Secure Authentication.
Step 3Select Root CA from the drop-down menu and continue with the LDAP configuration for ACS.
Related Topics
Using Certificates in ACS, page 4-10
Configuring Local Server Certificates, page 18-14
Managing External Identity Stores, page 8-22
Agentless Network Access
This section contains the following topics:
Overview of Agentless Network Access, page 4-12
Host Lookup, page 4-13
Agentless Network Access Flow, page 4-16
For more information about protocols used for network access, see Authentication in ACS 5.3, page B-1.
Overview of Agentless Network Access
Agentless network access refers to the mechanisms used to perform port-based authentication and 
authorization in cases where the host device does not have the appropriate agent software. 
For example, a host device, where there is no 802.1x supplicant or a host device, where the supplicant 
is disabled.
802.1x must be enabled on the host device and on the switch to which the device connects. If a 
host/device without an 802.1x supplicant attempts to connect to a port that is enabled for 802.1x, it will 
be subjected to the default security policy. 
The default security policy says that 802.1x authentication must succeed before access to the network is 
granted. Therefore, by default, non-802.1x-capable devices cannot get access to an 802.1x-protected 
network.
Although many devices increasingly support 802.1x, there will always be devices that require network 
connectivity, but do not, or cannot, support 802.1x. Examples of such devices include network printers, 
badge readers, and legacy servers. You must make some provision for these devices. 
						

							4-13
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Agentless Network Access
Cisco provides two features to accommodate non-802.1x devices. For example, MAC Authentication 
Bypass (Host Lookup) and the Guest VLAN access by using web authentication. 
ACS 5.3 supports the Host Lookup fallback mechanism when there is no 802.1x supplicant. After 802.1x 
times out on a port, the port can move to an open state if Host Lookup is configured and succeeds.
Related Topics
Host Lookup, page 4-13
Agentless Network Access Flow, page 4-16
Host Lookup
ACS uses Host Lookup as the validation method when an identity cannot be authenticated according to 
credentials (for example, password or certificate), and ACS needs to validate the identity by doing a 
lookup in the identity stores.
An example for using host lookup is when a network device is configured to request MAC 
Authentication Bypass (MAB). This can happen after 802.1x times out on a port or if the port is 
explicitly configured to perform authentication bypass. When MAB is implemented, the host connects 
to the network access device. 
The device detects the absence of the appropriate software agent on the host and determines that it must 
identify the host according to its MAC address. The device sends a RADIUS request with 
service-type=10 and the MAC address of the host to ACS in the calling-station-id attribute. 
Some devices might be configured to implement the MAB request by sending PAP or EAP-MD5 
authentication with the MAC address of the host in the user name, user password, and CallingStationID 
attributes, but without the service-type=10 attribute. 
While most use cases for host lookup are to obtain a MAC address, there are other scenarios where a 
device requests to validate a different parameter, and the calling-station-id attribute contains this value 
instead of the MAC address. For example, IP address in layer 3 use cases).
Ta b l e 4 - 2 describes the RADIUS parameters required for host lookup use cases.
ACS supports host lookup for the following identity stores:
Internal hosts
External LDAP
Table 4-2 RADIUS Attributes for Host Lookup Use Cases
 AttributeUse Cases
PAP 802.1x EAP-MD5
RADIUS::ServiceType — Call check (with PAP or 
EAP-MD5) —
RADIUS::UserNameMAC address Any value (usually the 
MAC address)MAC address
RADIUS::UserPasswordMAC address Any value (usually the 
MAC address)MAC address
RADIUS::CallingStationIDMAC address MAC address MAC address 
						

							4-14
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Agentless Network Access
Internal users 
Active Directory
You can access the Active Directory via the LDAP API. 
You can use the Internal Users identity store for Host Lookup in cases where the relevant host is already 
listed in the Internal Users identity store, and you prefer not to move the data to the Internal Hosts 
identity store. 
ACS uses the MAC format (XX-XX-XX-XX-XX-XX) and no other conversions are possible. To search 
the Internal Users identity store using the User-Name attribute (for example, xx:xx:xx:xx:xx:xx) you 
should leave the Process Host Lookup option unchecked. ACS will handle the request as a PAP request.
When MAC address authentication over PAP or EAP-MD5 is not detected according to the Host Lookup 
configuration, authentication and authorization occur like regular user authentication over PAP or 
EAP-MD5. You can use any identity store that supports these authentication protocols. ACS uses the 
MAC address format as presented in the RADIUS User-Name attribute.
Related Topics
Creating an Access Service for Host Lookup, page 4-18
Viewing and Performing Bulk Operations for Internal Identity Store Hosts, page 8-18
Managing Users and Identity Stores, page 8-1
Authentication with Call Check, page 4-14
Authentication with Call Check
When ACS identifies a network access request with the call check attribute as Host Lookup 
(RADIUS::ServiceType = 10), ACS authenticates (validates) and authorizes the host by looking up the 
value in the Calling-Station-ID attribute (for example, the MAC address) in the configured identity store 
according to the authentication policy. 
When ACS receives a RADIUS message, it performs basic parsing and validation, and then checks if the 
Call Check attribute, RADIUS ServiceType(6), is equal to the value 10. If the RADIUS ServiceType is 
equal to 10, ACS sets the system dictionary attribute UseCase to a value of Host Lookup.
In the ACS packet processing flow, the detection of Host Lookup according to Call Check service-type 
is done before the service selection policy. It is possible to use the condition UseCase equals Host 
Lookup in the service selection policy. 
Initially, when RADIUS requests are processed, the RADIUS User-Name attribute is copied to the 
System UserName attribute. When the RADIUS Service-Type equals 10, the RADIUS 
Calling-Station-ID attribute is copied to the System User-Name attribute, and it overrides the RADIUS 
User-Name attribute value.
ACS supports four MAC address formats:
Six groups of two hexadecimal digits, separated by hyphens—01-23-45-67-89-AB
Six groups of two hexadecimal digits, separated by colons—01:23:45:67:89:AB
Three groups of four hexadecimal digits, separated by dots—0123.4567.89AB
Twelve consecutive hexadecimal digits without any separators—0123456789AB
If the Calling-Station-ID attribute is one of the four supported MAC address formats above, ACS copies 
it to the User-Name attribute with the format of XX-XX-XX-XX-XX-XX. If the MAC address is in a 
format other than one of the four above, ACS copies the string as is. 
						

							4-15
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Agentless Network Access
Process Service-Type Call Check
You may not want to copy the CallingStationID attribute value to the System UserName attribute value. 
When the Process Host Lookup option is checked, ACS uses the System UserName attribute that was 
copied from the RADIUS User-Name attribute. 
When the Process Host Lookup option is not checked, ACS ignores the HostLookup field and uses the 
original value of the System UserName attribute for authentication and authorization. The request 
processing continues according to the message protocol. For example, according to the RADIUS 
User-Name and User-Password attributes for PAP.
For setting the Process Host Lookup option, see Creating an Access Service for Host Lookup, page 4-18.
PAP/EAP-MD5 Authentication
When a device is configured to use PAP or EAP-MD5 for MAC address authentication, you can 
configure ACS to detect the request as a Host Lookup request, within the network access service. The 
device sends the request with the hosts MAC address in the User-Name, User-Password, and 
Calling-Station-ID attributes.
If you do not configure ACS to detect Host Lookup, the access request is handled as a regular PAP, or 
EAP-MD5 authentication request.
If you check the Process HostLookup field and select PAP or EAP-MD5, ACS places the HostLookup 
value in the ACS::UseCase attribute. The User-Password attribute is ignored for the detection algorithm. 
ACS follows the authentication process as if the request is using the call check attribute, and processes 
it as a Host Lookup (Service-Type=10) request. The RADIUS dictionary attribute ACS::UseCase is set 
to the value of HostLookup.
The Detect Host Lookup option for PAP and EAP-MD5 MAC authentication is done after the service 
selection policy. If a service selection rule is configured to match ACS::UseCase = Host Lookup, the 
request falls into the Host Lookup category.
If ACS is not configured to detect PAP or EAP-MD5 authentications as MAC authentication flows, ACS 
will not consider the Detect Host Lookup option. These requests are handled like a regular user request 
for authentication, and looks for the username and password in the selected identity store. 
Related Topics
Creating an Access Service for Host Lookup, page 4-18
Managing Access Policies, page 10-1
Viewing and Performing Bulk Operations for Internal Identity Store Hosts, page 8-18
Managing Users and Identity Stores, page 8-1 
						

							4-16
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Agentless Network Access
Agentless Network Access Flow
This topic describes the end-to-end flow for agentless network access and lists the tasks that you must 
perform. The information about how to configure the tasks is located in the relevant task chapters. 
Perform these tasks in the order listed to configure agentless network access in ACS:
Step 1Configure network devices and AAA clients. 
This is the general task to configure network devices and AAA clients in ACS and is not specific to 
agentless network access. Select Network Resources > Network Devices and AAA Clients and click 
Create. See Network Devices and AAA Clients, page 7-5. 
Step 2Configure an identity store for internal hosts.
Configure an internal identity store. See Adding a Host to an Internal Identity Store, page 4-17
or
Configure an external identity store. See Configuring an LDAP External Identity Store for Host 
Lookup, page 4-17. 
For more information, see Chapter 8, “Managing Users and Identity Stores.”
Step 3Configure the identity group. See Configuring an Identity Group for Host Lookup Network Access 
Requests, page 4-18.
For more information, see Chapter 8, “Managing Users and Identity Stores.”
Step 4Define policy elements and authorization profiles for Host Lookup requests.
For more information, see Chapter 9, “Managing Policy Elements.”
Step 5Create an empty service by defining an access service for Host Lookup. For more information, see 
Creating an Access Service for Host Lookup, page 4-18. 
Step 6Return to the service that you created:
a.Define an identity policy. For more information, see Configuring an Identity Policy for Host Lookup 
Requests, page 4-19.
ACS has the option to look for host MAC addresses in multiple identity stores. 
For example, MAC addresses can be in the Internal Hosts identity store, in one of the configured 
LDAP identity stores, or in the Internal Users identity store. 
The MAC address lookup may be in one of the configured identity stores, and the MAC attributes 
may be fetched from a different identity store that you configured in the identity sequence.
You can configure ACS to continue processing a Host Lookup request even if the MAC address was 
not found in the identity store. An administrator can define an authorization policy based on the 
event, regardless of whether or not the MAC address was found.
The ACS::UseCase attribute is available for selection in the Authentication Policy, but is not 
mandatory for Host Lookup support.
b.Return to the service that you created.
c.Define an authorization policy. For more information, see Configuring an Authorization Policy for 
Host Lookup Requests, page 4-20.