As you begin to explore the group section to apply Network Access Restrictions (NAR), note that you see no current NARs in the left vertical box titled NARs. This is because you must first configure the NAR before you can apply it. In this section, you configure a NAR and then apply it to an interface. The type of NAR that you configure is called a shared NAR. All users of this group share this common NAR, and you can also use this NAR for other groups. A NAR is simply additional access restrictions that must be met before a user can access the network. By using a NAR, you are going to create an IP-based filter or a non-IP-based filter that provides that additional set of access restrictions. All in all, NARs must match specific attributes sent to the ACS by the AAA client. Understanding how to match these attributes is the key factor when deploying NARs in ACS. Note the following information from a white paper on NARs:
How a NAR Finds a MatchA NAR creates a rule that is based on a match or no match condition. In other words, permission to the network means that you match the NAR. If you do not match the NAR or if not enough information is provided, you are denied access to the network, provided the NAR is a PERMIT. If your NAR is used to deny access to the network, a match to the statement would invoke action to deny, and no match or not enough information would then permit network access. It is important to understand what attribute field is used when a NAR is configured. The attribute field used if the TACACS+ protocol is in use is the rem_addr field. If you use RADIUS (IETF), calling-station-id (attribute 31) and called-station-id (attribute 30) are used. An attribute is an indication of what type of data is included; the value is the data. NOTE Chapter 13, "Exploring TACACS+ Attribute Values," covers the TACACS+ and RADIUS attribute/value pairs. You can see the actions performed by a NAR more clearly in Table 8-1, the content of which was taken from a white paper[2].
When the ACS that's proxied to receives the T+ request, it checks to see if it has been sent by an IP address that it recognizes as the IP address of the AAA client in the NAR. Unless, as a workaround, the AAA server is configured as an AAA client, too, so that the NAR is written with this bogus AAA client instead of the real AAA client whose IP address is not associated with the forwarded T+ packet, the NAR will never match. Configuring the NARYou can configure a NAR in more than one way. You can configure a NAR in the group configuration, the user configuration, or as a shared NAR by using options available in Shared Profile Components. In this example, you configure a NAR only in the group configuration. In Chapter 9, "Managing Network Configurations," the Shared Profile Components are discussed. Follow these steps to configure the NAR at the group level for the network in Figure 8-6:
Figure 8-6. router14all's Network ConfigurationNOTE In this situation, the default Permitted Calling/Point of Access option is selected in the field labeled Table Defines. Remember that this defines the "match." In other words, if the source IP address matches and the connection to port 23 is to the selected AAA client, the user is permitted access. If the IP address does not match that of the source address and is not destined for the AAA client, router14all, the users are denied access. The other option that you could select is the Denied Calling/Point of Access option. This would behave opposite the example. Applying a NAR to a UserNow that you have a NAR specified for this group, it's time to look at an extension to the group configuration by adding NARs to the individual user configuration. For this example, you use the network diagram in Figure 8-7. Figure 8-7. Simple NAR TopologyThe AAA client router14all is the device that you want to control access to. In this simple network diagram, only two PCs are shown; however, they are in different subnets. The user ADMIN should not be allowed access from any subnet variation of the 10.x.x.x network, and all other users are allowed access to the AAA client on port 23. To accomplish this, you create two NARs. To apply the NAR to this user, follow these steps:
In this configuration, the opposite effect takes place. The user with the deny NAR is not allowed to access port 23 of the AAA client router14all. This configuration is seen in Figure 8-8. Figure 8-8. Deny NAR in the User ConfigurationA Look at Shared Network Access RestrictionsBy examining the User Setup, you find that user-level Network Access Restrictions are what you used in the preceding example. Although this method works, it is recommended that you create shared Network Access Restrictions in shared profile components. This is a more modular approach and gives you the ability to re-use any NAR that you create. You most likely need to enable shared Network Access Restrictions for both the user and group levels. This is done in Interface Configuration under Advanced Options. This configuration is performed in Chapter 10, "Configuring Shared Profile Components." |