Cisco Acs 57 User Guide

							21   
Common Scenarios Using ACS
ACS and Cisco Security Group Access
Cisco AnyConnect VPN client 2.3 Series
MS VPN client
Related Topics
VPN Remote Network Access, page 19
Supported Authentication Protocols, page 19
Supported Identity Stores, page 20
Supported VPN Network Access Servers, page 20
Configuring VPN Remote Access Service, page 21
Configuring VPN Remote Access Service
To configure a VPN remote access service:
1.Configure the VPN protocols in the Allowed Protocols page of the default network access service. For more 
information, see Configuring Access Service Allowed Protocols, page 16.
2.Create an authorization profile for VPN by selecting the dictionary type, and the Tunneling-Protocols attribute type 
and value. For more information, see Specifying RADIUS Attributes in Authorization Profiles, page 20.
3.Click Submit to create the VPN authorization profile.
Related Topics
VPN Remote Network Access, page 19
Supported Authentication Protocols, page 19
Supported Identity Stores, page 20
Supported VPN Network Access Servers, page 20
Supported VPN Clients, page 20
Configuring VPN Remote Access Service, page 21
ACS and Cisco Security Group Access
Note: ACS requires an additional feature license to enable Security Group Access capabilities.
Cisco Security Group Access, hereafter referred to as Security Group Access, is a new security architecture for Cisco 
products. You can use Security Group Access to create a trustworthy network fabric that provides confidentiality, 
message authentication, integrity, and antireplay protection on network traffic.
Security Group Access requires that all network devices have an established identity, and must be authenticated and 
authorized before they start operating in the network. This precaution prevents the attachment of rogue network devices 
in a secure network. 
Until now, ACS authenticated only users and hosts to grant them access to the network. With Security Group Access, 
ACS also authenticates devices such as routers and switches by using a name and password. Any device with a Network 
Interface Card (NIC) must authenticate itself or stay out of the trusted network.  
						

							22
Common Scenarios Using ACS
 
ACS and Cisco Security Group Access
Security is improved and device management is simplified since devices can be identified by their name rather than IP 
address.
Note: The Cisco Catalyst 6500 running Cisco IOS 12.2(33) SXI and DataCenter 3.0 (Nexus 7000) NX-OS 4.0.3 devices 
support Security Group Access. The Cisco Catalyst 6500 supports Security Group Tags (SGTs); however, it does not 
support Security Group Access Control Lists (SGACLs) in this release.
To configure ACS for Security Group Access:
1.Add users.
This is the general task to add users in ACS and is not specific to Security Group Access. Choose Users and Identity 
Stores > Internal Identity Store > Users and click Create. See Creating Internal Users, page 13, for more 
information.
2.Adding Devices for Security Group Access, page 22.
3.Creating Security Groups, page 23.
4.Creating SGACLs, page 23.
5.Configuring an NDAC Policy, page 23.
6.Configuring EAP-FAST Settings for Security Group Access, page 24.
7.Creating an Access Service for Security Group Access, page 24.
8.Creating an Endpoint Admission Control Policy, page 25.
9.Creating an Egress Policy, page 25.
10.Creating a Default Policy, page 26.
Adding Devices for Security Group Access
The RADIUS protocol requires a shared secret between the AAA client and the server. In ACS, RADIUS requests are 
processed only if they arrive from a known AAA client. You must configure the AAA client in ACS with a shared secret. 
The Security Group Access device should be configured with the same shared secret. In Security Group Access, every 
device must be able to act as a AAA client for new devices that join the secured network. 
All the Security Group Access devices possess a Protected Access Credential (PAC) as part of the EAP Flexible 
Authentication via Secured Tunnel (EAP-FAST) protocol. A PAC is used to identify the AAA client. The RADIUS shared 
secret can be derived from the PAC.
To add a network device: 
1.Choose Network Resources > Network Devices and AAA Client and click Create. SeeNetwork Devices and AAA 
Clients, page 5 for more information. 
2.Choose Fill in the fields in the Network Devices and AAA clients pages: 
To add a device as a seed Security Group Access device, check RADIUS and Security Group Access, or to add a 
device as a Security Group Access client, check Security Group Access only.
If you add the device as a RADIUS client, enter the IP Address and the RADIUS/Shared Secret. 
If you add the device as a Security Group Access device, fill in the fields in the Security Group Access section.
You can check Advanced Settings to display advanced settings for the Security Group Access device configuration 
and modify the default settings. 
						

							23   
Common Scenarios Using ACS
ACS and Cisco Security Group Access
The location or device type can be used as a condition to configure an NDAC policy rule.
3.Click Submit.
Creating Security Groups
Security Group Access uses security groups for tagging packets at ingress to allow filtering later on at Egress. The 
product of the security group is the security group tag, a 4-byte string ID that is sent to the network device. 
The web interface displays the decimal and hexadecimal representation. The SGT is unique. When you edit a security 
group you can modify the name, however, you cannot modify the SGT ID.
The security group names Unknown and Any are reserved. The reserved names are used in the Egress policy matrix. The 
generation ID changes when the Egress policy is modified.
Devices consider only the SGT value; the name and description of a security group are a management convenience and 
are not conveyed to the devices. Therefore, changing the name or description of the security group does not affect the 
generation ID of an SGT. 
To create a security group:
1.Choose Policy Elements > Authorizations and Permissions > Network Access > Security Groups and click 
Create.
2.Fill in the fields as described in the Configuring Security Group Access Control Lists, page 31.
Note: When you edit a security group, the security group tag and the generation ID are visible.
3.Click Submit.
Creating SGACLs 
Security Group Access Control Lists (SGACLs) are similar to standard IP-based ACLs, in that you can specify whether 
to allow or deny communications down to the transport protocol; for example, TCP, User Datagram Protocol (UDP), and 
the ports; FTP; or Secure Shell Protocol (SSH). 
You can create SGACLs that can be applied to communications between security groups. You apply Security Group 
Access policy administration in ACS by configuring these SGACLs to the intersection of source and destination security 
groups through a customizable Egress matrix view, or individual source and destination security group pairs. 
To create an SGACL:
1.Choose Policy Elements > Authorizations and Permissions > Named Permissions Objects > Security Group 
ACLs. then click Create.
2.Fill in the fields as described in the Configuring Security Group Access Control Lists, page 31.
3.Click Submit.
Configuring an NDAC Policy
The Network Device Admission Control (NDAC) policy defines which security group is sent to the device. When you 
configure the NDAC policy, you create rules with previously defined conditions, for example, NDGs.  
						

							24
Common Scenarios Using ACS
 
ACS and Cisco Security Group Access
The NDAC policy is a single service, and it contains a single policy with one or more rules. Since the same policy is used 
for setting responses for authentication, peer authorization, and environment requests, the same SGT is returned for all 
request types when they apply to the same device.
Note: You cannot add the NDAC policy as a service in the service selection policy; however, the NDAC policy is 
automatically applied to Security Group Access devices. 
To configure an NDAC policy for a device:
1.Choose Access Policies > Security Group Access Control > Security Group Access > Network Device Access > 
Authorization Policy. 
2.Click Customize to select which conditions to use in the NDAC policy rules.
The Default Rule provides a default rule when no rules match or there are no rules defined. The default security group 
tag for the Default Rule result is Unknown.
3.Click Create to create a new rule.
4.Fill in the fields in the NDAC Policy Properties page.
5.Click Save Changes.
Configuring EAP-FAST Settings for Security Group Access
Since RADIUS information is retrieved from the PAC, you must define the amount of time for the EAP-FAST tunnel PAC 
to live. You can also refresh the time to live for an active PAC.
To configure the EAP-FAST settings for the tunnel PAC:
1.Choose Access Policies > Security Group Access Control > > Network Device Access. 
2.Fill in the fields in the Network Device Access EAP-FAST Settings page.
3.Click Submit.
Creating an Access Service for Security Group Access
You create an access service for endpoint admission control policies for endpoint devices, and then you add the service 
to the service selection policy. 
Note: The NDAC policy is a service that is automatically applied to Security Group Access devices. You do not need to 
create an access service for Security Group Access devices. 
To create an access service:
1.Choose Access Policies > Access Service, and click Create. See Configuring Access Services, page 10, for more 
information.
2.Fill in the fields in the Access Service Properties—General page as required.
3.In the Service Structure section, choose User selected policy structure.
4.Select Network Access, and check Identity and Authorization.
5.Click Next.
The Access Services Properties page appears. 
						

							25   
Common Scenarios Using ACS
ACS and Cisco Security Group Access
6.In the Authentication Protocols area, check the relevant protocols for your access service. 
7.Click Finish.
Creating an Endpoint Admission Control Policy
After you create a service, you configure the endpoint admission control policy. The endpoint admission control policy 
returns an SGT to the endpoint and an authorization profile. You can create multiple policies and configure the Default 
Rule policy. The defaults are Deny Access and the Unknown
 security group.
