|
|
This chapter provides an introduction to the advantages and features of CiscoSecure Global Roaming Server (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 be accomplished through the command-line interface (CLI). 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 Structured Query Language (SQL) commands, because the tools automatically ensure the integrity of the relationships needed for CiscoSecure GRS to operate correctly. For more information, see "Using the CiscoSecure GRS Command-Line Interface Options and 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 store options are available with CiscoSecure GRS, a flatfile data store or an Oracle 7.3.4 database or higher. For more information on the data store options, see the "CiscoSecure GRS Data Store Options" section.
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 "Configurable Prefix and Suffix Delimiters" section, 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. For more information, see the "start_grs" section.
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 points of presence (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.
There are no username format requirements for DNIS proxy.
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.
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:
Figure 1-4 describes the authentication/authorization sequence when the RSP is using RADIUS and the remote ISP is using TACACS+.
1. The NAS sends a RADIUS access request packet with username=mary@isp1, Service-Type=Framed, Framed-Protocol=PPP, and PAP password=secret.
2. Proxy retrieves two entries from the database: the record for isp1 and the record for NAS1. (This might be cached.)
3. Proxy decodes the password using the shared NAS1-Proxy shared secret.
4. Proxy creates a TACACS+ start packet, encodes the data, and forwards it to the TACACS+ server.
5. TACACS+ server responds with a PASSED reply and the username.
6. Proxy sends the authorization attribute-value (AV) pairs to the TACACS+ server.
7. TACACS+ server authorizes the services.
8. Proxy sends an Access-Accept with the authorized AV pairs to NAS1.
After receiving an authorization packet from an access control server (ACS), CiscoSecure GRS can add, modify, or filter an authorization attribute before the authorization is sent to the NAS. The filtering of attributes can be based on domain and DNIS. Furthermore, all Cisco and vendor-specific attributes for RADIUS 11.3(2) or higher are supported. Also, some IETF attributes and nonvendor-specific Ascend attributes are supported.
When performing same-vendor RADIUS-to-RADIUS proxy, CiscoSecure GRS can pass-through authorization Attribute 26, an attribute specific to your organization. The attribute can also be filtered based on a specific domain and DNIS.
CiscoSecure GRS can translate the IP address 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 translation for the IP address 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.
If an ISP's ACS can assign IP address pool names, the ISP's ACS must be configured to assign 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 ACS determines it is talking with the NAS. Based on the customer's username, the ISP's ACS assigns an IP address pool name.
When CiscoSecure GRS is performing the proxy, it might 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 have been 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 address pool based on the ISP's domain. Range checking verifies that the IP address is appropriate; if it is inappropriate, authentication fails. When authentication fails, the accounting record logs the reason for the failure.
To use range checking, you must define a list of acceptable values. If you do not configure a list of acceptable values, 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 Dial-Up 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 "CiscoSecure GRS and Virtual Private Dial-Up Networks."
CiscoSecure GRS forwards accounting information to the local ACS that the ISP and customer can use later for billing purposes. The accounting process is illustrated in 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 as follows:
1. Accounting packets are generated by the RSP's NAS.
2. The CiscoSecure GRS at the RSP receives the packet.
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.
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 ACS 2.3 for UNIX 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 "Domain Type" section), 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 ACS 2.3 for UNIX 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 "Installing and Starting CiscoSecure GRS.")
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 "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 "CiscoSecure GRS Data Store Options" section, or the "CiscoSecure GRS Utilities" section.)
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 "Configuring CiscoSecure GRS.")
Step 5 (Optional) Unless you want CiscoSecure GRS to use only the local domain, you must add a domain. (See "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 "Configuring CiscoSecure GRS" and your ACS documentation.)
Step 7 Start GRS. (See "Installing and Starting CiscoSecure GRS.")
Step 8 (Optional) To monitor current usage, use a web browser. (See "Configuring CiscoSecure GRS.")
Posted: Wed Feb 24 12:11:25 PST 1999
Copyright 1989-1999©Cisco Systems Inc.