|
|
This chapter provides an introduction to the advantages and features of the CiscoSecure Global Roaming Server (CiscoSecure GRS), as well as information on accounting and specification conformance for Terminal Access Controller Access Control System (TACACS+) and Remote Access Dial-In User Service (RADIUS).
CiscoSecure GRS allows a regional service provider (RSP) to lease its points of presence (POPs) to customers such as Internet service providers (ISPs). The ISP can lease the RSP's POPs to provide or expand coverage. CiscoSecure GRS offers these advantages:
The CiscoSecure GRS software sits between the network access server (NAS) and the access control server (ACS) for network access security. CiscoSecure GRS acts as a proxy agent that translates and, if necessary, forwards packets between the NAS and the ACS.
This section describes the CiscoSecure GRS features.
Most CiscoSecure GRS configuration tasks can also be accomplished through the command-line interface. CiscoSecure GRS includes utilities that can be used for adding, updating, and removing entries from the CiscoSecure GRS data store. We recommend that you use these tools instead of using SQL commands, because the tools automatically ensure the integrity of the relationships needed for CiscoSecure GRS to operate correctly. See the chapter "Using the CiscoSecure GRS Command-Line Options and Utilities" for information on using the utilities.
CiscoSecure GRS can also proxy authentication and authorization requests that do not have an @ in the username, using a configurable set of characters as delimiters, such as dots (.), slashes (/), and hyphens (-). When configuring CiscoSecure GRS delimiters, you specify whether the domain is the prefix or suffix. An example of a suffix domain is user*domain.us (* represents any delimiter). An example of a prefix domain is domain.us*user.
Two types of data storage options are available with CiscoSecure GRS, a flatfile data store or an Oracle System 7.3.x database. For more information on the data store options, see the section "CiscoSecure GRS Data Store Options" in the chapter "Installing and Starting CiscoSecure GRS."
CiscoSecure GRS offers an optional feature that allows stripping from domains. Stripping allows CiscoSecure GRS to remove matching strings from the domain portion of the username. You can enable stripping during authentication, authorization, and/or accounting.
When the stripping feature is enabled, CiscoSecure GRS examines each address for matching information. When it finds any matching information, it removes it. Continuing to use the example in the section "Configurable Prefix and Suffix Delimiters," if CiscoSecure GRS is configured to match ".us" and stripping is enabled, the ".us" is removed from "domain.us," leaving an address of user*domain or domain.user.
The stripping feature is based on a matching algorithm. Matching information is stripped, and the matching algorithm always selects the longest match first. Stripping is configurable on a per-domain basis.
The CiscoSecure GRS daemon grs_d enables fault tolerance for CiscoSecure GRS. This daemon allows CiscoSecure GRS to start, monitor the daemon grs, and automatically restart CiscoSecure GRS after an unexpected shutdown. See the section "start_grs" in the chapter "Using the CiscoSecure GRS Command-Line Options and Utilities."
CiscoSecure GRS features a Java-based graphical user interface (GUI) that allows you to easily configure CiscoSecure GRS, the CiscoSecure GRS data store, and the grs.ini file. This standalone application runs only on the Solaris machine on which it is installed.
The RSP can use the MaxSessions parameter to restrict the number of sessions the ISP can use concurrently.
The RSP can bill its customers based on a maximum number of proxy sessions. For example, the RSP might lease a maximum number of 100 simultaneous sessions to a local ISP. CiscoSecure GRS can limit the number of simultaneous sessions for any given RSP customer.
Proxy allows an RSP to provide coverage to its users in areas that are not normally covered by its POPs. This is especially valuable to users who travel.
For example, a local New York area RSP using the proxy feature of CiscoSecure GRS can lease its POPs to an ISP located in the San Francisco Bay Area.
When they travel to New York, the San Francisco Bay Area ISP's customers can place a local call to the closest POP rather than having to dial an expensive long-distance telephone number or an 800 number that might have access charges.
Figure 1-1 and Figure 1-2 illustrate the differences between a system without proxy and one with proxy.
CiscoSecure GRS supports proxy from TACACS+ to TACACS+ and from RADIUS to RADIUS.
Usernames of roaming users must have one of the following formats:
username = name@domain
or
username = name@domain.home_country
For example:
mary@cisco
or
mary@cisco.us
CiscoSecure GRS also supports using the domain as a prefix. For example:
cisco.us*mary
Proxy can also be used to provide wider coverage for an ISP. An ISP can either purchase and maintain all its own NASes, or it can lease POPs from an RSP. If the ISP maintains its own ACS, proxy is required.
In the situation described in the "Proxy" section, the ISP and the RSP are using the same AAA protocols. If the ISP and RSP are using different AAA protocols, CiscoSecure GRS translates the attributes.
Translation is transparent to the CiscoSecure GRS administrator and user; the applicable protocol types are simply selected during configuration. This substantially reduces administrative startup costs. The ISP's ACS perceives CiscoSecure GRS as a NAS. The RSP's NAS perceives CiscoSecure GRS as an ACS.
See Figure 1-3 for an illustration of an example network using proxy and translation.
CiscoSecure GRS uses the standard AAA protocols to communicate with the local NAS, so compatibility is ensured with any NAS that complies with these protocols:
When the RSP is using RADIUS and the remote ISP is using TACACS+, the authentication/authorization sequence shown in Figure 1-4 is followed.
By default, if the protocol dialects are the same, CiscoSecure GRS proxies all the attributes and no filtering takes place. If the protocols are different, CiscoSecure GRS translates the attributes. There are some attributes that do not have a translation or are not supported in the other protocol. If an attribute is to be filtered, it is dropped after translation or proxy. The filter feature of CiscoSecure GRS allows any TACACS+ and/or RADIUS attribute to be filtered. Currently when CiscoSecure GRS filters an attribute, it simply drops it from the attribute list.
In this manner, the owners of the NASes can control the messages sent back from the ACS to control the NAS. For example, if the ISP is assigning the RADIUS Idle-Timeout attribute to the user, the RSP may want to filter this attribute so that the NAS controls the timeout.
When the ISP assigns the IP address, the IP address is based on the NAS in to which the user dials. The ISP's access control server can assign the IP address pool name. In order to do this, the ISP's access control server must choose the IP address pool that is appropriate for the customer.
When the ISP wants to assign the IP address, the ISP's customer dials in to the RSP's NAS. The CiscoSecure GRS at the RSP proxies to the ISP as if it were a NAS. The ISP's access control server determines it is talking with the NAS. Based on the customer's username, the ISP's access control server assigns an IP address pool name. Note that the user is always assigned the same IP address pool name regardless of the NAS in to which the user dials; the IP address pool can represent a different range of IP addresses, depending on the NAS.
When CiscoSecure GRS is performing the proxy, it might range-check the value to verify that the ISP has chosen an appropriate IP address pool name. If the IP address pool name does not exist in CiscoSecure GRS, the CiscoSecure GRS denies access to the user. After authentication and authorization are performed, the NAS assigns the IP address from the specified IP address pool.
With CiscoSecure GRS, the ISP can assign the IP address. When the ISP assigns the IP address, the IP address is the same regardless of the NAS into which the user dials.
CiscoSecure GRS can range-check the IP pool name and address based on the ISP's domain. Range checking verifies that the value for a specified attribute is appropriate; if it is inappropriate, authentication fails. When authentication fails, the accounting record logs the reason for the failure.
CiscoSecure GRS can check the IP pool name assigned using the TACACS+ AV pair addr-pool and the Ascend RADIUS attribute Ascend-Assign-IP-Pool. For example, if the RSP has configured range checking for the IP pool name and allocated only the address pool "ISP-A" for ISP A, ISP A's security server cannot assign the value "ISP-B" to the attribute addr-pool (TACACS+) or Ascend-Assign-IP-Pool (RADIUS), and authorization is rejected. This can also be done when the ISP assigns a specific IP address.
To use range checking, you must define a list of acceptable values. If you do not configure a list of acceptable attributes, there will be no range checking. You must also enable range checking for the CiscoSecure GRS domain.
CiscoSecure GRS supports proxy/translation of Virtual Private Dialup Network (VPDN) requests. There are two basic types of "roaming" users: Internet and intranet. VPDN addresses the requirements of roaming intranet users. In some VPDN cases, both proxy and translation are required.
For an explanation of VPDN and tunneling features, scenarios, and sample NAS configurations, see the chapter "CiscoSecure GRS and Virtual Private Dialup Networks."
Accounting information can be stored at both the ISP's and RSP's locations and can be forwarded from one location to the other. Because the ISP might charge a customer a different rate when the customer is "roaming," CiscoSecure GRS forwards accounting information from the RSP to the ISP. Because the RSP might charge its ISP customer based on the ISP's customer's usage, CiscoSecure GRS also allows the RSP to store accounting information.
CiscoSecure GRS forwards accounting information to the local ACS that the ISP and customer can use later for billing purposes. See Figure 1-5.
When performing proxy between identical AAA protocols (TACACS+ to TACACS+ or RADIUS to RADIUS), accounting is straightforward. When performing proxy/translation between different protocols (TACACS+ to RADIUS or RADIUS to TACACS+), the accounting attributes must be translated.
The ISP can receive the accounting information from the RSP to bill a customer. The steps involved are as follows:
Step 1 Accounting packets are generated by the RSP's NAS.
Step 2 The CiscoSecure GRS at the RSP receives the packet.
Step 3 If the RSP and ISP are using different AAA protocols, the CiscoSecure GRS at the RSP translates the packet, then forwards the information to the security server at the ISP; otherwise, CiscoSecure GRS just forwards the packet.
Step 4 The ISP receives the information, logs it, then acknowledges receiving it.
The following example shows a TACACS+ accounting packet for the ISP:
grs1 mary@isp.com async0 - start server=acs1 time=06:04:46 date=10/03/97 task_id=18000088 addr=10.2.0.2
The RSP can bill the ISP based on usage. If this is the case, the ISP can get accounting information on remote users. The following example shows the format in which the RSP stores the accounting information. This example is for a TACACS+ configuration with stripping enabled.
User-Name = mary@isp.com
or
User-Name = isp.com
The format in which the accounting information is stored depends on how the Local Domain is configured. If the Local Domain is set up as TACACS+, the data format is TACACS+. If the Local Domain is set up as RADIUS, the data format is RADIUS. Accounting information is stored in the data store of the ACS that has been designated as the Local Domain. See your ACS manufacturer's documentation for more information on data storage formats.
The following example shows the information in a typical TACACS+ accounting packet:
grs1 mary@isp.com async0 - start server=acs1 time=06:06:24 date=10/03/97 task_id=18000088 addr=10.2.0.1
If you are using a RADIUS ACS for your Local Domain, the accounting packet will contain most of the same information, but will appear in standard RADIUS format.
See your CiscoSecure Access Control Server User Guide for an explanation of the fields in the accounting packet.
If you have Insert Domain AV Pair Into Local Accounting Packet enabled (see the section "Inserting a Domain AV Pair into an Accounting Packet" in the chapter "Configuring CiscoSecure GRS"), the accounting packet will resemble the following example packet:
grs1 mary async0 - start server=acs1 time=06:06:24 date=10/03/97 task_id=18000088 addr=10.2.0.1 domain=isp.com
Accounting information is extracted from the ACS using the technique described in your server documentation; for example, the CiscoSecure Access Control Server User Guide. See your server documentation for instructions.
The CiscoSecure GRS software conforms to the following specifications:
The following is a general overview of the steps to follow to use CiscoSecure GRS. See the section listed with each step for more detailed information.
Step 1 Install the CiscoSecure GRS software. See the chapter "Installing and Starting CiscoSecure GRS" for more information.
Step 2 Run the GUI. The first time you run the GUI, the Express Setup Wizard automatically starts and guides you through the steps necessary for basic CiscoSecure GRS configuration. See the chapter "Configuring CiscoSecure GRS."
Step 3 Populate the GRS data store using either the GUI or the data store utilities in the $GRSHOME/bin directory. See the section "CiscoSecure GRS Data Store Options" in the chapter "Installing and Starting CiscoSecure GRS" or the section "CiscoSecure GRS Utilities" in the chapter "Using the CiscoSecure GRS Command-Line Options and Utilities."
Step 4 Using the GUI, verify that your data is correct. Verify that your shared secrets for Domains, ACSes, and NASes are correct and that the ports used by CiscoSecure GRS match your configuration. See the chapter "Configuring CiscoSecure GRS."
Step 5 (Optional) Unless you want CiscoSecure GRS to use only the Local Domain, you must add a domain. See the chapter "Configuring CiscoSecure GRS."
Step 6 If you do not already have an ACS running and communicating with the CiscoSecure GRS, you must add and configure an ACS and make sure it can communicate with CiscoSecure GRS. See the chapter "Configuring CiscoSecure GRS" and your ACS documentation.
Step 7 Start GRS. See the chapter "Installing and Starting CiscoSecure GRS."
Step 8 (Optional) To monitor current usage, use a web browser. See the chapter "Configuring CiscoSecure GRS."
|
|