To add a session authorization policy for an access service:
1.Choose Access Policies > Access Services > service > Authorization. 
2.Configure an Authorization Policy. See Configuring a Session Authorization Policy for Network Access, page 30.
3.Fill in the fields in the Network Access Authorization Rule Properties page.
The Default Rule provides a default rule when no rules match or there are no rules defined. The default for the Default 
Rule result is Deny Access, which denies access to the network. The security group tag is Unknown.
You can modify the security group when creating the session authorization policy for Security Group Access.
4.Click OK.
5.Choose Access Policies > Service Selection Policy to choose which services to include in the endpoint policy. See 
Configuring the Service Selection Policy, page 5, for more information.
6.Fill in the fields in the Service Select Policy pages.
7.Click Save Changes.
Creating an Egress Policy
The Egress policy (sometimes called SGACL policy) determines which SGACL to apply at the Egress points of the 
network based on the source and destination SGT. The Egress policy is represented in a matrix, where the X and Y axis 
represent the destination and source SGT, respectively, and each cell contains the set of SGACLs to apply at the 
intersection of these two SGTs. 
Any security group can take the role of a source SGT, if an endpoint (or Security Group Access device) that carries this 
SGT sends the packet. Any security group can take the role of a destination SGT, if the packet is targeting an endpoint 
(or Security Group Access device) that carries this SGT. Therefore, the Egress matrix lists all of the existing security 
groups on both axes, making it a Cartesian product of the SGT set with itself (SGT x SGT).
The first row (topmost) of the matrix contains the column headers, which display the destination SGT. The first column 
(far left) contains the row titles, with the source SG displayed. At the intersection of these axes lies the origin cell (top 
left) that contains the titles of the axes, namely, Destination and Source. 
All other cells are internal matrix cells that contain the defined SGACL. The rows and columns are ordered alphabetically 
according to the SGT names. Each SGACL can contain 200 ACEs.
Initially, the matrix contains the cell for the unknown source and unknown destination SG. Unknown refers to the 
preconfigured SG, which is not modifiable. When you add an SG, ACS adds a new row and new column to the matrix 
with empty content for the newly added cell. 
						

							26
Common Scenarios Using ACS
 
RADIUS and TACACS+ Proxy Requests
To add an Egress policy and populate the Egress matrix:
1.Choose Access Policies > Security Group Access Control > Egress Policy.
The Egress matrix is visible. The security groups appear in the order in which you defined them.
2.Click on a cell and then click Edit.
3.Fill in the fields as required.
4.Select the set of SGACLs to apply to the cell and move the selected set to the Selected column.
The ACLS are used at the Egress point of the SGT of the source and destination that match the coordinates of the 
cell. The SGACLs are applied in the order in which they appear.
5.Use the Up and Down arrows to change the order. The device applies the policies in the order in which they are 
configured. The SGACL are applied to packets for the selected security groups.
6.Click Submit.
Creating a Default Policy
After you configure the Egress policies for the source and destination SG in the Egress matrix, Cisco recommends that 
you configure the Default Egress Policy. The default policy refers to devices that have not been assigned an SGT. The 
default policy is added by the network devices to the specific policies defined in the cells. The initial setting for the default 
policy is Permit All. 
The term default policy refers to the ANY security group to ANY security group policy. Security Group Access network 
devices concatenate the default policy to the end of the specific cell policy. 
If the cell is blank, only the default policy is applied. If the cell contains a policy, the resultant policy is the combination 
of the cell-specific policy which precedes the default policy. 
The way the specific cell policy and the default policy are combined depends on the algorithm running on the device. 
The result is the same as concatenating the two policies.
The packet is analyzed first to see if it matches the ACEs defined by the SGACLs of the cell. If there is no match, the 
packet falls through to be matched by the ACEs of the default policy. 
Combining the cell-specific policy and the default policy is done not by ACS, but by the Security Group Access network 
device. From the ACS perspective, the cell-specific and the default policy are two separate sets of SGACLs, which are 
sent to devices in response to two separate policy queries.
To create a default policy:
1.Choose Access Policies > Security Group Access Control > Egress Policy then choose Default Policy.
2.Fill in the fields as in the Default Policy for Egress Policy page.
3.Click Submit.
RADIUS and TACACS+ Proxy Requests
You can use ACS to act as a proxy server having NAS/AAA client in its database, that receives authentication RADIUS 
requests and authentication and authorization TACACS+ requests from a network access server (NAS) and forwards 
them to a remote server. ACS then receives the replies for each forwarded request from the remote RADIUS or TACACS+ 
server and sends them back to the client. 
						

							27   
