|
|
CiscoSecure ACS 2.0 for Windows NT is network security software that helps you authenticate users by controlling dial-in access to a Cisco network access server (NAS). The CiscoSecure access control server (ACS) operates as a Windows NT service and controls the authentication, authorization, and accounting of users accessing networks.
The CiscoSecure ACS supports the centralization of access control and accounting for dial-up access servers and firewalls as well as management of access to routers and switches. With it, service providers can quickly administer accounts and globally change levels of service offerings for entire groups of users. This improves service providers' ability to deliver wholesale dial-up services to corporations investing in the outsourcing of dial-up and networking services. Because of its tight integration with the Windows NT operating system, companies may leverage the working knowledge as well as the investment already made into building a Window NT network.
The CiscoSecure ACS supports different Cisco NASes (such as the Cisco 2509, 2511, 3620, 3640, and AS5200) and the PIX firewall. It is an ACS for Windows NT Server Version 4.0. CiscoSecure uses the Terminal Access Controller Access Control System (TACACS+) and Remote Access Dial-In User Service (RADIUS) protocols to provide Authentication, Authorization, and Accounting (AAA) to ensure a secure environment. CiscoSecure can authenticate users against either the Windows NT User Database, the CiscoSecure User Database, or a token card server's database.
The NAS directs all dial-in user access requests to the CiscoSecure ACS for authentication and authorization of privileges. Using either the RADIUS or TACACS+ protocol, the NAS sends authentication requests to the CiscoSecure server, which verifies the username and password. The CiscoSecure server then returns a success or failure response to the NAS, which permits or denies user access. When the user has been authenticated, CiscoSecure sends a set of authorization attributes to the NAS, and the accounting functions take affect.
This section describes the CiscoSecure ACS 2.0 for Windows NT features:
Access Control Servers (ACSes) are used to determine who can access the network and what services are authorized for each user. The ACS stores a profile containing authentication and authorization information for each user. Authentication information validates their identity, and authorization information determines what they can access.
An ACS can be used simultaneously with dial-up access servers, routers and firewalls. Each network device can be configured to communicate with an ACS. This makes it possible to centrally provision and control dial-up access for a service provider as well as secure corporate network devices from unauthorized access. Both applications have unique authentication and authorization requirements. With a CiscoSecure ACS, system administrators may use a variety of authentication methods that are used with different degrees of authorization privileges.
Completing the access control functionality, the CiscoSecure ACS serves as a central repository for accounting information. Each user session that is granted by the ACS can be fully accounted for and stored in the server. This accounting information can be used for billing, capacity planning and security audits.
ACS functions are divided into three categories; authentication, authorization and accounting. Each of these are described in detail in the following section.
Authentication determines a user's identity, and then it verifies that information. Authentication can take many forms. Traditional authentication uses a name and a fixed password. More modern and secure methods use One Time Passwords (OTPs) such as CHAP and token cards. CiscoSecure provides support for these authentication methods.
A fundamental relationship between authentication and authorization is that the more authorization privileges a user receives, the stronger the authentication should be. The CiscoSecure ACS offers this capability by providing several different methods of authentication.
Username and password is the most popular, simplest, and least expensive method used for authentication. This fits under the category of "something you know." No special equipment is required. This is a popular method for service providers due to its easy application by the client. The disadvantage is that what you know can be told to someone else, guessed, or captured. Username and password is not considered a strong authentication mechanism; therefore, you would use it for low authorization or privilege level such as Internet access, it can be sufficient.
One can reduce the risk of password capturing on the network by using encryption. Client and server access control protocols, such as Terminal Access Controller Access Control System (TACACS+) and Remote Authentication Dial-In User Service (RADIUS) encrypt passwords to prevent them from being captured within a network. However, TACACS+ and RADIUS operate between the NAS and the ACS. Clear-text passwords can be captured between a client host dialing up over a phone line or an Integrated Service Digital Network (ISDN) line terminating at a NAS.
Service providers offering increased levels of security services and corporate customers who want to lessen the chance of intruder access resulting from password capturing, can use an OTP. The CiscoSecure ACS supports several types of OTP solutions including CHAP for Point-to-Point Protocol (PPP) remote-node logon. Token cards are considered one of the strongest OTP authentication mechanisms available today. With token cards, authentication requires something you have and something you know, and it results in an OTP that prevents password captures.
The CiscoSecure ACS currently supports two different token card manufacturers including Security Dynamics, Inc. (SDI) and Axent. The CiscoSecure ACS embeds the clients for SDI's ACE server so that it will call the server when their token card authentication solution is required. The Axent authentication server is configured with the CiscoSecure ACS with an address and shared secret.
Authorization determines what a user is allowed to do. The CiscoSecure ACS can send user profile policies to a network device such as an access server to determine the network services they can access or the level of service subscribed to. You can configure authorization to give different users and groups different levels of service. For example, standard dial-up users might not have the same access privileges as premium customers and users. You can also differentiate by levels of security, access times, and services.
One of the fastest growing services being offered by service providers, and adopted by corporations is a service authorization for Virtual Private Networks (VPNs). The CiscoSecure ACS can provide information to the network device for a specific user to configure a secure tunnel through a public network such as the Internet. The information may be for the access server (such as the Home Gateway for that user) or for the Home Gateway router to validate the user at the customer premise. In either case, a CiscoSecure ACS can be used for each end of the VPN.
The CiscoSecure ACS can permit or deny login based on time-of-day and day-of-week. For example, you could create a group for temporary accounts that can be set up to be disable on specified dates. This would make it possible for a service provider to offer a 30-day free trial. The same authorization could be used to create a temporary account for a consultant with login permission limited to Monday through Friday, 9 a.m. to 5 p.m.
You can restrict users to any one or a combination of PPP, ARA, Serial Line Internet Protocol (SLIP), or EXEC services. Once a service is selected, you can restrict Layer 2 and 3 protocols, and you can apply individual access lists. Access lists on a per-user or per-group basis can restrict users from reaching parts of the network where critical information is stored. Access lists can prevent users from using certain services such as File Transfer Protocol (FTP) or Simple Network Management Protocol (SNMP).
Accounting is the action of recording what a user is doing or has done. The CiscoSecure ACS writes accounting records to a CSV log file daily. You can easily update this log file into popular database and spreadsheet applications for billing, security audits, and report generation.
The CiscoSecure ACS is designed to be modular and flexible. This enables it to fit the needs of both simple and large networks. This section describes the architectural components and the interface design.
The CiscoSecure ACS includes five service modules:
Each module can be started and stopped individually from within the Microsoft Service Control Panel or as a group from within the CiscoSecure ACS browser interface. Each module can operate independently, but this limits functionality.
CSAdmin is the service for the internal web server. The CiscoSecure ACS does not require the presence of a third party web server, it is equipped with its own internal server. After the CiscoSecure ACS is installed you must configure it from its HTML/Java interface. Therefore, to configure the CiscoSecure ACS, CSAdmin must always be running.
Although you can start and stop services from within the CiscoSecure ACS browser interface, it does not start or stop CSAdmin. If the service is stopped abnormally because of an external action, you would no longer be able to access the CiscoSecure ACS from any machines other than the Windows NT server on which it is running. You can start or stop CSAdmin from the Windows NT Service menu.
CSAdmin is designed as a multithreaded application to support environments where multiple administrators are accessing CSAdmin simultaneously. Therefore, CSAdmin is better suited for distributed, multiprocessor, and clustered environments.
Note When you access CSAdmin from a browser, a new port is assigned for that session of the browser. This was designed for security and session management purposes. This means that when a firewall wall is used in an environment with proxy services, the port <server IP address>:2002 must be excluded.
CSAuth is the service for authentication and authorization. The primary responsibility of the CiscoSecure ACS is the authentication and authorization of requests from devices to permit or deny access to a specified user. CSAuth is the service responsible for determining if access should be granted and defining the privileges associated with that user. CSAuth is the database manager.
The CiscoSecure ACS can access one of three different databases for authentication. When a request for authentication arrives, the first database the CiscoSecure ACS always solicits is its own local user database. This local user database stores information about where the authentication password is stored. When the username of the user is located, CSAuth knows which of the three databases to check.
The CiscoSecure ACS offers and option to check the Windows NT User Database for authentication for first time logins. In other words, if the username is not found in the CiscoSecure User Database, it will not yet deny authentication, it will forward the request onto Windows NT to see if Windows NT will authenticate the user. If Windows NT does, than authentication is granted as above.
In the case of using a token card server the CiscoSecure ACS manages communication, via TACACS+ or RADIUS, with device where the client is requesting to enter. Though token servers might offer some support of TACACS+ or RADIUS, that function is not being used as the CiscoSecure ACS maintains that communication. Therefore, TACACS+ or RADIUS should be disabled at the token card server.
When the authentication has occurred and been approved against one of the three methods above, a set of authorizations are obtained from the profile of the user and the group in which they are assigned. This information is stored with the username in the CiscoSecure User Database. Authorizations will include the services to which the user is entitled such as IP over PPP, IP pools to draw an IP address from, or an access control list that limits the user's access. The authorizations, with the approval of authentication, are then passed to the CSTacacs or CSRadius modules to be forwarded to the requesting device.
CSTacacs and CSRadius services communicate between the CSAuth module and the access device requesting the authentication and authorization services. For CSTacacs and CSRadius to work properly the following conditions must be met:
CSTacacs is used to communicate with TACACS+ devices and CSRadius to communicate with RADIUS devices. Both services can run at the same time. When only one security protocol is used, only the respective service needs to be running.
CSLog is the service used to capture and place logging information. CSLog gathers data from the TACACS+ or RADIUS packet and CSAuth and manipulates the data to be put into the CSV files. The CSV files are created daily starting at midnight. CSV files are stored in the default subdirectory \Program Files\CiscoSecure ACS v2.0\Logs\. There are three subdirectories located there: Audit, RadiusAccounting, and TacacsAccouting. The Audit subdirectory contains failed attempt information. The other two subdirectories contain successful authentication and authorizations for their respective protocols.
The CiscoSecure ACS interface is designed to be viewed using Microsoft Internet Explorer 3.02 and Netscape Navigator 3.0. Earlier versions do not support the frame technology used by the CiscoSecure ACS interface.
The design primarily uses HTML with some Java functions that contribute to ease of use. These design decisions keep the responsiveness of the interface high and the interface straightforward. Because of this, it is necessary to configure the browser to support Java.
The web-based interface not only makes viewing and editing user and group information possible, it also allows you to restart the service, add remote administrators, change network access server information, and view reports from anywhere on the network. These reports track connection activity, show which users are currently logged in, and list the failed authentication and authorization attempts.
To access to the CiscoSecure ACS web-based interface, enter one of the following addresses on the address line of a browser:
From the browser on the server the CiscoSecure ACS is installed:
From a browser on a workstation*:
Note You must configure an administrators username and password in the CiscoSecure ACS to access the interface from a machine other than then the local Windows NT Server.
The layout of the screens are broken down into three vertical sections.
Note At the bottom of each section, a submit button is positioned to accept the changes defined in this area. If the submit button isn't selected, the changes are not kept.
The overriding methodology of the interface is centered on ease of use. The intricate concepts of network security are presented from a user-centered perspective. This section describes implicit and explicit relationships among the different components that comprise network security.
To keep the CiscoSecure ACS easy to use, it was important that it had a similar relationship between a user and the group to which the user belongs. In doing this, it was necessary to "flatten out" the hierarchical nature of TACACS+. TACACS+ supports the concept of users belong to groups that belong to other groups and so on. This wasn't an issue for RADIUS as it doesn't offer that ability. The Windows NT user-group relationship is not hierarchical. The CiscoSecure ACS has adopted a one-level, user-to-group relationship.
A user belongs to one group. Some parameters are configurable at the user level, such as static IP address, password and expiration. However, the majority of the TACACS+ and RADIUS attributes are configured at the group level. This methodology was adopted for two reasons. First is performance. To maximize performance (transactions per second), user and group information should be cached in RAM. To prevent the product requirements of RAM from being un-reasonable, storage of every possible user attribute is not optimal. Furthermore, configuring every parameter at the user level also doesn't scale when there are a large number of users in the database. Therefore, the CiscoSecure ACS makes available typical user configurable parameters at the user level, and the remainder at the group level. This balances scalability and performance with user configurable granularity. Should a specific user have a non-typical configuration requirement, they can also be a single member of a group with all of their own, unique settings.
To maintain ease of use and robust functionality, the default configuration options under Group Setup support the most common applications of the product. The entire itemization of every TACACS+ and RADIUS attribute is not listed. Within the CiscoSecure ACS, there is an option to select from a list, those attributes that should be displayed (make available to configure) under the Group Setup screens. This means it is possible to configure the configuration screens. Therefore, if an attribute is desired but not listed under Group Setup, or there are default options under Group Setup that are not used, attributes can be displayed or hidden to best fit the application.
In line with the selection of attributes in Group Setup, it is possible to introduce the ability to control the usage of each TACACS+ Service by the time-of-day and day-of-week. An example would be that PPP-Exec (telnet) access would be restricted to business hours, but PPP-IP access would be permitted all week long.
The default setting for Group Setup is that time of day access can be controlled for all services as part of authentication. However, it is possible to display a time of day access grid for every service and override the default. This contributes to keeping the Group Setup easy to manage, while making the function available for the most sophisticated environments.
This is limited to TACACS+ as it has the ability to separate the processes of authentication and authorization. RADIUS time-of-day access is for all services. If both TACACS+ and RADIUS are being used simultaneously, the default time-of-day access applies to both. This provides a common method to control access regardless of the access control protocol.
The CiscoSecure ACS can also display a custom command field for each service. This free-form text field makes it possible to make specialized configurations that will be downloaded for a particular service for users in a particular group. An example would be the ability to define an Access Control List (ACL) at the ACS. The IP addresses that a user of a group would be limited to would be downloaded to the access device at the time of authentication and authorization. Once no users of that group access are used by that access device, the ACL would be eliminated until a user of that group accessed the device again.
This feature isn't limited just to ACLs, it can be used to send many TACACS+ commands to the access device for that service, provided the device supported the command and the command's syntax was entered properly. This feature is disabled by default, but can be easily enabled in the same manner as the attributes and time-of-day access.
The CiscoSecure ACS can simultaneously communicate with different access devices with one of 4 different protocol selections. When adding or configuring a NAS, a pull down menu with four choices appears: TACACS+, RADIUS (IETF), RADIUS (Cisco) and RADIUS (Ascend). the CiscoSecure ACS can communicate with a NAS with any of these choices. TACACS+ and RADIUS (IETF) are the protocols with attributes defined by the IETF. RADIUS (Cisco) is the RADIUS (IETF) support plus IETF attribute 26, the Vendor Specific Attribute (VSA) for Cisco. It is under the VSA that any TACACS+ command can be sent to an access device through RADIUS. RADIUS (Ascend) is the RADIUS (IETF) support plus the Ascend proprietary attributes. Note that some of the proprietary attributes conflict with the IETF attributes. When selected, the proprietary attributes prevail.
This section describes some of the different components that work together with the CiscoSecure ACS to provide network security.
The access device (NAS, firewall or router) is configured to direct all user access requests to the CiscoSecure ACS for authentication and authorization of privileges. Using the TACACS+ or RADIUS protocol, the access device sends authentication requests to the CiscoSecure ACS 2.0, which verifies the username and password either against the Windows NT User Database or the CiscoSecure ACS User Database. The CiscoSecure ACS then returns a success or failure response to the NAS, which permits or denies user access.
When the user has been successfully authenticated, a set of session attributes can be sent to the access device to provide additional security and control of privileges. These attributes can include the IP address pool to pull from, and access control list and the type of connection (for example, IP, IPX, or Telnet).
Both TACACS+ and RADIUS security protocols can be used by the CiscoSecure ACS.
Different levels of security can be used with the CiscoSecure ACS for different requirements. The basic level of user to network security is PAP. Though it doesn't represent the highest form of encrypted security, it does offer convenience and simplicity for the client. When using the Windows NT User Database, PAP is used and allows authentication against that database. By using PAP and the Windows NT User Database, single login may be achieved. A higher level of security for encrypting passwords when communication from the a client to the network device such as an access server is CHAP. This can be used when using the CiscoSecure User Database. To support Apple clients, ARA support is included in the product.
PAP and CHAP are both authentication protocols used to encrypt passwords. However, each provides a different level of security.
PAP—Uses clear-text passwords and is the least sophisticated authentication protocol. Authenticating users against the Windows NT User Database only allows password encryption using PAP.
CHAP—Uses a challenge-response mechanism with one-way encryption on the response. It allows the CiscoSecure ACS to negotiate downward from the most secure to the least secure encryption mechanism, and it protects passwords transmitted in the process. If you are using the CiscoSecure User Database for authentication, you can use either PAP or CHAP.
CiscoSecure ACS 2.0 for Windows NT supports all of the leading authentication protocols:
There are several ways in which passwords can be processed using these protocols based on the version and type of security control protocol used and the configuration of the NAS and client. The following sections outline the different conditions and functions of the password handling.
The CiscoSecure ACS supports two distinct types of passwords:
If you want to use outbound passwords and maintain the highest level of security, it is recommended that you configure the CiscoSecure ACS with a separate outbound password that is different from the inbound password. For more information refer to the section Advanced Password Configurations.
There are four basic password configurations that the majority of users will adopt:
In addition to the four basic password configurations given above, the CiscoSecure ACS also provides for:
When using CHAP and ARAP authentication with a NAS configured to use TACACS+ with Cisco IOS Release 11.1, authentication is performed by the NAS and not by the CiscoSecure ACS TACACS+ server. This results in the CiscoSecure ACS giving a password back to the NAS.
A NAS running Cisco IOS Release 11.1 generates TACACS+ SENDPASS requests in order to service a CHAP or ARAP authentication. The TACACS+ server replies with either the single ASCII PAP, CHAP, ARAP, or separate CHAP and ARAP password, depending on how the user has been configured.
You can select the Windows NT User Database or the CiscoSecure User Database to authenticate usernames and passwords according to your network requirements. This section contrasts the advantages and limitations of each option.
CiscoSecure ACS 2.0 for Windows NT can be configured to authenticate usernames and passwords against those usernames and passwords already configured in the Windows NT User Database. This means that in organizations where a substantial Windows NT User Database already exists, the CiscoSecure ACS can leverage the work already invested in building that database without any added intervention by the system administrator. This eliminates the need to build two separate databases.
The pairing of the CiscoSecure User Database and the Windows NT User Databases results in convenient administration of network security. The access device presents the username to the CiscoSecure ACS. The CiscoSecure ACS searches in its own database to locate a match. If a match is not found, and the CiscoSecure ACS has been configured to check the Windows NT User Database for usernames not found, then the username and password is forwarded to Windows NT for authentication against the usernames and passwords residing in the Windows NT User Database. If a match is confirmed, the username (not password) is stored in the CiscoSecure User Database for future authentication requests. This enables all future authentication's by this user to occur much faster because the CiscoSecure ACS goes directly to the Windows NT User Database for authentication. When this new user is added to the CiscoSecure User Database, the user setup is automatically configured to use the Windows NT User Database (the default database for new users) for password authentication, and to assign the user to the group specified as Windows NT Users.
The authorization privileges assigned to the Windows NT Users group are then assigned to the user just authenticated. The system administrator can then choose to reassign this user to another group should privilege levels be required that differ from those in the default Windows NT Users group.
For administrators that desire to further control access by user from within the Windows NT User Manager, the CiscoSecure ACS can be configured to also check the setting for "Grant dial-in permission". If the user has this parameter disabled, access will not be permitted regardless of correct username and password entry.
An added benefit of using the Windows NT User Database is the same username and password used for authentication is the same used for network login. As such, you can require users to enter their username and password once, for the convenience of a simple, single login.
However, authenticating against the Windows NT User Database does not allow the storage of third-party passwords for added levels of security (for example, CHAP). Therefore, if security is a more important consideration than the benefits of leveraging the Windows NT User Database, you should use the CiscoSecure User Database.
The NAS searches the CiscoSecure User Database for the user requesting access. If a match is not found, and the CiscoSecure ACS has not been configured to "Check NT User Database for usernames not found," the user is not authenticated. However, if a match is found, then the user is authenticated and assumes the authorization privileges of the group to which the user is assigned. (See Figure 1-2.)
The CiscoSecure ACS uses a built-in database that is a hash-indexed flat file. This type of file is not searched from the top of a text file as typically associated with the term flat file, but instead is indexed like a database. The hash-indexed flat file builds an index and tree structure so searches can occur exponentially rather than in a linear fashion, which enables the CiscoSecure User Database to rapidly authenticate users.
Using the CiscoSecure User Database requires you need to manually enter the usernames. However, after the names exist in the CiscoSecure User Database, administration is easier than using the Windows NT User Database.
The CiscoSecure User Database supports authentication for both PAP and CHAP.
Note Although using the CiscoSecure User Database does not permit a single login like the Windows NT User Database, it does increase the level of network security.
For an increased level of security, many networks desire the requirement of a token card for One Time Password (OTP) authentication. The use of the token card requires a user to posses a token card or soft token algorithm and know a password to enable the token. This concept is also described has "something you have and something you know". This represents one of the highest, commercially available, security methods of authentication.
The CiscoSecure ACS has the ability to act as a client to the token card server. To accomplish this, the CiscoSecure ACS is setup with a secured communication link to the token card server. This is done by either configuring a shared secret between the two servers and defining the IP address, or by installing a file created by the token card server into the CiscoSecure ACS containing the same information. Both the CiscoSecure ACS and the token server maintain its own database of users. From an administrative standpoint, it makes the most sense to use a third party database and import the list of users into both the CiscoSecure ACS and token card servers.
Requests from the access device are first sent to the CiscoSecure ACS. If the username is found and has been configured to authenticate against a token card server, the authentication request is forwarded accordingly. If the request for authentication returns a pass, then he appropriate authorizations are then forwarded with the approved authentication to the access device. The CiscoSecure ACS then maintains the accounting information.
CiscoSecure ACS 2.0 for Windows NT supports Security Dynamics and Axent token card servers. These token card servers are not included with the CiscoSecure ACS, they are purchased separately. When using the Security Dynamics token card server, both PPP (ISDN and async) and telnet are supported. Additionally, token caching for ISDN terminal adapters is supported by the CiscoSecure ACS. The Axent token server support only includes telnet over async, not PPP with ISDN.
One convenience feature for the support of using ISDN Terminal Adapters (TAs) is a feature called token caching. One of the inconveniences in using token cards for OTP authentication with ISDN is that each B channel requires their own OTP. Therefore, at a minimum, a user will have to enter two one time passwords plus any other login passwords such as Windows NT networking. If the TA supports the ability to turn on and off the second B channel, a user could find themselves entering many OTPs each time the second B channel came into service.
To help make the OTPs a bit easier for users to deal with, the ability to cache the token was created. This means that if a token card is being used to authenticate a user on the first B channel, a specified period can be set in which the second B channel can come into service without having to enter another OTP. Of course, this somewhat defeats the purpose of a one time password. To lessen the risk of the second B channel from being hi-jacked, the duration of time the second B channel can be limited. Furthermore, the second B channel can be configured to use the CHAP password entered during the first login to further lessen the chance of a security problem. Once the first B channel is dropped, the cached token is erased.
The CiscoSecure ACS acts as a client to the token card server. A secured communication link is required between the CiscoSecure ACS and the token card server. This is done by either configuring a shared secret between the two servers and defining the IP address, or by installing a file created by the token card server containing the same information into the CiscoSecure ACS.
The CiscoSecure ACS and the token card server maintain their own database of users. A third-party database list of users can be imported for use in both the CiscoSecure ACS and token card servers. This is the most efficient method for user administration.
User login requests are first sent to the CiscoSecure ACS. If the username is found and has been configured to authenticate against a token card server, the authentication request is forwarded to the token card server. With a successful login, the token card server sends the associated authorizations to the router or other access device. The CiscoSecure ACS then maintains the accounting information.
CiscoSecure ACS 2.0 for Windows NT supports Security Dynamics and Axent token card servers. These token card servers are not included with the CiscoSecure ACS, you must purchase them separately.
This section gives a brief overview of essential Windows NT concepts that relate to the CiscoSecure ACS as a service of Windows NT.
Before using the Windows NT User Database for authentication:
All of the CiscoSecure ACS services can be started, stopped, and restarted from the Services window. The CiscoSecure ACS services are proceeded by the letters CS. The sorting mechanism within Windows NT Services lists services alphabetically. All the CiscoSecure ACS services should be displayed in one area of the list.
The Windows NT Registry is a storage area for all application information in a tree-like structure. We recommend that you do not modify this file unless you have enough knowledge and experience to edit the file without destroying any existing data in the file.
The CiscoSecure ACS information is located in the HKEY_LOCAL_MACHINE file under SOFTWARE under Cisco. Items that can be changed within the registry are located in the Setup folder.
After the CiscoSecure ACS has been installed, you configure and manage it through the web-based GUI. The GUI is designed using frames, so you must view it with either Microsoft Internet Explorer 3.02 or Netscape Navigator 3.0.1. The web-based interface allows you to easily modify the authentication and authorization parameters of any user or group in the CiscoSecure ACS from any connection on your LAN or WAN.
The web-based interface allows you to:
The interface constantly displays a help screen of specific information and, if more extensive information is needed, clicking More Detailed Help will take you to the relevant point in the documentation.
Access the CiscoSecure web-based GUI by entering one of the following addresses on the address line of your browser:
From a browser on a workstation connected to your network:
Note You must have a username and password entry in the CiscoSecure Administrator Database if you want to connect to the CiscoSecure ACS interface from a LAN connection or a dial-up connection.
The CiscoSecure ACS has a built-in web server for support using an HTML interface. This eliminates the necessity of installing another web server on the Windows NT server running the CiscoSecure ACS. Because the CiscoSecure ACS web server uses port 2002, you can use another web server on the same machine to provide other web services.
Posted: Tue Jan 21 03:44:46 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.