-
Cisco ACNS Software Configuration Guide for Locally Managed Deployments, Release 5.5
-
Preface
-
Chapter 1: Introduction
-
Chapter 2: Understanding the Basics
-
Chapter 3: Deployment Scenarios for Standalone Content Engines
-
Chapter 4: Getting Started
-
Chapter 5: Performing Other Basic Tasks for Standalone Content Engines
-
Chapter 6: Configuring Transparent Redirection for Standalone Content Engines
-
Chapter 7: Configuring Conventional Caching Services for Standalone Content Engines
-
Chapter 8: Configuring RealMedia Services on Standalone Content Engines
-
Chapter 9: Configuring WMT Streaming Media Services on Standalone Content Engines
-
Chapter 10: Configuring Content Authentication and Authorization on Standalone Content Engines
-
Chapter 11: Configuring Content Preloading and URL Filtering on Standalone Content Engines
-
Chapter 12: Configuring ICAP on Standalone Content Engines
-
Chapter 13: Configuring the Rules Template on Standalone Content Engines
-
Chapter 14: Configuring Primary and Backup Proxy Servers for Standalone Content Engines
-
Chapter 15: Configuring Advanced Transparent Caching Features on Standalone Content Engines
-
Chapter 16: Updated Configuring Additional Network Interfaces and Bandwidth on Standalone Content Engines
-
Chapter 17: Configuring Administrative Login Authentication and Authorization on Standalone Content Engines
-
Chapter 18: Configuring AAA Accounting on Standalone Content Engines
-
Chapter 19: Creating and Managing IP Access Control Lists for Standalone Content Engines
-
Chapter 20: Viewing and Modifying TCP Stack Parameters on Standalone Content Engines
-
Chapter 21: Monitoring Standalone Content Engines and Transactions
-
Chapter 22: Troubleshooting
-
Appendix A: Content Engine GUI Menu Options
-
Appendix B: Reference Material for Standalone Content Engine Deployments
-
Index
-
Table Of Contents
Configuring Administrative Login Authentication and Authorization on Standalone Content Engines
Understanding Administrative Login Authentication and Authorization
Default Administrative Login Authentication and Authorization Configuration
Understanding Failover for Administrative Login Authentication
Understanding Login Authentication and Authorization Through the Local Database
Understanding RADIUS Authentication and Authorization
Understanding TACACS+ Authentication and Authorization
TACACS+ Enable Password Attribute
Configuring Administrative Login Authentication and Authorization
Specifying RADIUS Authentication Settings for Standalone Content Engines
Specifying TACACS+ Authentication Settings for Standalone Content Engines
Specifying and Enabling the Administrative Login Authentication and Authorization Scheme
Enabling and Disabling Administrative Login Authentication and Authorization Through RADIUS
Enabling and Disabling Administrative Login Authentication and Authorization Through TACACS+
Displaying the Current Administrative Authentication and Authorization Configuration
Configuring Administrative Login Authentication and Authorization on Standalone Content Engines
This chapter describes how to configure administrative login authentication and authorization support for standalone Content Engines. This chapter describes how to configure a standalone Content Engine to use the local database and external RADIUS and TACACS+ databases to process log-in requests from administrators who want to access the Content Engine for configuration, monitoring, or troubleshooting purposes.
Note
Content authentication and authorization, which controls end users' access to the requested content that is served through a standalone Content Engine, is independent of administrative login authentication and authorization for the Content Engine. For information about content authentication and authorization, see Chapter 10, "Configuring Content Authentication and Authorization on Standalone Content Engines."
For complete syntax and usage information for the CLI commands used in this chapter, see the Cisco ACNS Software Command Reference, Release 5.5 publication. For information about configuring administrative login authentication and authorization for Content Engines that are registered with a Content Distribution Manager, see the Cisco ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.5.This chapter contains the following sections:
•
•
•
Understanding Administrative Login Authentication and Authorization
Administrative login authentication and authorization is used to control administrator access rights to the Content Engine. For example, if an administrator logs in to the Content Engine with the predefined ACNS software superuser account (root administrator), the Content Engine grants that administrator the highest privilege level (level 15), which allows that administrator to perform any Content Engine administrative task during that login session. For instance, that administrator could perform any of the following administrative tasks:
•
•
•
Note
Figure 17-1 shows how an administrator can log in to the Content Engine through the console or the Content Engine GUI. To process these administrative login requests, the Content Engine checks the specified authentication database to verify the user's username and password and to determine the access rights that this particular administrator should be granted during this login session. When the Content Engine receives an administrative login request, the Content Engine can check its local database or a remote third-party database (the TACACS+ database or the RADIUS database) to verify the username with the password and to determine the access privileges of the administrator.
Figure 17-1 Authentication Databases and a Standalone Content Engine
Note
The secured Content Engine GUI is the default (https://Content_Engine_ip_address:8003). For more information, see the "Logging in to the Content Engine GUI" section on page 4-55.You can configure any combination of these authentication and authorization methods to control administrative login access to a standalone Content Engine:
•
•
•
By default, the Content Engine uses the local login authentication method as the primary method to process administrative login requests. When you enable local authentication with one or more other authentication methods, local authentication is always attempted first if the priority flags (primary, secondary, or tertiary) are not set. You cannot specify different login authentication methods for console and Telnet connections.
Default Administrative Login Authentication and Authorization Configuration
By default, the Content Engine uses the local database to obtain login authentication and authorization privileges for administrative users.
Note
Table 17-1 lists the default configuration for administrative login authentication and authorization.
You can change these defaults through the Content Engine CLI or GUI, as described in the "Configuring Administrative Login Authentication and Authorization" section.
Understanding Failover for Administrative Login Authentication
By default, Content Engines fail over to the secondary method of administrative login authentication whenever the primary administrative login authentication method fails. In the ACNS software releases prior to the ACNS 5.0.5 software releases, you were not able to change this default method of failover for administrative login authentication.
In the ACNS 5.0.5 software and later releases, you can change this default login authentication failover method. For standalone Content Engines, you can use Content Engine GUI (choose System > Authentication and check the Failover due to Server Unreachable box) or the CLI (use the authentication fail-over server-unreachable global configuration command) to enable failover due to an unreachable server.
The following example sets failover for administrative login authentication to occur only if the authentication server is unreachable. In this case, the Content Engine will only query the next authentication method if the administrative login authentication server is unreachable.
ContentEngine(config)# authentication fail-over server-unreachableContentEngine(config)#To use the login authentication failover feature, you must set TACACS+ or RADIUS as the primary login authentication method, and local as the secondary login authentication method.
If the failover due to unreachable server option is enabled, then remember the following information:
•
•
For example, if the failover due to the unreachable server option is enabled and RADIUS is set as the primary login authentication scheme and local is set as the secondary login authentication scheme, the following events occur:
•
•
•
Note
Conversely, if the failover due to unreachable server option is disabled, then the standalone Content Engine contacts the secondary authentication database regardless of the reason why the authentication failed with the primary authentication database.
If all the authentication databases are enabled for use, then all the databases are queried in the order of priority selected and based on the failover reason. If no failover reason is specified, then all the databases are queried in the order of their priority. For example, first the primary authentication database is queried, then the secondary authentication database is queried, and finally the tertiary database is queried.
The local and the remote databases (TACACS+ and RADIUS) can be enabled or disabled through the Content Engine CLI or GUI. The Content Engine verifies whether all databases are disabled and if so, sets the system to the default state (the local database is queried for authentication). (For information about this default state, see the "Default Administrative Login Authentication and Authorization Configuration" section.)
For more information on the various types of login authentication and authorization schemes, see the following sections:
•
•
•
Note
Understanding Login Authentication and Authorization Through the Local Database
Local authentication and authorization uses locally configured login and passwords to authenticate administrative login attempts. The login and passwords are local to each Content Engine and are not mapped to individual usernames.
By default, local login authentication is enabled first. You can disable local login authentication only after enabling one or more of the other administrative login authentication methods. However, when local login authentication is disabled, if you disable all other administrative login authentication methods, local login authentication is reenabled automatically.
Understanding RADIUS Authentication and Authorization
RADIUS is a client/server authentication and authorization access protocol used by a network access server (NAS) to authenticate users attempting to connect to a network device. The NAS functions as a client, passing user information to one or more RADIUS servers. The NAS permits or denies network access to a user based on the response it receives from one or more RADIUS servers. RADIUS uses the User Datagram Protocol (UDP) for transport between the RADIUS client and server.
You can configure a RADIUS key on the client and server. If you configure a key on the client, it must be the same as the one configured on the RADIUS servers. The RADIUS clients and servers use the key to encrypt all RADIUS packets transmitted. If you do not configure a RADIUS key, packets are not encrypted. The key itself is never transmitted over the network.
Note
RADIUS authentication usually occurs in these instances:
•
•
RADIUS authentication is disabled by default. You can enable RADIUS authentication and other authentication methods at the same time. You can also specify which method to use first. For more information about configuring RADIUS authentication, see the "Specifying RADIUS Authentication Settings for Standalone Content Engines" section.
Understanding TACACS+ Authentication and Authorization
TACACS+ controls access to network devices by exchanging Network Access Server (NAS) information between a network device and a centralized database to determine the identity of a user or an entity. TACACS+ is an enhanced version of TACACS, a UDP-based access-control protocol specified by RFC 1492. TACACS+ uses TCP to ensure reliable delivery and encrypt all traffic between the TACACS+ server and the TACACS+ daemon on a network device.
TACACS+ works with many authentication types, including fixed password, one-time password, and challenge-response authentication. TACACS+ authentication usually occurs in these instances:
•
•
When a user requests restricted services, TACACS+ encrypts the user password information using the MD5 encryption algorithm and adds a TACACS+ packet header. This header information identifies the packet type being sent (for example, an authentication packet), the packet sequence number, the encryption type used, and the total packet length. The TACACS+ protocol then forwards the packet to the TACACS+ server.
A TACACS+ server can provide authentication, authorization, and accounting functions. These services, while all part of TACACS+, are independent of one another, so a given TACACS+ configuration can use any or all of the three services.
When the TACACS+ server receives a packet, it does the following:
•
•
You can configure a TACACS+ key on the client and server. If you configure a key on the Content Engine, it must be the same as the one configured on the TACACS+ servers. The TACACS+ clients and servers use the key to encrypt all TACACS+ packets transmitted. If you do not configure a TACACS+ key, packets are not encrypted.
TACACS+ authentication is disabled by default. You can enable TACACS+ authentication and local authentication at the same time.
TACACS+ Enable Password Attribute
The ACNS software CLI EXEC mode is used for setting, viewing, and testing system operations. It is divided into two access levels, user and privileged. To access privileged-level EXEC mode, enter the enable EXEC command at the user access level prompt and specify a privileged EXEC password (superuser or admin-equivalent password) when prompted for a password.
In TACACS+ there is an enable password feature that allows an administrator to define a different enable password per administrative-level user. If an administrative-level user logs in to the Content Engine with a normal-level user account (privilege level of 0) instead of an admin or admin-equivalent user account (privilege level of 15), that user must enter the admin password in order to access privileged-level EXEC mode. This requirement applies even if ACNS users are using TACACS+ for login authentication.
ContentEngine> enablePassword:
When using TACACS+ with ACNS, the maximum length for a password is 31 characters.
Configuring Administrative Login Authentication and Authorization
This section describes how to configure login authentication and authorization for ACNS administrators who want to log in to the Content Engine for monitoring, configuration, or troubleshooting purposes.
Note
For information about content authentication and authorization, see Chapter 10, "Configuring Content Authentication and Authorization on Standalone Content Engines."To configure administrative login authentication and authorization for standalone Content Engines, follow these steps:
Step 1
Step 2
For example, specify the IP address of the remote RADIUS servers or TACACS+ servers that the Content Engine should use to authenticate login requests. For more information, see the following sections:
•
•
Step 3
•
•
•
For example, specify which authentication database the Content Engine should check to process an administrative login request. For more information, see the "Specifying and Enabling the Administrative Login Authentication and Authorization Scheme" section.
Caution
When local authentication is disabled, if you disable all other authentication methods, local authentication is reenabled automatically.
The following sections describe how to specify authentication server settings for a standalone Content Engine.
•
•
Specifying RADIUS Authentication Settings for Standalone Content Engines
RADIUS authentication clients reside on the Content Engine running ACNS 5.x software. When enabled, these clients send authentication requests to a central (remote) RADIUS server, which contains login authentication and network service access information.
To configure RADIUS authentication on a standalone Content Engine, you must configure a set of RADIUS authentication server settings on the Content Engine. You can use the Content Engine GUI or the CLI to configure this set of RADIUS authentication server settings for a Content Engine.
Table 17-2 describes the RADIUS authentication settings.
After configuring these RADIUS authentication settings on the Content Engine, you can enable the following types of RADIUS authentication on the Content Engine:
•
•
To use the Content Engine GUI to configure RADIUS authentication settings on a standalone Content Engine, choose Caching > RADIUS. Use the displayed RADIUS Authentication Settings window. Click the Enable RADIUS On radio button to enable RADIUS authentication on this Content Engine. Use the RADIUS Authentication Settings window to specify the other RADIUS authentication settings. For more information about this window, click the HELP button in the window.
To use the Content Engine CLI to configure RADIUS authentication settings on a standalone Content Engine, follow these steps:
Step 1
ContentEngine(config)# radius-server host ip_addr [auth-port port]This example shows how to specify a RADIUS server at 172.16.52.3:
ContentEngine(configure)# radius-server 172.16.52.3Step 2
ContentEngine(configure)# radius-server key myradiuskey
Step 3
For example, configure the Content Engine to wait 10 seconds before declaring a timeout if it has not received a response from the RADIUS server:
ContentEngine(config)# radius-server timeout 10Step 4
For example, configure the Content Engine to retransmit three times to the RADIUS server if a RADIUS timeout occurs:
ContentEngine(config)# radius-server retransmit 3
Note
The following example enables the RADIUS client on the Content Engine, specifies a remote RADIUS server for authentication, specifies the RADIUS key on the Content Engine, accepts retransmit defaults, and excludes the domain name and mydomain.net domains from RADIUS authentication. Configuration can be verified with the show radius-server and show rule all EXEC commands.
ContentEngine(config)# radius-server enableContentEngine(config)# radius-server host 172.16.90.121ContentEngine(config)# radius-server key myradiuskeyContentEngine(config)# rule enableContentEngine(config)# rule no-auth domain mydomain.netYou can now enable RADIUS as a administrative login authentication and authorization method for this Content Engine, as described in the "Enabling and Disabling Administrative Login Authentication and Authorization Through RADIUS" section.
Specifying TACACS+ Authentication Settings for Standalone Content Engines
In order to configure TACACS+ authentication on standalone Content Engines, you must configure a set of TACACS+ authentication settings on the Content Engine. You can use the Content Engine CLI or GUI to configure this set of TACACS+ authentication settings for a standalone Content Engine.
Table 17-3 describes the TACACS+ authentication settings.
Note
To use the Content Engine CLI to configure TACACS+ authentication settings on a standalone Content Engine, follow these steps:
Step 1
ContentEngine(config)# tacacs server ip_addr [primary]This example shows how to specify a specific TACACS+ server as a primary server:
ContentEngine(config)# tacacs server 172.16.50.1 primaryThis example shows how to specify a specific TACACS+ server as a backup server. This can be achieved by not specifying the primary option.:
ContentEngine(config)# tacacs server 172.16.50.2Step 2
ContentEngine(config)# tacacs key key
Step 3
For example, configure the Content Engine to wait 15 seconds before declaring a timeout if it has not received a response from the TACACS+ server:
ContentEngine(config)# tacacs timeout 15Step 4
For example, configure the Content Engine to retransmit only one time to the TACACS+ server if a TACACS+ timeout occurs:
ContentEngine(config)# tacacs retransmit 1Step 5
For example, specify ASCII clear text by entering the ASCII keyword:
ContentEngine(config)# tacacs password ascii
Note
In the following example, a TACACS+ server with the hostname of spearhead is configured as the primary TACACS+ server. The Content Engine is configured to use the same key (human789) as the one used on the TACACS+ server (the server named spearhead) and the default timeout interval, number of retransmits, and password types are changed. This example also shows how to use the show tacacs EXEC command to view the current TACACS+ configuration on the Content Engine:
ContentEngine(config)# tacacs host spearhead primaryContentEngine(config)# tacacs key human789ContentEngine(config)# tacacs timeout 10ContentEngine(config)# tacacs retransmit 5ContentEngine(config)# tacacs password asciiContentEngine(config)# exitContentEngine# show tacacsLogin Authentication for Console/Telnet Session: enabled (secondary)Configuration Authentication for Console/Telnet Session: enabled (secondary)TACACS+ Configuration:---------------------TACACS+ Authentication is offKey = *****Timeout = 5Retransmit = 2Password type: asciiServer Status---------------------------- ------10.107.192.148 primary10.107.192.16810.77.140.77You can now enable TACACS+ as an administrative login authentication and authorization method for this Content Engine, as described in the "Enabling and Disabling Administrative Login Authentication and Authorization Through TACACS+" section.
Specifying and Enabling the Administrative Login Authentication and Authorization Scheme
This section describes how to define and modify the various administrative login authentication and authorization schemes (the authentication configuration) for a standalone Content Engine:
•
•
Caution
Usage Guidelines
When defining or modifying the authentication configuration method for a standalone Content Engine, remember the following important information:•
•
–
–
–
•
authentication {configuration {local | radius | tacacs} enable [primary | secondary | tertiary] | fail-over server-unreachable | login {local | radius | tacacs} enable [primary | secondary | tertiary]}
Table 17-4 describes the parameters for the authentication global configuration command.
•
•
–
–
•
•
–
–
–
If all methods of an authentication login or authentication configuration command are configured as primary, or all as secondary or tertiary, the local method is attempted first, then TACACS+, and then RADIUS.
The following example enables local, TACACS+, and RADIUS authentication and authorization, setting TACACS+ as the first method used, local as the secondary method if the TACACS+ method fails, and RADIUS as the tertiary method to use if both local and TACACS+ fail:
ContentEngine(config)# authentication login tacacs enable primaryContentEngine(config)# authentication login local enable secondaryContentEngine(config)# authentication login radius enable tertiaryContentEngine(config)# authentication configuration tacacs enable primaryContentEngine(config)# authentication configuration local enable secondaryContentEngine(config)# authentication configuration radius enable tertiary
Note
The radius-server global configuration command and a RADIUS server must be configured to use the RADIUS authentication and authorization method. For information about configuring a RADIUS server, see the "Specifying RADIUS Authentication Settings for Standalone Content Engines" section.•
–
–
•
•
–
–
•
Reenabling and Disabling Administrative Login Authentication and Authorization Through the Local Database
By default, the Content Engine is configured to use its local database to authenticate and authorize administrative login requests. This scheme of authentication and authorization is referred to as the local method. You can use the Content Engine GUI or CLI to disable and reenable this method of authentication and authorization on a standalone Content Engine.
Caution
If you have disabled it on a Content Engine and want to reenable it from the Content Engine GUI, choose System > Authentication. In the displayed Authentication Configuration window, check the Enable box next to Local to enable local login authentication. By default, the local database is the primary database for administrative login authentication. To change this default, choose another option (for example, Secondary or Tertiary) from the drop-down list next to Local. Click Update. For more detailed information about how to use the Authentication Configuration window to perform this task, click the HELP button in the window.
To use the Content Engine CLI to reenable the local method on a standalone Content Engine, follow these steps:
Step 1
ContentEngine(config)# authentication login local enableStep 2
ContentEngine(config)# authentication configuration local enableThere are two privilege levels that can be granted to administrative users: normal-level administrative access (restricted privilege level of 0, or superuser administrative access [privilege level of 15]). For more information about privilege levels for administrative users, see the "Managing Administrative Login Accounts" section on page 5-3.
Note
Enabling and Disabling Administrative Login Authentication and Authorization Through RADIUS
When configuring a standalone Content Engine to use RADIUS to authenticate and authorize administrative login requests, keep these important points in mind:
•
•
•
•
From the Content Engine GUI, choose System > Authentication. Use the displayed Authentication Configuration window. For more information about how to use the Authentication Configuration window, click the HELP button in the window.
To use the Content Engine CLI to enable RADIUS authentication and authorization on a standalone Content Engine, follow these steps:
Step 1
ContentEngine(config)# authentication login radius enable [primary] [secondary] [tertiary]For example, to force the Content Engine to try RADIUS authentication first (to try it before using TACACS+ authentication), enter the following command:
ContentEngine(config)# authentication login radius enable primary
Step 2
ContentEngine(config)# authentication configuration radius enable [primary] [secondary] [tertiary]For example, to force the Content Engine to try RADIUS authorization first (to try it before using TACACS+ authorization), enter the following command:
ContentEngine(config)# authentication configuration radius enable primary
Note
Enabling and Disabling Administrative Login Authentication and Authorization Through TACACS+
When configuring a standalone Content Engine to use TACACS+ to authenticate and authorize administrative login requests, keep this important points in mind:
•
•
•
•
•
To enable TACACS+ authentication and authorization from the Content Engine GUI, choose System > Authentication, and use the displayed Authentication Configuration window. For more information about how to use the Authentication Configuration window, click the HELP button in the window.
To use the Content Engine CLI to enable TACACS+ authentication and authorization on a standalone Content Engine, follow these steps:
Step 1
ContentEngine(config)# authentication login tacacs enable [primary] [secondary] [tertiary]For example, to force the Content Engine to try TACACS+ authentication first (to try it before using RADIUS authentication), enter this command:
ContentEngine(config)# authentication login tacacs enable primary
Step 2
ContentEngine(config)# authentication configuration tacacs enable [primary] [secondary] [tertiary]For example, to force the Content Engine to try TACACS+ authorization first (to try it before using RADIUS authorization), enter this command:
ContentEngine(config)# authentication configuration tacacs enable primary
Note
Displaying the Current Administrative Authentication and Authorization Configuration
To display the current administrative login authentication and authentication configuration on a standalone Content Engine, enter the show authentication user EXEC command. As the following sample output shows, the authentication schemes (for example, local, RADIUS, or TACACS+) that the Content Engine is configured to use to authenticate and authorize administrative login requests are displayed:
ContentEngine# show authentication userAuthentication scheme fail-over reason: server unreachableLogin Authentication: Console/Telnet Session----------------------------- -----------------------local enabled (primary)radius disabledtacacs disabledConfiguration Authentication: Console/Telnet Session----------------------------- -----------------------local enabled (primary)radius disabledtacacs disabled