Common Scenarios Using ACS
RADIUS and TACACS+ Proxy Requests
ACS uses the service selection policy to differentiate between incoming authentication and accounting requests that 
must be handled locally and those that must be forwarded to a remote RADIUS or TACACS+ server.
When ACS receives a proxy request from the NAS, it forwards the request to the first remote RADIUS or TACACS+ server 
in its list. ACS processes the first valid or invalid response from the remote RADIUS server and does the following:
If the response is valid for RADIUS, such as Access-Challenge, Access-Accept, or Access-Reject, ACS returns the 
response back to the NAS.
If ACS does not receive a response within the specified time period, then after the specified number of retries, or 
after a specified network timeout, it forwards the request to the next remote RADIUS server in the list.
If the response is invalid, ACS proxy performs failover to the next remote RADIUS server. When the last failover 
remote RADIUS server in the list is reached without getting reply, ACS drops the request and does not send any 
response to the NAS.
ACS processes the first valid or invalid response from the remote TACACS+ server and does the following:
If the response is valid for TACACS+, such as TAC_PLUS_AUTHEN (REPLY) or TAC_PLUS_AUTHOR(RESPONSE), 
ACS returns the response back to the NAS.
If ACS does not receive a response within the specified time period, after the specified number of retries, or after 
specified network timeout it forwards the request to the next remote TACACS+ server in the list.
If the response is invalid, ACS proxy performs failover to the next remote TACACS+ server. When the last failover 
remote TACACS+ server in the list is reached without getting reply, ACS drops the request and does not send any 
response to the NAS.
You can configure ACS to strip the prefix, suffix, and both from a username (RADIUS) or user (TACACS+). For example, 
from a username acme\[email protected], you can configure ACS to extract only the name of the user, smith by 
specifying  and @ as the prefix and suffix separators respectively.
ACS can perform local accounting, remote accounting, or both. If you choose both, ACS performs local accounting and 
then moves on to remote accounting. If there are any errors in local accounting, ACS ignores them and moves on to 
remote accounting.
During proxying, ACS:
1.Receives the following packets from the NAS and forwards them to the remote RADIUS server:
Access-Request
2.Receives the following packets from the remote RADIUS server and returns them to the NAS:
Access-Accept
Access-Reject
Access-Challenge
3.Receives the following packets from the NAS and forwards them to the remote TACACS+ server:
TAC_PLUS_AUTHOR
TAC_PLUS_AUTHEN
4.Receives the following packets from the remote TACACS+ server and returns them back to the NAS: This behavior 
is configurable.
TAC_PLUS_ACCT 
						

							28
Common Scenarios Using ACS
 
RADIUS and TACACS+ Proxy Requests
An unresponsive external RADIUS server waits for about timeout * number of retries seconds before failover to move to 
the next server. 
There could be several unresponsive servers in the list before the first responsive server is reached. In such cases, each 
request that is forwarded to a responsive external RADIUS server is delayed for number of previous unresponsive servers 
* timeout * number of retries.
This delay can sometimes be longer than the external RADIUS server timeout between two messages in EAP or RADIUS 
conversation. In such a situation, the external RADIUS server would drop the request.
You can configure the number of seconds for an unresponsive external TACACS+ server waits before failover to move to 
the next server.
ACS 5.7 supports multiple network interface connectors for RADIUS (IPv4) and TACACS+ (IPv4 and IPv6) proxies. ACS 
5.7 with Virtual machine, SNS-3495, SNS-3415, or CSACS-1121 platform contains up to four network interfaces: 
Ethernet 0, Ethernet 1, Ethernet 2, and Ethernet 3. For more information, see Multiple Network Interface Connector in the 
Connecting the Network Interface section of Installation and Upgrade Guide for Cisco Secure Access Control System 5.7.
RADIUS Attribute Rewrite Operation
ACS 5.7 supports the RADIUS attribute rewrite operation when ACS is used as a RADIUS proxy server. This feature allows 
you to manipulate attributes in the RADIUS access requests and responses.
This feature allows you to add, overwrite, and delete the RADIUS inbound attributes on access requests, which will 
be redirected from ACS to external servers. 
This feature allows you to add, overwrite, and delete RADIUS outbound attributes on access-accept responses, 
which will be returned to the client from ACS. The RADIUS attributes update operation on the responses is enabled 
only for access-accept responses and not for access-reject or challenge responses. 
The attribute rewrite operation is configured as part of the Proxy Access Service. This feature is enabled only for RADIUS 
access requests and not for the accounting requests. 
Note: ACS 5.7 does not allow you to conditionally rewrite RADIUS attribute values.
Example for attribute operation statement:
Operator-name ADD new value: “University A”
Rewriting RADIUS InBound Requests
You can update the incoming RADIUS requests and rewrite them before sending them to the external server. You can 
rewrite the attribute values for a specific proxy access service. When this service is selected, ACS performs the operation 
on the access request and forwards the updated access request to the external server.
The following operations are available in the RADIUS inbound attributes rewrite operation:
Adding Attributes to Inbound RADIUS Requests, page 28
Updating Attributes in Inbound RADIUS Requests, page 29
Deleting Attributes from Inbound RADIUS Requests, page 30
Adding Attributes to Inbound RADIUS Requests
This option is used to add a new attribute value for the selected RADIUS attribute.
If multiple attributes are not allowed, the add operation adds the new value for the selected attribute only if this 
attribute does not exist in the request.
Example: 
						

							29   
