Cisco Acs 5x User Guide
Have a look at the manual Cisco Acs 5x User Guide online for free. It’s possible to download the document as PDF or print. UserManuals.tech offer 53 Cisco manuals and user’s guides for free. Share the user manual or guide on Facebook, Twitter or Google+.
3-9 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Chapter 3 ACS 5.x Policy Model Access Services ACS can simultaneously act as a proxy server to multiple external RADIUS and TACACS+ servers. For ACS to act as a proxy server, you must configure a RADIUS or TACACS+ proxy service in ACS. See Configuring General Access Service Properties, page 10-13 for information on how to configure a RADIUS proxy service. For more information on proxying RADIUS and TACACS+ requests, see RADIUS and TACACS+ Proxy Requests, page 4-29. Related Topics Policy Terminology, page 3-3 Types of Policies, page 3-5 Flows for Configuring Services and Policies, page 3-19 Identity Policy Two primary mechanisms define the mechanism and source used to authenticate requests: Password-based—Authentication is performed against databases after the user enters a username and password. Hosts can bypass this authentication by specifying a MAC address. However, for identity policy authentication, host lookup is also considered to be password-based. Certificate-based—A client presents a certificate for authentication of the session. In ACS 5.3, certificate-based authentication occurs when the PEAP-TLS or EAP-TLS protocol is selected. In addition, databases can be used to retrieve attributes for the principal in the request. The identity source is one result of the identity policy and can be one of the following types: Deny Access—Access to the user is denied and no authentication is performed. Identity Database—Single identity database. When a single identity database is selected as the result of the identity policy, either an external database (LDAP or AD) or an internal database (users or hosts) is selected as the result. The database selected is used to authenticate the user/host and to retrieve any defined attributes stored for the user/host in the database. Certificate Authentication Profile—Contains information about the structure and content of the certificate, and specifically maps certificate attribute to internal username. For certificate-based authentication, you must select a certificate authentication profile. For certificate based requests, the entity which identifies itself with a certificate holds the private key that correlates to the public key stored in the certificate. The certificate authentication profile extends the basic PKI processing by defining the following: –The certificate attribute used to define the username. You can select a subset of the certificate attributes to populate the username field for the context of the request. The username is then used to identify the user for the remainder of the request, including the identification used in the logs. –The LDAP or AD database to use to verify the revocation status of the certificate. When you select an LDAP or AD database, the certificate data is retrieved from the LDAP or AD database and compared against the data entered by the client in order to provide additional verification of the client certificate.
3-10 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Chapter 3 ACS 5.x Policy Model Access Services Identity Sequence—Sequences of the identity databases. The sequence is used for authentication and, if specified, an additional sequence is used to retrieve only attributes. You can select multiple identity methods as the result of the identity policy. You define the identity methods in an identity sequence object, and the methods included within the sequence may be of any type. There are two components to an identity sequence: one for authentication, and one for attribute retrieval. The administrator can select to perform authentication based on a certificate or an identity database or both. –If you choose to perform authentication based on a certificate, ACS selects a single certificate authentication profile. –If you choose to perform authentication based on an identity database, you must define a list of databases to be accessed in sequence until authentication succeeds. When authentication succeeds, any defined attributes within the database are retrieved. In addition, you can define an optional list of databases from which additional attributes are retrieved. These additional databases can be accessed irrespective of whether password- or certificate-based authentication was used. When certificate-based authentication is used, the username field is populated from a certificate attribute and is used to retrieve attributes. All databases defined in the list are accessed and, in cases where a matching record for the user is found, the corresponding attributes, are retrieved. Attributes can be retrieved for a user even if the user’s password is marked that it needs to be changed or if the user account is disabled. Even when you disable a user’s account, the user’s attributes are still available as a source of attributes, but not for authentication. Failure Options If a failure occurs while processing the identity policy, the failure can be one of three main types: Authentication failed—ACS received an explicit response that the authentication failed. For example, the wrong username or password was entered, or the user was disabled. User/host not found—No such user/host was found in any of the authentication databases. Process failed—There was a failure while accessing the defined databases. All failures returned from an identity database are placed into one of the types above. For each type of failure, you can configure the following options: Reject—ACS sends a reject reply. Drop—No reply is returned. Continue—ACS continues processing to the next defined policy in the service. The Authentication Status system attribute retains the result of the identity policy processing. If you select to continue policy processing in the case of a failure, this attribute can be referred to as a condition in subsequent policy processing to distinguish cases in which identity policy processing did not succeed. Because of restrictions on the underlying protocol being used, there are cases in which it is not possible to continue processing even if you select the Continue option. This is the case for PEAP, LEAP, and EAP-FAST; even if you select the Continue option, the request is rejected. The following default values are used for the failure options when you create rules: Authentication failed—The default is reject. User/host not found—The default is reject. Process failure—The default is drop.
3-11 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Chapter 3 ACS 5.x Policy Model Access Services Group Mapping Policy The identity group mapping policy is a standard policy. Conditions can be based on attributes or groups retrieved from the external attribute stores only, or from certificates, and the result is an identity group within the identity group hierarchy. If the identity policy accesses the internal user or host identity store, then the identity group is set directly from the corresponding user or host record. This processing is an implicit part of the group mapping policy. Therefore, as part of processing in the group mapping policy, the default rule is only applied if both of the following conditions are true: None of the rules in the group mapping table match. The identity group is not set from the internal user or host record. The results of the group mapping policy are stored in the IdentityGroup attribute in the System Dictionary and you can include this attribute in policies by selecting the Identity Group condition. Authorization Policy for Device Administration Shell profiles determine access to the device CLI; command sets determine TACACS+ per command authorization. The authorization policy for a device administration access service can contain a single shell profile and multiple command sets. Processing Rules with Multiple Command Sets It is important to understand how ACS processes the command in the access request when the authorization policy includes rules with multiple command sets. When a rule result contains multiple command sets, and the rule conditions match the access request, ACS processes the command in the access request against each command set in the rule: 1.If a command set contains a match for the command and its arguments, and the match has Deny Always, ACS designates the command set as Commandset-DenyAlways. 2.If there is no Deny Always for a command match in a command set, ACS checks all the commands in the command set sequentially for the first match. –If the first match has Pe r m i t, ACS designates the command set as Commandset-Permit. –If the first match has Deny, ACS designates the command set as Commandset-Deny. 3.If there is no match and “Permit any command that is not in the table below” is not checked (default,) ACS designates the command set as Commandset-Deny. 4.If there is no match and “Permit any command that is not in the table below” is checked, ACS designates the command set as Commandset-Permit. 5.After ACS has analyzed all the command sets, it authorizes the command: a.If ACS designated any command set as Commandset-DenyAlways, ACS denies the command. b.If there is no Commandset-DenyAlways, ACS permits the command if any command set is Commandset-Permit; otherwise, ACS denies the command.
3-12 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Chapter 3 ACS 5.x Policy Model Service Selection Policy Related Topics Policy Terminology, page 3-3 Authorization Profiles for Network Access, page 3-16 Exception Authorization Policy Rules A common real-world problem is that, in day-to-day operations, you often need to grant policy waivers or policy exceptions. A specific user might need special access for a short period of time; or, a user might require some additional user permissions to cover for someone else who is on vacation. In ACS, you can define an exception policy for an authorization policy. The exception policy contains a separate set of rules for policy exception and waivers, which are typically ad hoc and temporary. The exception rules override the rules in the main rule table. The exception rules can use a different set of conditions and results from those in the main policy. For example, the main policy might use Identity Group and Location as its conditions, while its related exception policy might use different conditions By default, exception policies use a compound condition and a time and date condition. The time and date condition is particularly valuable if you want to make sure your exception rules have a definite starting and ending time. An exception policy takes priority over the main policy. The exception policy does not require its own default rule; if there is no match in the exception policy, the main policy applies, which has its own default rule. You can use an exception to address a temporary change to a standard policy. For example, if an administrator, John, in one group is on vacation, and an administrator, Bob, from another group is covering for him, you can create an exception rule that will give Bob the same access permissions as John for the vacation period. Related Topics Policy Terminology, page 3-3 Policy Conditions, page 3-16 Policy Results, page 3-16 Policies and Identity Attributes, page 3-17 Service Selection Policy When ACS receives various access requests, it uses a service selection policy to process the request. ACS provides you two modes of service selection: Simple Service Selection, page 3-12 Rules-Based Service Selection, page 3-13 Simple Service Selection In the simple service selection mode, ACS processes all AAA requests with just one access service and does not actually select a service.
3-13 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Chapter 3 ACS 5.x Policy Model Service Selection Policy Rules-Based Service Selection In the rules-based service selection mode, ACS decides which access service to use based on various configurable options. Some of them are: AAA Protocol—The protocol used for the request, TACACS+ or RADIUS. Request Attributes—RADIUS or TACACS+ attributes in the request. Date and Time—The date and time ACS receives the request. Network Device Group—The network device group that the AAA client belongs to. ACS Server—The ACS server that receives this request. AAA Client—The AAA client that sent the request. Network condition objects—The network conditions can be based on –End Station—End stations that initiate and terminate connections. –Device—The AAA client that processes the request. –Device Port—In addition to the device, this condition also checks for the port to which the end station is associated with. For more information on policy conditions, see Managing Policy Conditions, page 9-1. ACS comes preconfigured with two default access services: Default Device Admin and Default Network Access. The rules-based service selection mode is configured to use the AAA protocol as the selection criterion and hence when a TACACS+ request comes in, the Default Device Admin service is used and when a RADIUS request comes in, the Default Network Access service is used. Access Services and Service Selection Scenarios ACS allows an organization to manage its identity and access control requirements for multiple scenarios, such as wired, wireless, remote VPN, and device administration. The access services play a major role in supporting these different scenarios. Access services allow the creation of distinct and separate network access policies to address the unique policy requirements of different network access scenarios. With distinct policies for different scenarios, you can better manage your organizations network. For example, the default access services for device administration and network access reflect the typical distinction in policy that is required for network administrators accessing network devices and an organizations staff accessing the company’s network. However, you can create multiple access services to distinguish the different administrative domains. For example, wireless access in the Asia Pacific regions can be administered by a different team than the one that manages wireless access for European users. This situation calls for the following access services: APAC-wireless—Access service for wireless users in the Asia Pacific region. Europe-wireless—Access service for wireless users in the European countries. You can create additional access services to reduce complexity in policies within a single access service by creating the complex policy among multiple access services. For example, if a large organization wishes to deploy 802.1x network access, it can have the following access services: 802.1x—For machine, user password, and certificate-based authentication for permanent staff. Agentless Devices—For devices that do not have an EAP supplicant, such as phones and printers. Guest Access—For users accessing guest wireless networks.
3-14 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Chapter 3 ACS 5.x Policy Model Service Selection Policy In this example, instead of creating the network access policy for 802.1x, agentless devices, and guest access in one access service, the policy is divided into three access services. First-Match Rule Tables ACS 5.3 provides policy decisions by using first-match rule tables to evaluate a set of rules. Rule tables contain conditions and results. Conditions can be either simple or compound. Simple conditions consist of attribute operator value and are either True or False. Compound conditions contain more complex conditions combined with AND or OR operators. See Policy Conditions, page 3-16 for more information. The administrator selects simple conditions to be included in a policy. The conditions are displayed as columns in a rule table where the column headings are the condition name, which is usually the name of the attribute. The rules are displayed under the column headings, and each cell indicates the operator and value that are combined with the attribute to form the condition. If ANY Figure 3-1 shows a column-based rule table with defined condition types. Figure 3-1 Example Policy Rule Table
3-15 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Chapter 3 ACS 5.x Policy Model Service Selection Policy The default rule specifies the policy result that ACS uses when no other rules exist, or when the attribute values in the access request do not match any rules. ACS evaluates a set of rules in the first-match rule table by comparing the values of the attributes associated with the current access request with a set of conditions expressed in a rule. If the attribute values do not match the conditions, ACS proceeds to the next rule in the rule table. If the attribute values match the conditions, ACS applies the result that is specified for that rule, and ignores all remaining rules. If the attribute values do not match any of the conditions, ACS applies the result that is specified for the policy default rule. Related Topics Policy Terminology, page 3-3 Policy Conditions, page 3-16 Policy Results, page 3-16 Exception Authorization Policy Rules, page 3-12 Column Description Status You can define the status of a rule as enabled, disabled, or monitored: Enabled—ACS evaluates an enabled rule, and when the rule conditions match the access request, ACS applies the rule result. Disabled—The rule appears in the rule table, but ACS skips this rule and does not evaluate it. Monitor Only—ACS evaluates a monitored rule. If the rule conditions match the access request, ACS creates a log record with information relating to the match. ACS does not apply the result, and the processing continues to the following rules. Use this status during a running-in period for a rule to see whether it is needed. Name Descriptive name. You can specify any name that describes the rule’s purpose. By default, ACS generates rule name strings rule-number. Conditions Identity Group In this example, this is matching against one of the internal identity groups. NDG: Location Location network device group. The two predefined NDGs are Location and Device Type. Results Shell Profile Used for device administration-type policies and contains permissions for TACACS+ shell access request, such as Cisco IOS privilege level. Hit Counts Displays the number of times a rule matched an incoming request since the last reset of the policy’s hit counters. ACS counts hits for any monitored or enabled rule whose conditions all matched an incoming request. Hit counts for: Enabled rules reflect the matches that occur when ACS processes requests. Monitored rules reflect the counts that would result for these rules if they were enabled when ACS processed the requests. The primary server in an ACS deployment displays the hit counts, which represent the total matches for each rule across all servers in the deployment. On a secondary server, all hit counts in policy tables appear as zeroes.
3-16 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Chapter 3 ACS 5.x Policy Model Authorization Profiles for Network Access Policy Conditions You can define simple conditions in rule tables based on attributes in: Customizable conditions—You can create custom conditions based on protocol dictionaries and identity dictionaries that ACS knows about. You define custom conditions in a policy rule page; you cannot define them as separate condition objects. Standard conditions—You can use standard conditions, which are based on attributes that are always available, such as device IP address, protocol, and username-related fields. Related Topics Policy Terminology, page 3-3 Policy Results, page 3-16 Exception Authorization Policy Rules, page 3-12 Policies and Identity Attributes, page 3-17 Policy Results Policy rules include result information depending on the type of policy. You define policy results as independent shared objects; they are not related to user or user group definitions. For example, the policy elements that define authorization and permission results for authorization policies include: Identity source and failure options as results for identity policies. See Authorization Profiles for Network Access, page 3-16. Identity groups for group mapping. See Group Mapping Policy, page 3-11. Authorization Profiles for Network Access, page 3-16. Authorization Policy for Device Administration, page 3-11. Security groups and security group access control lists (ACLs) for Cisco Security Group Access. See ACS and Cisco Security Group Access, page 4-23. For additional policy results, see Managing Authorizations and Permissions, page 9-17. Related Topics Policy Terminology, page 3-3 Policy Conditions, page 3-16 Exception Authorization Policy Rules, page 3-12 Policies and Identity Attributes, page 3-17 Authorization Profiles for Network Access Authorization profiles define the set of RADIUS attributes that ACS returns to a user after successful authorization. The access authorization information includes authorization privileges and permissions, and other information such as downloadable ACLs.
3-17 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Chapter 3 ACS 5.x Policy Model Policies and Identity Attributes You can define multiple authorization profiles as a network access policy result. In this way, you maintain a smaller number of authorization profiles, because you can use the authorization profiles in combination as rule results, rather than maintaining all the combinations themselves in individual profiles. Processing Rules with Multiple Authorization Profiles A session authorization policy can contain rules with multiple authorization profiles. The authorization profile contains general information (name and description) and RADIUS attributes only. When you use multiple authorization profiles, ACS merges these profiles into a single set of attributes. If a specific attribute appears: In only one of the resulting authorization profiles, it is included in the authorization result. Multiple times in the result profiles, ACS determines the attribute value for the authorization result based on the attribute value in the profile that appears first in the result set. For example, if a VLAN appears in the first profile, that takes precedence over a VLAN that appears in a 2nd or 3rd profile in the list. NoteIf you are using multiple authorization profiles, make sure you order them in priority order. The RADIUS attribute definitions in the protocol dictionary specify whether the attribute can appear only once in the response, or multiple times. In either case, ACS takes the values for any attribute from only one profile, irrespective of the number of times the values appear in the response. The only exception is the Cisco attribute value (AV) pair, which ACS takes from all profiles included in the result. Related Topics Policy Terminology, page 3-3 Authorization Policy for Device Administration, page 3-11 Policies and Identity Attributes The identity stores contain identity attributes that you can use as part of policy conditions and in authorization results. When you create a policy, you can reference the identity attributes and user attributes. This gives you more flexibility in mapping groups directly to permissions in authorization rules. When ACS processes a request for a user or host, the identity attributes are retrieved and can then be used in authorization policy conditions. For example, if you are using the ACS internal users identity store, you can reference the identity group of the internal user or you can reference attributes of the internal user. (Note that ACS allows you to create additional custom attributes for the internal identity store records.) If you are using an external Active Directory (AD), you can reference AD groups directly in authorization rules, and you can also reference AD user attributes directly in authorization rules. User attributes might include a user’s department or manager attribute.
3-18 User Guide for Cisco Secure Access Control System 5.3 OL-24201-01 Chapter 3 ACS 5.x Policy Model Policies and Network Device Groups Related Topics Managing Users and Identity Stores, page 8-1 Policy Terminology, page 3-3 Types of Policies, page 3-5 Policies and Network Device Groups You can reference Network device groups (NDGs) as policy conditions. When the ACS receives a request for a device, the NDGs associated with that device are retrieved and compared against those in the policy table. With this method, you can group multiple devices and assign them the same policies. For example, you can group all devices in a specific location together and assign to them the same policy. When ACS receives a request from a network device to access the network, it searches the network device repository to find an entry with a matching IP address. When a request arrives from a device that ACS identified using the IP address, ACS retrieves all NDGs associated with the device. Related Topics Managing Users and Identity Stores, page 8-1 Policy Terminology, page 3-3 Types of Policies, page 3-5 Example of a Rule-Based Policy The following example illustrates how you can use policy elements to create policy rules. A company divides its network into two regions, East and West, with network operations engineers at each site. They want to create an access policy that allows engineers: Full access to the network devices in their region. Read-only access to devices outside their region. You can use the ACS 5.3 policy model to: Define East and West network device groups, and map network devices to the appropriate group. Define East and West identity groups, and map users (network engineers) to the appropriate group. Define Full Access and Read Only authorization profiles. Define Rules that allow each identity group full access or read-only access, depending on the network device group location. Previously, you had to create two user groups, one for each location of engineers, each with separate definitions for permissions, and so on. This definition would not provide the same amount of flexibility and granularity as in the rule-based model.