Cisco Systems OL-9971-01 manual Fallback on Failed Connection, An Example

Chapter 3 Network Configuration

Proxy in Distributed Systems

An Example

This section presents a scenario of proxy that is used in an enterprise system. Mary is an employee with an office in the corporate headquarters in Los Angeles. Her username is mary@la.corporate.com. When Mary needs access to the network, she accesses the network locally and authenticates her username and password. Because Mary works in the Los Angeles office, her user profile, which defines her authentication and authorization privileges, resides on the local Los Angeles AAA server.

However, Mary occasionally travels to a division within the corporation in New York, where she still needs to access the corporate network to get her e-mail and other files. When Mary is in New York, she dials in to the New York office and logs in as mary@la.corporate.com. The New York ACS does not recognize her username, but the Proxy Distribution Table contains an entry, @la.corporate.com, to forward the authentication request to the Los Angeles ACS. Because the username and password information for Mary reside on that AAA server, when she authenticates correctly, the AAA client in the New York office applies the authorization parameters that are assigned to her.

Proxy Distribution Table

Whether, and where, an authentication request is to be forwarded is defined in the Proxy Distribution Table on the Network Configuration page. You can use multiple ACSs throughout your network. For information about configuring the Proxy Distribution Table, see Configuring Proxy Distribution Tables, page 3-27.

ACS employs character strings that the administrator defines to determine whether an authentication request should be processed locally or forwarded, and where. When an end user dials in to the network device and ACS finds a match for the character string defined in the Proxy Distribution Table, ACS forwards the authentication request to the associated remote AAA server.

Note When an ACS receives a TACACS+ authentication request forwarded by proxy, any requests for Network Access Restrictions for TACACS+ are applied to the IP address of the forwarding AAA server, not to the IP address of the originating AAA client.

Note When an ACS proxies to a second ACS, the second ACS responds to the first by using only IETF attributes, no VSAs, when it recognizes the first ACS as the AAA server. Alternatively, you can configure the second ACS to see an ACS as a AAA client; in this case, the second ACS responses include the RADIUS VSAs for whatever RADIUS vendor is specified in the AAA client definition table entry—in the same manner as any other AAA client.

Administrators with geographically dispersed networks can configure and manage the user profiles of employees within their immediate location or building. The administrator can, therefore, manage the policies of just their users and all authentication requests from other users within the company can be forwarded to their respective AAA server for authentication. Not every user profile must reside on every

AAAserver. Proxies save administration time and server space, and allows end users to receive the same privileges regardless of the access device through which they connect.

Fallback on Failed Connection

You can configure the order in which ACS checks remote AAA servers if a failure of the network connection to the primary AAA server occurs. If an authentication request cannot be sent to the first listed server, because of a network failure for example, the next listed server is checked. This checking

User Guide for Cisco Secure Access Control Server

3-4 OL-9971-01