Policy Elements
You know from Chapter 2 that ACS 5.x is based on a rule-based policy model. You also know that the rules are called policies and they consist of conditions and results, which are called policy elements. In this section and the next, you will learn more about policy elements and how to create them, the different types of policies, and the flow of a request through different processes in ACS.
Before creating policies, you must create policy elements, which are the building blocks of policies. Policy elements are divided into two types: session conditions and authorization and permissions.
Session conditions are conditions used to apply policies to requests. Some conditions are available by default, whereas others can be created by you. The following conditions are available by default:
Request/Protocol Attributes: These attributes are derived from the authentication request itself.
Identity Attributes: Identity attributes are derived from the user definition in the internal identity store or external repositories such as LDAP and Active Directory. The attributes need to be mapped in the external database configuration before they become available in the policies. See Chapter 5 for more on external databases and attribute mapping.
Identity Groups: You can map every user and host to an identity group. This group association can be used in policies as a condition.
Network Device Groups(NDGs): Each device is associated with an NDG. This association can be used as a condition in the policies.
The following conditions can be created by you:
Date and Time Conditions: You can create conditions that define specific time intervals across days of the week. These conditions take into account the current date and time and return a true or false result indicating whether the condition is met.
Custom Conditions: You can create conditions based on attributes of various identity and protocol dictionaries which are available in ACS. These conditions allow you to apply policies based on the authentication and authorization requests received from AAA clients.
Network Conditions: You can create conditions based on the following to restrict access:
- End Station Filters: These are based on end stations that initiate and terminate the connection. End stations may be identified by IP Address, MAC Address, or Caller Line Identification (CLI) and Dialed Number Identification Service (DNIS) fields obtained from the request.
- Network Device Filters: Based on the AAA client that processes the request. A network device can be identified by IP address, the name of the device that is defined in the network device repository or the network device group (NDG).
- Device Port Filters: Network device definition might be supplemented by the device port that the end station is connected to.
- These filters or conditions can be included in policy conditions. This set of definitions is matched against those presented in the request. The operator that you use in the condition can either be match (in which case the value presented must match at least one entry within the network condition) or no matches (in which case it should not match any entry in the set of objects present in the filter).
Authorization and permissions are the results applied to a request that matches a condition in a policy. You can define the following types of results:
Authorization Profiles: You can define a set of attributes and values that is returned to the device in Access-Accept responses for network access requests. These profiles can contain common data such as VLAN information, reauthentication timer, or any RADIUS attribute.
Shell Profiles: You can define a set of permissions that is applied to a user requesting administrative access of a device. Some of these permissions include privilege level, auto command, and custom TACACS+ attributes.
Command Sets: You can define a list of commands that a user can execute on a device during an administrative session.
Downloadable ACLs: You can define downloadable ACLs that can be sent to a device with an Access-Accept message.
If you have worked on previous ACS versions (4.x or 3.x), you must have noticed that many of the policy elements were available earlier in the Group Setup. The difference in ACS 5.x is that these conditions and results are now defined globally and can be used in multiple rules. Group-based configuration required configuring the conditions and results in each group even if they were similar.
Figure 4-13 shows a typical simplified flow of a request through ACS. Note the different places where policy elements are used. At this stage, do not worry about the different policies shown in the figure because they will be covered later in the chapter.
Flow of a Request Through ACS 5.x
The following sections look at creating the different policy elements.
Session Conditions: Date and Time
To create a Date and Time session condition, follow these steps:
Step 1. | Select Policy Elements > Session Conditions > Date and Time. |
Step 2. | Click Create. The Date and Time Properties page appears as shown in Figure 4-14. |
Step 3. | Enter a name. For this example, use Work-week. |
Step 4. | (optional) Enter a description. |
Step 5. | Define start and end times for this element. During the period defined, the element can be used by policies. You can select Start Immediately and No End Date for the element to be active always or select a specific date and time during which this element will be active. This is useful when you want to provide some access or privilege for only a certain duration. For our example, select the Start Immediately and No End Date options. |
Step 6. | Select the days and time during which this element will return a positive reply for access request. Each square in the grid is equal to one hour. Select a grid square to make the corresponding time active. For this example, select 7:00 to 18:00 hours, Monday to Friday as shown in Figure 4-14. |
Step 7. | Click Submit. |
Creating Date and Time Condition
The policy element you created will restrict access to 7:00–18:00 hours on Monday through Friday, when applied to a policy.
Session Conditions: Custom
To create a custom session condition, follow these steps:
Step 1. | Select Policy Elements > Session Conditions > Custom. |
Step 2. | Click Create. The Custom Condition Properties page appears. This page is shown in Figure 4-15. |
Step 3. | Enter a name. For our example, use Protocol. |
Step 4. | (optional) Enter a description. |
Step 5. | Select Dictionary from the drop-down list. Different Protocol and Identity dictionaries are available in the drop-down list. For our example, select RADIUS-IETF. |
Step 6. | Click Select next to the Attribute text box and select an attribute. For our example, select Framed-Protocol. |
Step 7. | Click Submit. |
Creating a Custom Session Condition
The custom condition that you just created will match the Framed-Protocol attribute in a RADIUS request when applied to a policy.
Session Conditions: End Station Filters
To create an end station filter, follow these steps:
Step 1. | Select Policy Elements > Session Conditions > Network Conditions > End Station Filters. |
Step 2. | Click Create. The End Station Filter Properties page appears as shown in Figure 4-16. |
Step 3. | Enter a Name. For this example, use Host List 1. |
Step 4. | (optional) Enter a description. |
Step 5. | End stations can be filtered by IP address, MAC address, or Calling Line ID (CLI)/Dialed Number Identification Service (DNIS). The filter values are added under the respective tabs. For this example, select the IP Address tab. |
Step 6. | Click Create. A dialog box opens where you can enter an IP address or a range of addresses. For this example, select IP Range(s) and enter 192.168.1.0 in the IP text box and 24 in the Mask text box. Click Ok. 192.168.1.0/24 is now listed in the Network Devices table. Note that the options in the dialog box will change depending on the tab selected. |
Step 7. | Click Submit. |
Creating an End Station Filter
The filter you created will match any host in the 192.168.1.0/24 when applied to a policy.
Session Conditions: Device Filters
To create a device filter, follow these steps:
Step 1. | Select Policy Elements > Session Conditions > Network Conditions > Device Filters. |
Step 2. | Click Create. The Device Filter Properties page appears as shown in Figure 4-17. |
Step 3. | Enter a name. For this example, use Core Routers. |
Step 4. | You can enter the IP addresses of devices, the names of devices already in the ACS repository, or a network device group under the respective tabs. For this example, select the Network Device Group tab. |
Step 5. | Click Create. A dialog box appears where the NDG can be selected. Click Select next to the NDG Type text box and select the Routers group that you created earlier. Then click on Select next to the NDG Value text box and select the Core Routers group that you created earlier. Click Ok. The Core Routers NDG is now listed in the Network Devices table. Note that the options in the dialog box will change depending on the tab selected. |
Step 6. | Click Submit. |
Creating Device Filters
The device filter you created will match any device in the Core Routers NDG when applied to a policy.
Session Conditions: Device Port Filters
The steps to create a device port filter are similar to the one you followed to create device filters. The only difference is the addition of a Port text box in the dialog box where you select or enter device information. Figure 4-18 shows the Device Port Filter properties page where the Core Routers NDG is added with port 23.
Creating Device Port Filters
Note - Authorization and permissions policy elements are covered in later chapters.
Authorization profiles are covered in Chapter 8, “IOS Switches.”
Shell profiles and command sets are covered in Chapter 6, “Administrative AAA on IOS.”
Downloadable ACLs are covered in Chapter 10, “Cut-Through Proxy AAA on PIX/ASA.”
Access Policies
Before you start creating policies, it is important to understand how ACS applies a particular policy to a request and how many policies are available. ACS uses service selection rules and access services to decide on a policy to apply to a request.
Service Selection Rules
Service selection rules decide which access service to send an authentication or authorization request to. You can configure ACS to use a single access service to process all requests or use rules based on session conditions to send requests to different access services. In the case of a rule-based selection, ACS uses the first rule from the top that matches a request.
Note - When rules are used for service selection, ACS provides an option to configure a default rule. If a request does not match any rules in the table, the default rule is applied.
To further understand how this works, take a department store for example. A department store is divided into sections using product category (clothing, sporting goods, jewelry, and so on). An ACS configured to use a single access service is like the department store. All requests go to a single access service, which has different policies. The access service checks session conditions and applies the appropriate policy. Consider a grocery store for another example. A grocery store sells only groceries, but might have sections based on different categories (produce, meat, canned goods, and so on). An ACS configured for rule based service selection is similar to such a store. It will send different kinds of requests to different access services. Each access service equates to a specialized store. These access services will have different policies.
To further understand service selection rules and access services, consider another example. XYZ Inc. has five offices. Each office has routers terminating VPN connections. These routers are going to authenticate and authorize VPN sessions and administrative sessions to a single ACS. There are two ways to configure ACS for the organization:
Method 1: Configure ACS to send all requests to a single access service and configure two policies in the access service. One policy to process all administrative session requests via the TACACS+ protocol and the other to process all VPN session requests via the RADIUS protocol.
Method 2: Configure ACS to send all TACACS+ (administrative sessions) requests to one access service and to send all RADIUS (VPN sessions) request to another access service. Each access service can have one or more policies to process the requests.
Method 1 is easier to configure and maintain; however, it can get very complicated if different authentication or authorization methods need to be applied. For example, one site might need more stringent authorization for VPN sessions than other sites or administrators might need restricted access to remote devices. Further consider an organization with 100 sites and thousands of network devices. In such scenarios, policies will increase in the access service and soon become unmanageable. On the other hand, different access services will have a smaller number of policies and will be easier to manage.
Access Services
Access services are the most basic parts of ACS. They are sets of policies which process all authentication and authorization requests. Every authentication and authorization request has to match a policy in an access service before it is processed. As you already know, a request is sent to an access service by the service selection rules. When an access service receives a request, it checks policies in a top-down manner and applies the first policy that matches the session conditions.
Access services consist of the following types of policies:
Identity Policy: Specifies how the user should be authenticated and includes the allowed authentication protocols and the user repository to use for password validation. Identity policies can be simple or rule based. Simple policies apply a single policy to all requests. Rule-based policies use session conditions to choose rules for requests.
Group Mapping Policy: Specifies whether the user’s ACS identity group should be dynamically established based on user attributes or group membership in external identity stores. The user’s identity group can be used as part of its authorization. Chapter 5 covers group mapping in more detail.
Authorization Policy: Specifies the authorization rules for the user. Authorization policies can only be rule based.
Note - If a policy is rule based, ACS checks rules in a top-down manner and uses the first rule that matches. ACS also provides an option to configure a default rule. If a request does not match any rules in the table, the default rule is applied.
ACS has two access services by default:
Default Device Admin: Service selection rules are configured to send all TACACS+ requests to this default access service.
Default Network Access: Service selection rules are configured to send all RADIUS requests to this default access service.
Creating an Access Service
Access services and their policies bring together different elements from ACS. Hence, before creating an access service, you should determine the network configuration and the degree of refinement that you want individual policies to have. Depending on that, you should add devices and users or user databases. You should also create different policy elements such as session conditions and authorization and permission elements. Ensuring that you have all the required components will save you from moving back and forth between different drawers in the menu.
To create an access service, follow these steps:
Step 1. | Select Access Policies > Access Services. The Access Services page appears. |
Step 2. | Click Create. The Access Service General Properties page appears as shown in Figure 4-19. |
Step 3. | Enter a name. For this example, use Remote Access VPN. |
Step 4. | (optional) Enter a description. |
Step 5. | Select one of the following options for Access Service Policy Structure:
For this example, select User Selected Service Type and select Network Access from the drop-down box. Select Identity and Authorization in the policy structure. |
Step 6. | Click Next. The Allowed Protocols properties page appears as shown in Figure 4-20. |
Step 7. | This page enables you to select which authentication protocols will be allowed with this access service. PAP, CHAP, MS-CHAPv1, MS-CHAPv2 and various EAP protocols are available as options. You can also enable host lookup (required for machine authentication) from this page. For this example, deselect Process Host Lookup and select Allow PAP/ASCII and Allow MS-CHAPv2. |
Step 8. | Click Finish. The access service will be saved and will appear as a menu item in the Access Services drawer. Below the menu item, selected policy types will be shown as submenu items. At this point, a prompt will give you an option to activate this service in the Service Selection Rules. For now, click No. The Access Services page will appear with the new access service listed in the table. |
General Properties of a New Access Service
Configuring Allowed Protocols in an Access Service
You are now ready to configure the identity rules and authorization rules for the new access service.
Configuring Identity Policy
As you already know, identity policies can be simple or rule-based. By default, identity policies are simple. When you select Identity under a new Access Service (Remote Access VPN for this example) in the Access Policies drawer, you will find that the Single result selection option is selected and Identity Source is DenyAccess.
If you want to configure a simple policy, follow these steps:
Step 1. | Click Select next to Identity Source and select an identity store. You can select between certificate-based authentications or different password-based internal or external identity stores. |
Step 2. | (Optional) Click Advanced Options to display the fail-open options. Fail-open opens enable you to configure the behavior of ACS when authentication fails, the user is not found in an identity store, or there is a process failure. A process failure occurs when ACS is not able to verify the credentials, usually due to external factors such as a network failure between ACS and an external database. To understand the fail-open process, you have to remember that a device will fail over to a different AAA server if the primary server does not respond to a request. Each of the three fail-open options has three possible actions:
By default ACS will reject a request if authentication fails or a user is not found, and will drop a request if the process fails. Figure 4-21 shows this page with the default Advanced options. |
Step 3. | Click Save Changes. |
Configuring a Simple Identity Policy
If you want to configure a rule-based identity policy, follow these steps:
Step 1. | Select Rule based result selection from the Identity Properties page. This will change the properties page to a rule-based table format shown in Figure 4-22. |
Step 2. | The rules of an Identity policy use session conditions to determine which identity store to use for a request. The session conditions available in the Rules Properties page need to be enabled from the Identity Properties page. Click Customize to open the Customize Conditions dialog box. Select the conditions that you want to use. For this example, deselect default conditions and select NDG:Routers (you created this NDG earlier in this chapter). |
Step 3. | Click Create. The Identity Rule properties page appears as shown in Figure 4-23. |
Step 4. | Enter a name. For this example, use Core Routers. |
Step 5. | Select a session condition. In this example, only NDG:Routers is available, so select it. |
Step 6. | Select an operator from the drop-down box next to the selected condition. The available operators change depending on the condition selected. These are logical operators that allow matching or not matching the user-provided argument with the selected condition. For this example, select in from the drop-down box. |
Step 7. | For some conditions, such as NDGs, you will see a Select button next to the condition. You can click this button to select the required element. For some conditions, you will get a drop-down box or a text box. For this example, click Select and select Core Routers NDG. |
Step 8. | In the Results section, you can select the identity source to be used for this rule. Click Select next to Identity Source and select an identity store. You can select between certificate-based authentications or different password-based internal or external identity stores. For this example, use Internal Users. |
Step 9. | (Optional) Click Advanced Options to display the fail-open options. Remember that by default, ACS will reject a request if authentication fails or a user is not found, and will drop a request if the process fails. For this example, leave them set to the default values. |
Step 10. | Click OK. The rule will be saved and the Identity Policy page will appear with the rule listed in the table. The rule you created will use the Internal Users identity store to authenticate requests that originate from any device in the Core Routers NDG. You can add more rules to use different identity stores for different session conditions. |
The Identity Policy Page for a Rule-Based Configuration
Configuring the Rules of an Identity Policy
Now that the identity policy is configured, you can configure the authorization policy to complete the access service.
Configuring Authorization Policy
As mentioned earlier, authorization policies are rule based only. You cannot configure a simple authorization policy, but you can configure a single rule that will match all requests coming to the access service.
ACS also provides a default authorization rule. The default rule is applied if no rules are defined in an authorization policy or if a request does not match any defined rules.
Note - I strongly suggest that you do not use the default rule to avoid security lapses. Using the default rule in most circumstances is like having a gate but leaving it open. You should have explicit rules for all variations of requests you get.
To configure a rule, follow these steps: