Configuring Network Access Restrictions


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:

  • A non-IP-based NAR is a list of permitted or denied "calling" or "point of access" locations that you can employ in restricting an AAA client when an IP-based connection is not established. The non-IP-based NAR generally uses the calling line ID (CLID) number and the Dialed Number Identification Service (DNIS) number.

  • By entering an IP address instead of the CLID, you can use the non-IP-based filter even when the AAA client does not use a Cisco IOS Software release that supports CLID or DNIS. In another exception to entering a CLID, you can enter a MAC address to permit or deny access when you are using a Cisco Aironet AAA client. Likewise, you could enter the Cisco Aironet access point MAC address instead of the DNIS number. The format of what you specify in the CLID boxCLID, IP address, or MAC addressmust match the format of what you receive from your AAA client. You can determine this format from your RADIUS accounting log.

  • When specifying a NAR, you can use an asterisk (*) as a wildcard for any value, or as part of any value, to establish a range. All the values and conditions in a NAR specification must be met for the NAR to restrict access. That is, the values are "ANDed."[1]

How a NAR Finds a Match

A 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].

Table 8-1. NAR Permit and Deny Conditions
 

Match

No Match

Insufficient Information

Permit

Access granted

Access denied

Access denied

Deny

Access denied

Access granted

Access denied


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 NAR

You 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:

Step 1.

From the left frame menu, choose the button labeled Group Setup.

Step 2.

Select the FirstUsers group in the drop-down list.

Step 3.

Click Edit.

Step 4.

Scroll to Per Group Defined Network Access Restrictions.

Step 5.

Select the check box Define IP-based access restriction.

Step 6.

In the drop-down, select Permitted Calling/Point of Access Locations.

Step 7.

Select router14all in the AAA Client drop-down. If router14all does not appear in your ACS configuration, you need to add it to the network configuration. Figure 8-6 demonstrates this AAA client.

Step 8.

Enter 23 in the Port Field.

Step 9.

Enter 10.*.*.* in the Address field.

Step 10.

Click Enter.

Step 11.

Click Submit and Restart.

Figure 8-6. router14all's Network Configuration


NOTE

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 User

Now 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 Topology


The 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:

Step 1.

Access the user that you want to apply the NAR to.

Step 2.

When in the edit screen of the user, scroll to the Network Access Restrictions (NAR) heading.

Step 3.

Select the check box Define IP-based access restriction.

Step 4.

In the drop-down, select Denied Calling/Point of Access Locations.

Step 5.

Select router14all in the AAA client drop-down. If router14all does not appear in your ACS configuration, you need to add it to the network configuration. Figure 8-6 demonstrated this AAA client.

Step 6.

Enter 23 in the Port Field.

Step 7.

Enter 10.*.*.* in the Address field.

Step 8.

Click Enter.

Step 9.

Click Submit.

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 Configuration


A Look at Shared Network Access Restrictions

By 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."




Cisco Access Control Security(c) AAA Administrative Services
Cisco Access Control Security: AAA Administration Services
ISBN: 1587051249
EAN: 2147483647
Year: 2006
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net