|
Table Of Contents
Overview of Cisco Secure ACS for UNIX
Overview of Cisco Secure ACS for Windows
Network Access Server Configuration
Additional Profile Differences
Technology Bulletin
Feature Comparison: Cisco Secure ACS for Windows Compared to Cisco Secure ACS for UNIX
Introduction
Cisco Secure ACS for UNIX Version 1.0 was introduced in 1992. The original version supported the Terminal Access Controller Access Control System Plus (TACACS+) only. Cisco Secure ACS for Windows was originally released as EasyACS in 1997. This version, too, supported TACACS+ only. Cisco Secure ACS v2.0 for UNIX and the newly renamed CiscoSecure ACS 2.0 for Windows NT added support for Remote Authentication Dial-In User Service (RADIUS). Though similar in functionality, each product proceeded along its own line of development with different development teams. In 2000, support for Cisco Secure ACS for Windows was acquired by the Enterprise Management Business Unit (EMBU) as part of the enterprise management suite. Because Cisco Systems now has three authentication, authorization, and accounting (AAA) products (including UNIX-based Cisco Access Registrar for the service provider market), the decision has been made to discontinue Cisco Secure ACS for UNIX in 2003.
This bulletin will compare the overall feature sets of both platforms, as well as examine the advantages and disadvantages of Cisco Secure ACS for Windows and Cisco Secure ACS for UNIX and discuss issues related to migrating from the UNIX-based product to the Windows version.
Overview of Cisco Secure ACS for UNIX
Cisco Secure ACS for UNIX runs on a Sun Solaris platform. For administration, it supports both an HTML and Java graphical user interface (GUI) and a command-line interface, both of which can be used remotely. It offers most of the standard AAA functions with perhaps proxy support and Extensible Authentication Protocol (EAP) 802.1x support being the only major omissions. For storage of configuration information, Cisco Secure ACS for UNIX can support the following databases: Sybase SQLAnywhere, Sybase Enterprise, and Oracle Enterprise. (A no-charge SQLAnywhere database is included with the Cisco Secure ACS for UNIX license and is limited to a 5000-user database.) Most large-scale customers prefer to use the Oracle and Sybase Enterprise database platforms to provide replication and fault-tolerance functionality.
Overview of Cisco Secure ACS for Windows
Cisco Secure ACS for Windows runs on a Windows 2000 server platform.1 Future versions will also be appliance-based and will provide a choice between running the product as a software server or as a dedicated appliance with no visibility of the underlying operating system. Cisco Secure ACS for Windows is similar to Cisco Secure ACS for UNIX in that it uses a Web-based front end, but its feature set differs greatly. Where the Cisco Secure ACS for UNIX GUI is protocol-oriented, requiring the user to have a detailed understanding of the AAA protocols, the Cisco Secure ACS for Windows GUI attempts to reduce the user's level of AAA knowledge by providing more detailed menus with easy access to help information.
Direct Comparison
Providing a feature-by-feature comparison of the two products is difficult because their layouts differ, primarily as a result of the differences between the operating systems on which each product was developed. Another difficulty is that the two products were developed by separate teams, at different times, using different philosophies. Nevertheless, this bulletin attempts to provide a one-to-one comparison, given the constraints of each application's organization.
Network Access Server Configuration
Table 1 compares the two products' network-access-server configurations.
Figures 1 and 2 show how TACACS+ network access servers are configured on Cisco Secure ACS for UNIX. Figure 3 shows the RADIUS network access server configuration window under the advanced GUI. Compare this to Cisco Secure ACS for Windows in figures 4 through 6. Figure 4 shows the different network device groups that have been configured. Figure 5 shows the network access servers in the network device group. Figure 6 shows the configuration window for the individual network access server.
Figure 1—Cisco Secure ACS for UNIX Network Access Server Selection Window (TACACS+)
Figure 2—Cisco Secure ACS for UNIX Network Access Server Configuration Window (TACACS+)
Figure 3—Cisco Secure ACS for UNIX Network Access Server Configuration Window (RADIUS)
Figure 4—Cisco Secure ACS for Windows Network Device Group Selection Window
Figure 5—Cisco Secure ACS for Windows Network Access Server Selection Window
Figure 6—Cisco Secure ACS for Windows Network Access Server Configuration Window
User and Group Administration
Table 2 compares how user and group administration differs between the two products.
The two products differ significantly in how each supports user, group, administrator, and unknown-user configurations.
Users
Both products support single-user configuration. That is, only one username may be configured in the server. In Cisco Secure ACS for UNIX, the administrator may configure TACACS+ either through member administration (Figure 7) or by using the advanced GUI (Figure 8). For RADIUS configuration, Cisco Secure ACS for UNIX is limited to the advanced GUI. By contrast, Cisco Secure ACS for Windows does all configuration for a single user in one window (Figure 9).
Figure 7—Cisco Secure ACS for UNIX User Configuration Window (GUI)
Figure 8—Cisco Secure ACS for UNIX User Configuration Window (Advanced GUI)
Figure 9—Cisco Secure ACS for Windows User Configuration Window
Another difference is that in Cisco Secure ACS for UNIX, the administrator first selects the group that the user will be in and then adds the user. In Cisco Secure ACS for Windows, the administrator adds the user and then selects the group from within the user configuration.
Migration issue: Where mapping is compatible, no problem exists. Group membership is to the lowest group in the nesting. Password differences may cause problems.
Groups
Cisco Secure ACS for UNIX supports group nesting and group inheritance. Figure 10 provides an example:
Figure 10—Group Nesting in Cisco Secure ACS for UNIX
In this example, everyone is in group 1. All group 1 attributes will be given to each user. Larry belongs only to group 1 and is limited to those attributes unless an attribute found in larry's configuration is the same type as in group 1, in which case larry's configuration overrides group 1. Sue is a member of group 1.1. Group 1.1 is a member of group 1 and will inherit group 1 attributes. As in larry's case, any attributes in group 1.1 that are the same type as in group 1 will override the supergroup configuration. This applies to all users and groups. Therefore, bob, a member of group 1.2.1, inherits group 1, group 1.2, and group 1.2.1, unless specific configurations override the upper-level configurations.
Cisco Secure ACS for UNIX is not limited to the number of groups that can be configured except as specified by the database. SQLAnywhere, which is supplied with Cisco Secure ACS for UNIX, is limited to 5000 users, groups, and network access servers.
Cisco Secure ACS for Windows does not support group nesting. The file structure allows for only a flat database. Additionally, the application has a fixed number of groups—500—that can be configured.
Administrators
Cisco Secure ACS for UNIX and Cisco Secure ACS for Windows differ greatly in how administrators are configured.
With Cisco Secure ACS for UNIX, administrators and users are configured by the same method. In Figure 11 there is a group called administrator and there is a user, superuser. Superuser can be configured for network access, as well as for administrative functions.
In Cisco Secure ACS for Windows, administrators are configured in a separate location (Figure 15). If network access is required for an administrator, the administrator requires a separate configuration for TACACS and RADIUS.
Figure 11—Superuser in Advanced GUI
Figure 12—Adding an Administrator in Cisco Secure ACS for UNIX
Figure 13—Cisco Secure ACS for UNIX Web Privilege Selection Pull-Down Menu
Figure 14—GrpLd1 in the Cisco Secure ACS for UNIX Advanced GUI
Figure 15—Cisco Secure ACS for Windows Administrator Configuration Window
Unknown User Configuration
To allow instant integration with an existing authentication system, Cisco Secure ACS for UNIX has an unknown_user profile. This profile is used if the system fails to find the user in the database. This profile can be set up so that its password type is one of the external authentication databases, such as SDI or UNIX. This allows Cisco Secure ACS for UNIX just to manage the authorization and accounting for the user. For example, an unknown_user profile with password type set to system means that any unknown users with a valid UNIX username and password can be authenticated. This user profile is created by default and is configured in the same manner as a conventional user.
Figure 16 shows the default configuration in the Cisco Secure ACS for UNIX GUI, and Figure 17 shows it in the advanced GUI. Note that the unknown_user is not associated to a group by default. No attempt is made to remember an unknown user after authentication; no duplication occurs between the external authenticator and Cisco Secure ACS for UNIX. Thus when a user is removed from the external authenticator, he or she will no longer be able to log in. As a result, Cisco Secure ACS for UNIX cannot provide dynamic group placement, as does Cisco Secure ACS for Windows.
Figure 16—Unknown_user in the Cisco Secure ACS for UNIX User Configuration Window
Figure 17—Unknown_user in the Cisco Secure ACS for UNIX Advanced Configuration Window
Cisco Secure ACS for Windows also understands the concept of the unknown user. The application differs from Cisco Secure ACS for UNIX in that the unknown user is not configured as a conventional user. In Cisco Secure ACS for Windows, the unknown user is configured in the external databases section (Figure 18) because external database authentication is required to verify an unknown user. On receipt of an authentication request where the user is currently unknown, Cisco Secure ACS for Windows can hunt for the user in a set of configured third-party authenticators. When located and authenticated, the user is then automatically placed into the internal database with the correct password type, and the user is now known; future authentications are directed immediately to the correct authenticator. The user's group membership is then either determined based on group membership in the external authenticator or a simple static mapping for a particular type of authenticator (SDI, Axent, etc.). The resulting group then provides nearly all of the user's initial authorization information. When known to the Cisco Secure ACS for Windows application, the user is treated as if the user's data were inserted by hand and configured to use an external authenticator.
Figure 18—Cisco Secure ACS for Windows External Databases
Additional Profile Differences
Attribute Fields
In Cisco Secure ACS for Windows, the administrator selects which attribute fields will be visible for group and user profiles. These attribute fields are then applied to all groups and users (Figure 19), whether or not the field will be applied to a particular group or user. However, this does prevent the administrator from having to "look around" to find the attributes that require configuration.
In Cisco Secure ACS for UNIX, attribute fields are selected as required from menus (Figure 20). The administrator must know which fields are available because no list of available fields or their locations exists.
Figure 19—Cisco Secure ACS for Windows Interface Configuration Window
Figure 20—Cisco Secure ACS for UNIX Attributes in the Options Menu
Profile Duplication
In Cisco Secure ACS for UNIX, the administrator can copy the attributes from one profile to another. Cisco Secure ACS for Windows does not allow this procedure.
Passwords
In Cisco Secure ACS for UNIX, different passwords can be set for each of the available password types. Additionally, passwords can be set at the group level. In Cisco Secure ACS for Windows, passwords can be set only at the user configuration; the application supports different passwords only for PAP (cleartext) and for CHAP, MS-CHAP, and ARAP (hashed).
In Cisco Secure ACS for UNIX, at least one password type must be defined for a user. If multiple password types are defined, then the appropriate one will be selected based on the nature of the authentication request. Associated with each password is an optional date range. This date range defines the period when the password is valid. Not to be confused with time-of-day access, this feature defines a date range (day resolution) when the password is valid. With the ability to define multiple passwords for a user or group Cisco Secure ACS for UNIX deploys the following mechanism to determine which defined password type to use for authentication (Table 3). This processing depends on the AAA protocol being used and the contents of the request packet.
Note:
When a password type is found, no further password types are checked.
Cisco Secure ACS for Windows can be configured to use privately defined passwords or can be integrated with an existing authentication service. Up to two privately defined passwords can be defined for each user: the first one being used for all plaintext authentications and the second being used for CHAP, MS-CHAP, and ARAP authentications. If a second password is not defined, then the first password is used for all authentications. When selecting an external authenticator for the primary password, the secondary password will be used only if the external authenticator cannot perform CHAP, MS-CHAP, or ARAP authentication.
Table 4 indicates the current set of external authenticators.
Command Authorization
You can use TACACS+ to provide command filtering for the administration of Cisco routers, switches, and other devices that support this feature. Cisco Secure ACS for UNIX supports this feature by allowing you to define a set of commands, which are either permitted or denied, along with a list of permitted-and-denied arguments for each command. The configuration for these command authorizations is defined inside the shell service. A command is appended in the same way as normal service authorization attributes. Each command has the properties described in Table 5.
Command filtering is configured in Cisco Secure ACS for UNIX through the advanced section. Command filters are configured within a "Service-shell" profile in either a group or user profile (Figure 21). Cisco Secure ACS for UNIX allows for a default setting for command authorization of commands not configured for a particular group or user (Figure 22). Several menus are used to configure a specific command (Figure 23). These menus cover the items found in the previous table. In the example shown, the show command is being configured for authorization filtering. The default setting is permit, and the permission for the users argument (show users) is deny. When the command authorization configuration is complete, it will show up under the service-shell profile (Figure 24). Multiple arguments may be configured for a given command (Figure 25).
Figure 21—Configuring Command Filters in Cisco Secure ACS for UNIX
Figure 22—Default Command Attribute in Cisco Secure ACS for UNIX
Figure 23—Command Authorization Configuration Menus for Cisco Secure ACS for UNIX
Figure 24—Final Command Authorization Configuration Example in Cisco Secure ACS for UNIX
Figure 25—Multiple Command Arguments Configuration Example in Cisco Secure ACS for UNIX
Cisco Secure ACS for Windows provides similar capabilities for command authorization through the TACACS+ protocol. The application adds one further refinement to command filtering: the command authorization set. Command authorization sets enhance the scalability and manageability of setting authorization restrictions.
In Cisco Secure ACS for Windows, the default command authorization sets include the shell command authorization sets and the Cisco PIX command authorization sets. Cisco device-management applications, such as the CiscoWorks Management Center for PIX Firewalls, may be enabled to instruct Cisco Secure ACS for Windows to support additional command authorization set types. Command authorization sets enhance the command filtering capability as follows:
•
•
Figure 26—Accessing Command Authorization Sets Under Shared Profile Components
Figure 27—Configuration of a Command Authorization Set
Network Access Restrictions
Network access restrictions (NARs) provide the ability to define additional authorization and authentication conditions that must be met before a user can access the network. Both Cisco Secure ACS for UNIX and Cisco Secure ACS for Windows apply these conditions using information from attributes sent by the AAA clients (or network access server). Although there are several ways to set up NARs, all are based on matching attribute information sent by an AAA client.
Cisco Secure ACS for UNIX and Cisco Secure ACS for Windows differ substantially on what can be restricted and how the operation is performed.
Cisco Secure ACS for UNIX
Cisco Secure ACS for UNIX applies NARs using either IP address or a Domain Name System (DNS) host name (derived from the IP address provided by the network access server). The best way to show how Cisco Secure ACS for UNIX applies NARs is through a configuration example:
In this example, an organization has several network access servers in the same domain with similar names:
system1a.acme.com
system1b.acme.com
system1c.acme.com
system2a.acme.com
system2b.acme.com
system2c.acme.com
etc.
It is necessary to conduct network-access-server filtering based on the host name for groups:
deny system1*.acme.com
allow *.acme.com
1.
2.
3.
4.
system1.*\.acme.comwhere you include such devices as system1a.acme.com, system1b.acme.com, etc. The ".*" is the UNIX wildcard, and the "\" protects the ".acme.com" from being wildcarded.
5.
6.
7.
When completed, the resulting profile from the ViewProfile command should look something like:
User Profile Informationuser = admin1{profile_id = 31profile_cycle = 2member = admingroup1password = clear "********"password = pap "********"privilege = web "********" 15refuse "system1.*\.acme.com" ".*" ".*"allow ".*" ".*" ".*"}To enable filtering via the host name, make sure the following line in Cisco Secure ACS for UNIX.cfg is configured:
NUMBER config_get_names_from_dns = 1;found between the lines:
NUMBER config_max_failed_authentication = 10;
NAS config_nas_config =This option is available in Cisco Secure ACS for UNIX v2.3(3) and later. Make sure that DNS is functioning properly on the Solaris system.
Figure 28—Root Profile Options Menu
Figure 29—Profile Selection for Filter Profile
Figure 30—Filter Configuration Options
Figure 31—Final Profile Configuration for Filter Profile
Cisco Secure ACS for Windows
Cisco Secure ACS for Windows provides similar capabilities for network access restrictions (NARs). The application adds a refinement to NARs: the named profile. Shared-name NARs enhance the scalability and manageability of setting access restrictions. Named NAR profiles enhance the command filtering capability as follows:
Reusable named network access restriction profiles—A named set of network access restrictions can be created without directly citing any user or group. Several profile sets can be defined, each delineating different access profiles (figures 32 and 33). As with command authorization sets, NARs can be configured at the group and user levels (Figure 34).
Figure 32—Accessing NAR Named Profiles Under Shared Profile Components
Figure 33—Named NAR Profile Configuration
Figure 34—Group-Level NAR Configuration
Security
Issues of system security have been raised regarding Windows-based servers. UNIX-based systems are reported to be more secure from external threats. This issue is discussed in the white paper Securing Cisco Secure Access Control Server Running on Microsoft Windows Platforms, which can be found at:
http://www.cisco.com/warp/public/cc/pd/sqsw/sq/prodlit/secac_wp.htm
Conclusion
Cisco offers migration tools that will help Cisco Secure ACS for UNIX customers migrate to Cisco Secure ACS for Windows. The migration tools help export configuration data from Cisco Secure ACS for UNIX into a Cisco Secure ACS for Windows application and ease the transition. More information about these tools can be obtained by contacting your product manager or technical marketing engineer. Note that the Cisco Secure ACS for UNIX migration tools will not attempt to migrate fields that are difficult to port to Cisco Secure ACS for Windows because of the inherent differences mentioned in this bulletin. For this data, manual intervention is the better option for configuring the analogous features in Cisco Secure ACS for Windows.
1 Windows NT is not supported, as of Cisco Secure ACS v3.1 for Windows.
Posted: Tue Jan 17 17:11:09 PST 2006
All contents are Copyright © 1992--2006 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
