Network Access Restrictions

Network Access Restrictions (NARs) are additional authorization conditions that must be met before ACS grants a user access on to the network.

Types of NARs

In the shared profile components configuration page, you can add a new named access restriction, or you can access an existing named NAR to delete or edit it.

Two types of access restrictions exist:

• IP-based filters where the originating request relates to an IP address

• Non-IPbased restrictions for all other cases where automatic number identification (ANI) can be used

When configured, a NAR can be applied to a single user in the users profile or a group in the group setup page.

Working with NARs

NARs enable you to define additional authorization and authentication conditions that must be met before a user is granted access to the network. These restrictions are in addition to authentication credentials supplied by the user.

NARs are based on attributes that come from the AAA client through which the user is accessing the network. To properly configure NARs, you must understand the types of attributes that are passed from the AAA client. Once you understand the attributes passed, you determine a conditions action. In other words, you determine an action to be taken when an attribute is matched. Possible actions include permit or deny. If an attribute is passed that does not include sufficient information, the default rule is to deny access. These possible actions are seen in Table 10-1.

Table 10-1. NAR Actions

	Match	No Match	Insufficient Information
Permit	Access granted	Access denied	Access denied
Deny	Access denied	Access granted	Access denied

When you configure NARs, you have two options to choose. One is IP-based restrictions and the other is non-IPbased restrictions. The IP-based access restrictions are where the originating request is related to an existing IP address. The non-IPbased NARs are filters for all other cases where ANI can be used.

IP-Based NARs

IP-based NARs are based on one of two sets of attribute fields, depending on the protocol you are using. The following is a list of attributes:

• If you are using TACACS+, the rem_addr field is used.

• If you are using RADIUS IETF, the calling-station-id (attribute 31) and called-station-id (attribute 30) fields are used.

Again, if AAA clients do not provide sufficient IP-address information to ACS, the default rule is to deny access. This might happen when using NARs where the AAA client is a firewall. Some firewalls do not send sufficient IP information to the ACS, so full NAR functionality might not be supported.

Non-IPBased NARs

A non-IPbased NAR is a list of permitted or denied "calling"/"point of access" locations that you can employ in restricting an AAA client when you do not have an IP-based connection established. The non-IPbased NAR generally uses the calling line ID (CLID) number and the dialed number identification service (DNIS) number. The CLID is the number that identifies where a call is coming from, and a DNIS is the number that is being dialed. You can use the non-IPbased filter when the AAA client does not use a Cisco IOS release that supports CLID or DNIS by entering an IP address in place of the CLID.

Another exception to entering a CLID is to enter a MAC address to permit or deny access. An example of a situation where a MAC address is used is with a Cisco Aironet AAA client. Enter the Cisco Aironet Access Point (AP) MAC address in place of the DNIS. The format you specify in the CLID boxbe it CLID, 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.