Common Scenarios Using ACS
RADIUS and TACACS+ Proxy Requests
Called-Station-Id – Attribute Multiple NOT allowed:
On the access request:
Called-Station-Id NOT on the request
Attribute operation statement: 
Called-Station-Id ADD 1223
Result of the add attribute operation on the request forwarded to the server:
Called-Station-Id =1223
If the Called-Station-Id is on the original request, ACS does not perform the add operation in this example.
If multiple attributes are allowed, the add operation always adds the attribute with a new value.
Example:
Login-IP-Host – attribute Multiple allowed:
On the access request:
Login-IP-Host=10.56.21.190
Attribute operation statement:
Login-IP-Host ADD 10.56.1.1
Result of the attribute operation on the request forwarded to the server:
Login-IP-Host=10.56.21.190
Login-IP-Host=10.56.1.1
Updating Attributes in Inbound RADIUS Requests
This option is used to update the existing value of a selected RADIUS attribute.
If multiple attributes are not allowed, the update operation updates the existing attribute with the new value only if 
the attribute exists on the request.
If multiple attributes are allowed, the update operation removes all the occurrences of this attribute and adds one 
attribute with the new value.
Example:
Login-IP-Host – attribute Multiple allowed:
On the access request:
Login-IP-Host=10.56.21.190
Login-IP-Host=10.56.1.1
Attribute operation statement:
Login-IP-Host UPDATE 10.12.12.12
Result of the attribute operation on the request forwarded to the server: 
						

							30
Common Scenarios Using ACS
 
RADIUS and TACACS+ Proxy Requests
Login-IP-Host=10.12.12.12
If the attribute is a cisco-avpair (pair of key=value), the update is done according to the key.
Example:
On the access request:
cisco-avpair = url-redirect=www.cisco.com
cisco-avpair = url-redirect=www.yahoo.com
cisco-avpair = cmd=show
Attribute operation statement:
cisco-avpair UPDATE new value:[url-redirect=www.google.com]
Result of the attribute operation on the request forwarded to the server:
cisco-avpair = url-redirect=www.google.com
cisco-avpair = cmd=show
Deleting Attributes from Inbound RADIUS Requests
This option is used to delete the value of RADIUS inbound attributes.
Example:
Login-IP-Host – attribute Multiple allowed
On the access request:
Login-IP-Host=10.56.21.190
Attribute operation statement:
Login-IP-Host DELETE
Result of the attribute operation on the request forwarded to the server:
Attribute Login-IP-Host is not on the request.
Rewriting RADIUS Outbound Responses
You can update the outgoing RADIUS responses and rewrite them before they are sent to the client devices. You can 
rewrite the attribute values for a specific proxy access service. When this service is selected, ACS performs the operation 
on the access accept response and forwards it to the client devices.
The following operations are available in the RADIUS outbound attributes rewrite operation:
Adding Attributes to Outbound RADIUS Responses, page 30
Updating Attributes in Outbound RADIUS Responses, page 31
Deleting Attributes from OutBound RADIUS Responses, page 32
Adding Attributes to Outbound RADIUS Responses
This option is used to add a new attribute value for the selected RADIUS attribute.
If multiple attributes are not allowed, the add operation adds the new value for the selected attribute only if this 
attribute does not exist in the access accept response.