Core issue
Network Access Restrictions (NARs) provide authorization conditions that have to be met before a user can gain access to the network. Cisco Secure ACS applies these conditions using information from attributes sent by authentication, authorization, and accounting (AAA) clients. Although NARs can be set up in several ways, all of methods are based on matching attribute information sent by an AAA client. Therefore, it is essential to understand the format and content of the attributes that the AAA clients send if NARs are to be employed effectively.
Resolution
For more details about NARs, refer to the Network Access Restrictions White Paper.
For more details about how to configure NARs, refer to the Setting Network Access Restrictions for a User section of the User Guide for Cisco Secure ACS Solution Engine 3.3.
Note: It is usually advantageous to configure both IP-based and Calling Line ID (CLI)/Dialed Number Identification Service (DNIS) based NARs because of the way NARs are processed in Cisco Secure ACS. If the caller-ID value is present in the authentication packet ([13] Calling-Station-ID for RADIUS and rem_addr for TACACS+) and contains an IP address, then IP-based NARs are checked if that section is enabled.
If the value is absent or contains something other than an IP address, then the CLI/DNIS section is used instead, if it is enabled.
Also, note that Cisco Secure ACS determines what Network Access Server (NAS) the user connects to based on the [004] NAS-IP-Address value in the RADIUS packet, not on the IP of the requesting host as reported in failed or passed attempts. This can cause confusion if the NAS IP in the passed or failed attempts is different than that in the NAS-IP-Address attribute, which could be due to proxying.
