|
|
 |
Note The Cisco Application and Content Networking Software (ACNS) interoperates in transparent caching mode with other Content Engines in a cache cluster (WCCP farm), even if those Content Engines are running Release 2.x or Release 3.x versions of the Cisco Cache software. Both WCCP and Internet Cache Protocol (ICP) are supported in a cluster. |
This chapter describes caching features in ACNS 4.0 software (see Table 5-1) that were not included in Cisco Cache software, Release 3.1. Caching features that are enhanced but not new relative to Release 3.1 are discussed in the "Changes in Existing Cache Software Commands" section in "Cache Application Commands in Cisco Application and Content Networking Software, Release 4.0."
Table 5-1 lists new caching features in ACNS 4.0 software and their associated command-line interface (CLI) commands. Release notes might contain updates to this information.
| Cache Application Feature | Related CLI Commands | Section and Page |
|---|---|---|
| Cache parameter settings | ||
Caching of authenticated content | http cache-authenticated show http cache-authenticated | |
| Employee Internet management | ||
URL filtering | url-filter url-filter local-list-reload no url-filter show url-filter show statistics url-filter websense | |
| Management features | ||
Administration from the GUI | gui-server | Administering Caching from the Cache Application Management Graphical User Interface |
SSH version 1 | sshd ssh-key-generate show sshd no sshd enable | |
Setting ToS/DSCP with the Rules Template | ip dscp rule dscp | Setting Type of Service or Differentiated Services Code Point with the Rules Template |
| User authentication | ||
Microsoft NTLM authentication | http cache-authenticated ntlm server http authenticate-strip-ntlm show http cache-authenticated show http authenticate-strip-ntlm | |
TACACS+ authentication | authentication tacacs show tacacs | |
User authentication configuration | authentication show authentication show statistics authentication | |
RADIUS and LDAP authentication | http authentication cache http authentication header ldap radius-server show http-authcache show statistics http-authcache | |
| Miscellaneous features | ||
Browser autoconfiguration | proxy-auto-config show proxy-auto-config no proxy-auto-config | |
Healing mode | http cluster http cluster misses http cluster max-delay http cluster http-port clear statistics cluster show http cluster show statistics cluster | |
The following caching features are supported in ACNS 4.0 software, but are not found in Cache software, Release 3.1:
In addition to CLI, caching software can be configured and monitored with the Cache application management graphical user interface (GUI), which is accessed with a browser.
New in this release are GUI configuration pages for the following features:
Access to the Cache application management GUI can be controlled with multiple levels of username and password access, and access can be restricted to a subset of IP addresses (hosts). These access controls are configured with the user command and the trusted-host command, which are the same commands that you use to configure access to the CLI.
To connect to the Cache application management GUI, perform the following steps.
|
Note Be sure to enable Java, JavaScript, and Cascading Style Sheets on your Internet Explorer browser, or use the Netscape 4.0 or later browser. |
Step 1 Start a web browser on a machine that has access to the network on which the Content Engine resides.
Step 2 Open the URL with the cache IP address specified in the initial Content Engine configuration. Append the port number currently configured. In this example, the default port number of 8001 is used:
http://10.1.58.5:8001
You are prompted for a username and password.
Step 3 Enter a correct username and password. The Content Engine returns the initial management page, which contains links to other management pages.
If you forget your password, you must have another administrator reset your password. The password for the user admin is specified in the initial system configuration dialog.
ACNS 4.0 software provides support for proxy automatic configuration files (.pac files). A browser obtains proxy IP address and port configuration information from the proxy automatic configuration file (.pac file) when the browser's autoconfiguration URL field is configured with the Content Engine IP address, incoming port number, file directory, and .pac filename.
The proxy-auto-config download EXEC command downloads an automatic configuration file from an FTP server to the present working directory of the Content Engine. To enable the proxy automatic configuration file feature, enter the proxy-auto-config enable global configuration command. Each time you download a new autoconfiguration file to the Content Engine, enter a no proxy-auto-config enable and then a proxy-auto-config enable command.
The autoconfiguration feature is supported by the Microsoft Internet Explorer and Netscape browsers. The browser must be manually configured for automatic proxy configuration.
This example demonstrates how to download an autoconfiguration file from an FTP server to the Content Engine:
Console# proxy-auto-config download 172.16.10.10 remotedirname theproxyfile.pac
This example enables browser autoconfiguration on the Content Engine:
Console(config)# proxy-auto-config enable
This example shows the URL that you enter in the browser's automatic proxy configuration
URL field:
http://CCNScache-ipaddress:portnumber/theproxyfile.pac
The authenticated data caching feature allows basic and NT LAN Manager (NTLM) authenticated content to be cached and served to more than one user, while maintaining security. If an authenticated object is cached, then subsequent requests for that object (from new users) require authentication. The cached object is revalidated with the origin server through the authorization header for the new user. If the user is not authorized, the server sends a 401 (Unauthorized) response. If the user is authorized and the object is not modified, the cached object is served to the client. See the "Microsoft NTLM Authentication Support" section for further information.
|
Note The authenticated data caching feature existed in Cache software, Release 2.x. |
This example enables caching of basic and NTLM authenticated content:
Console(config)# http cache-authenticated all
Console(config)# show http cache-authenticated all
Basic authenticated objects are cached.
NTLM authenticated objects are cached.
When a Content Engine is added to an existing WCCP Version 2 cache group (cluster), it can receive requests for content that was formerly served by another cache in the cluster. This event is termed a "near-miss," because if the request had been sent to the former Content Engine, it would have been a cache hit. A near-miss lowers the overall cache hit rate of the Content Engine cluster.
Healing mode allows the newly added Content Engine to query and obtain cache objects from all other caches in the cluster on a cache miss event. If the object is not found in the cluster, the Content Engine processes the request through the outgoing proxy or origin server. The Content Engine in healing mode is called a healing client. The caches in the cluster that respond to healing client requests are called healing servers.
|
Note Healing mode is only invoked on a healing client when the request is transparently redirected to the Content Engine. Healing mode is not invoked when the request is sent to the Content Engine in proxy mode. |
The http cluster command modifies the healing mode parameters. The http cluster http-port command specifies the port number over which requests from the healing Content Engine are sent to other Content Engines in the cluster.
|
Note The default port number is 80. If you choose to configure a port other than the default 80, you have to make sure that the port configured matches the port specified in the http proxy incoming command on healing servers in the farm. Otherwise, the healing client is not able to retrieve objects from the healing servers. |
The http cluster misses command specifies the maximum number of misses that the healing Content Engine can receive from the cluster after the last healing mode hit response until the healing process is disabled. The default is 0 misses. The http cluster max-delay command specifies the maximum time interval in seconds for which a healing Content Engine waits for a healing response from the cluster before considering the healing request a miss.
To enable the healing client, you should, at the least, configure max-delay and misses. The default port number for http-port is 80; therefore, if you use the default port, you do not have to configure http-port.
To disable healing client, you should, at the least, configure either misses or max-delay to 0, or you can use the no form of the command:
|
Note Healing mode existed in Cache software, 2.x releases. |
This example enables the healing mode feature by setting the HTTP port for forwarding HTTP requests to a healing server, setting the maximum delay to wait for a response from the cluster in seconds before considering the healing request a miss, and setting the maximum number of misses that the healing Content Engine can receive from the cluster before healing mode gets disabled at healing client.
Console(config)# http cluster http-port 8080
Console(config)# http cluster max-delay 5
Console(config)# http cluster misses 5
In this example the show statistics cluster command displays the statistics of the healing client and the healing server. The clear statistics cluster command resets the healing mode statistics:
Console(config)# show statistics cluster
Healing mode client statistics
------------------------------
Client Requests Sent = 0
Client Responses Received = 0
Client Responses Hit = 0
Client Responses Miss = 0
Client Responses Error = 0
Client Responses Timeout = 0
Healing mode server statistics
------------------------------
Server Requests Received = 0
Server Responses Sent = 0
Server Responses Hit = 0
Server Responses Miss = 0
Server Responses Error = 0
Console(config)# clear statistics cluster
The show http cluster command displays max-delay, misses, and HTTP port values. In the first example, the values are set to 0 and the healing client is disabled.
Console(config)# show http cluster
Healing client is disabled
Timeout for responses = 0 seconds
Max number of misses allowed before stop healing mode = 0
Http-port to forward http request to healing server is not configured
In this example the healing client is enabled.
Console(config)# show http cluster
Healing client is enabled
Timeout for responses = 10 seconds
Max number of misses allowed before stop healing mode = 999
Http-port to forward http request to healing server = 8080
ACNS 4.0 software supports NTLM end-to-end authentication and HTTP request authentication. End-to-end NTLM authentication includes pass-through servicing and the caching of web objects that require NTLM authentication. HTTP request authentication authenticates a user's domain, username, and password with a preconfigured NTLM domain controller before allowing requests from the user to be served by the Content Engine. NTLM authentication works only in a Microsoft environment (for instance, Microsoft Internet Explorer clients accessing Microsoft Internet Information Servers).
|
Note End-to-end NTLM authentication is supported with WCCP Version 2 transparent caching only. For HTTP request authentication, if NTLM authentication is used but the browser does not support NTLM authentication, the username and password information is passed to the Content Engine in clear text with a Basic authentication header. The Content Engine then uses this information to authenticate the user against the preconfigured NT domain controller. |
The two levels of NTLM end-to-end support can be summarized as follows:
The ACNS 4.0 software can be configured to cache objects that require NTLM authentication. The server puts a "no-store" flag on a reply object to prevent the reply from being cached. If no such flag is present, the object is cachable. When the Content Engine receives a request from a client already connected with the intended NTLM server, the ACNS software searches the cache. For a cache miss, the request is forwarded to the origin server. The reply object is then sent to the client and a copy is cached. On a cache hit, the Content Engine checks for a secured connection between this client and the server. If the object requires NTLM authentication and there is no virtual persistent connection set up between the client and the server, the Content Engine establishes the secured connection between client and server and forwards the request to the server. If there is a virtual persistent connection between the client and the server, an If-Modified-Since (IMS) message is sent to the server to verify the validity of the object and the user's access rights to this object before the cached copy is served to the client.
Before invoking an NTLM authentication request, make sure that the following conditions exist.
In the following example, server1 must be in the cisco.com domain and must have an entry in DNS that matches its NetBIOS-named computer account.
ip domain-name cisco.com
ntlm server host server1
For clients within the domain using the Internet Explorer browser in proxy mode, authentication is "popless"; that is, the user is not prompted with a dialog box to enter a username and password. In transparent mode, authentication is popless only if the Internet options of Internet Explorer browser security settings are customized and set to User Authentication > Logon > Automatic logon with current username and password.
For clients outside the domain and those using the Netscape browser, a pop-up username/password dialog box appears only on the first authentication request. Once the client is successfully authenticated, the entry is placed in the cache, and no reauthentication requests are made to the client until the entry lease expires.
NTLM request authentication works in a "popless" mode in transparent caching mode (that is, no popup challenge windows) only if the site being accessed is an internal site. Otherwise, the browser prompts for username, password, and domain name. A site can be set as internal with the Microsoft Internet Explorer browser by entering the IP address of the internal site in the security and local intranet options field.
This example configures a Content Engine for end-to-end NTLM authentication. By default, basic and NTLM authenticated objects are not cached.
Console(config)# no http authenticate-strip-ntlm
Console(config)# http cache-authenticated ntlm
Console# show http cache-authenticated ntlm
Basic authenticated objects are not cached.
NTLM authenticated objects are cached.
This example configures a Content Engine for NTLM request authentication and blocking.
Console(config)# ntlm server enable
Console(config)# ntlm server host 172.16.10.10 primary
Console(config)# ntlm server host 172.16.10.12 secondary
Console(config)# ntlm server domain cisco_abc
Console# show ntlm
Primary: 172.16.10.10
Secondary: 172.16.10.12
State: Disabled
Domain name: cisco_abc
|
Note The HTTP authentication features RADIUS and Lightweight Directory Access Protocol (LDAP) existed in Cache software 2.x releases and were configured through the radius-server and ldap commands, respectively. For ACNS 4.0 software, the radius-server authtimeout option and the ldap authcache max-entries and ldap authcache auth-timeout options have been removed and are now configurable through the http authentication cache max-entries and timeout commands, respectively. The ldap client auth-header option has been removed and is now configurable through the http authentication header command. In addition, the radius-server command options exclude and multi-user-prompt have been removed. The rule no-auth domain command replaces radius-server exclude; however, there is no replacement available for the multi-user-prompt option. The ldap command has the following added options: enable and version. |
RADIUS authentication clients reside on Cisco Content Engines. When enabled, these clients send authentication requests to a central RADIUS server, which contains all user authentication and network service access information.
Enterprise system administrators can now use the Content Engine to restrict user Internet access with LDAP, which provides most of the services of the X.500 protocol, with less complexity and overhead. The ldap global configuration command was added to the CLI. Use the no form of the command to disable LDAP functions. An LDAP-enabled Content Engine authenticates users with an LDAP server. With an HTTP query, the Content Engine obtains a set of credentials from the user (user ID and password) and compares them against those in an LDAP server.
ACNS 4.0 software supports LDAP version 3 and supports all LDAP features except for Secure Authentication and Security Layer (SASL).
When the Content Engine authenticates a user through the LDAP server, a record of that authentication is stored locally in the Content Engine RAM (authentication cache). As long as the authentication entry is kept, subsequent attempts to access restricted Internet content by that user do not require LDAP server lookups.
The http authentication cache timeout command specifies how long an inactive entry can remain in the authentication cache before it is purged. Once a record has been purged, any subsequent access attempt to restricted Internet content requires reauthentication.
LDAP authentication can be used with Websense URL filtering, but not with RADIUS authentication. Both LDAP and RADIUS rely on different servers, which may require different user IDs and passwords, making RADIUS and LDAP authentication schemes mutually exclusive. Should both RADIUS and LDAP be configured on the Content Engine at the same time, LDAP authentication is executed, not RADIUS authentication.
To exclude domains from LDAP or RADIUS authentication, use the rule no-auth domain command. LDAP or RADIUS authentication takes place only if the site requested does not match the specified pattern.
The events listed below occur when the Content Engine is configured for LDAP authentication and one of the following two scenarios is true:
1. The Content Engine examines the HTTP headers of the client request to find user information (contained in the Proxy-Authorization header).
2. If no user information is provided, the Content Engine returns a 407 (Proxy Authorization Required) message to the client.
3. The client resends the request, including the user information.
4. The Content Engine searches its authentication cache (based on user ID and password) to see if the client has been previously authenticated.
5. If a match is found, the request is serviced normally.
6. If no match is found, the Content Engine sends a request to the LDAP server to find an entry for this client.
7. If the server finds a match, the Content Engine allows the request to be serviced normally and stores the client user ID and password in the authentication cache.
8. If no match is found, the Content Engine again returns a 407 (Proxy Authorization Required) message to the client.
The events listed below occur when the Content Engine is configured for LDAP authentication and both of the following are true:
1. The Content Engine searches its authentication cache to see if the user's IP address has been previously authenticated.
2. If a match is found, the Content Engine allows the request to be serviced normally.
3. If no match is found in the first step, the Content Engine examines the HTTP headers to find user information (contained in the Authorization header).
4. If no user information is provided, the Content Engine returns a 401 (Unauthorized) message to the client.
5. The client resends the request, including the user information.
6. The Content Engine sends a request to the LDAP server to find an entry for this user.
7. If the server finds a match, the Content Engine allows the request to be serviced normally and stores the client IP address in the authentication cache.
8. If no match is found, the Content Engine again returns a 401 (Unauthorized) message to the client.
In transparent mode, the Content Engine uses the client IP address as a key for the authentication database.
If you are using LDAP user authentication in transparent mode, we recommend that the AuthTimeout interval configured with the http authentication cache timeout command be short. IP addresses can be reallocated, or different users can access the Internet through an already authenticated device (PC, workstation, and the like). Shorter AuthTimeout values help reduce the possibility that individuals can gain access using previously authenticated devices. When the Content Engine operates in proxy mode, it can authenticate the user with the user ID and password.
Two LDAP servers can be specified with the ldap server host command to provide redundancy and improved throughput. Content Engine load-balancing schemes distribute the requests to the servers. If the Content Engine cannot connect to either server, no authentication can take place, and users who have not been previously authenticated are denied access.
The Content Engine uses simple (nonencrypted) authentication to communicate with the LDAP server. Future expansion may allow for more security options based on Secure Socket Layer (SSL), SASL, or certificate-based authentication.
In some cases, users are located at branch offices. A Content Engine (CE1) can reside with them in the branch office. Another Content Engine (CE2) can reside upstream, with an LDAP server available to both Content Engines for user authentication.
|
Note The http append proxy-auth-header global configuration command must be configured on the downstream Content Engines to ensure that proxy-authorization information, required by upstream Content Engines, is not stripped from the HTTP request by the downstream Content Engines. Up to 16 upstream IP addresses can be configured on each downstream Content Engine. |
If branch office user 1 accesses the Internet, and content is cached at CE1, then this content cannot be served to any other branch office user unless that user is authenticated. CE1 must authenticate the local users.
Assuming that both CE1 and CE2 are connected to the LDAP server and authenticate the users, when branch office user 2 firsts requests Internet content, CE1 responds to the request with an authentication failure response (either HTTP 407 if in proxy mode, or HTTP 401 if in transparent mode). User 2 enters the user ID and password, and the original request is repeated with the credentials included. CE1 contacts the LDAP server to authenticate user 2.
Assuming authentication success, and a cache miss, the request along with the credentials is forwarded to CE2. CE2 also contacts the LDAP server to authenticate user 2. Assuming success, CE2 either serves the request out of its cache or forwards the request to the origin server.
User 2 authentication information is now stored in the authentication cache in both CE1 and CE2. Neither CE1 nor CE2 needs to contact the LDAP server for user 2's subsequent requests (unless user 2's entry expires and is removed from the authentication cache).
This scenario assumes that CE1 and CE2 use the same method for authenticating users. Specifically, both Content Engines must expect the user credentials (user ID and password) to be encoded in the same way.
When the Content Engine operates in transparent mode, the user IP address is used as a key to the authentication cache. When user 2 sends a request transparently to CE1, after authentication, CE1 inserts its own IP address as the source for the request. Therefore, CE2 cannot use the source IP address as a key for the authentication cache.
When CE1 inserts its own IP address as the source, it must also insert an X-Forwarded-For header in the request (http append x-forwarded-for-header command). CE2 must first look for an X-Forwarded-For header. If one exists, that IP address must be used to search the authentication cache. Assuming the user is authenticated at CE2, then CE2 must not change the X-Forwarded-For header, just in case there is a transparent CE3 upstream.
In this scenario, if CE1 does not create an X-Forwarded-For header (for example, if it is not a Cisco Content Engine and does not support this header), then authentication on CE2 will not work.
In a topology with two Content Engines, assume that CE1 is operating in transparent mode and CE2 is operating in proxy mode, with the browsers of all users pointing to CE2 as a proxy.
Because the browsers are set up to send requests to a proxy, an HTTP 407 message is sent from CE1 back to each user to prompt for credentials. By using the 407 message, the problem of authenticating based on source IP address is avoided. The username and password can be used instead.
This mode provides better security than using the HTTP 401 message. The Content Engine examines the style of the address to determine whether there is an upstream proxy. If there is, the Content Engine uses an HTTP 407 message to prompt the user for credentials even when operating in transparent mode.
Once a user has been authenticated through LDAP, all transaction logs generated by the Content Engine for that user contain user information. If the Content Engine is acting in proxy mode, the user ID is included in the transaction logs. If the Content Engine is acting in transparent mode, the user IP address is included instead.
If the transaction-logs sanitize command is invoked, the user information is suppressed.
In this example, the host for the LDAP server daemon is configured:
Console(config)# ldap server host www.someDomain.com port 390
To delete an LDAP server, use the no ldap server command.
Console(config)# no ldap server host 1.1.1.1
In this example, the host for the RADIUS server is configured:
Console(config)# radius-server 172.16.90.121
In this example, the length of time that entries are valid in the authentication cache is set:
Console(config)# http authentication cache timeout 1000
The following example specifies that the Content Engine should use header 407 when asking the end user for authentication credentials (user ID and password).
Console(config)# http authentication header 407
The Rules Template feature allows for requests to be matched using a specified number of parameters with a specified number of actions applied against the matches. A rule consists of a pattern and an action. When a specific pattern (match) is found, a specified action occurs.
Setting the Type of Service (ToS) or differentiated services code point (DSCP) is called packet marking, which allows you to partition network data into multiple priority levels or types of service. With this release, you can now set the ToS or DSCP values in IP packets based on a URL match, a file type, a domain, a destination IP address, a source IP address, or a destination port.
You can set specific ToS or DSCP values for the following:
The ToS or DSCP may be set based on any of the policies matching the src-ip-address, dst-ip-address, dst-port-number, domain regex, url-regex, or mime-type regex options.
In addition, you can now configure global ToS or DSCP settings with the ip dscp command.
|
Note The Rules Template configuration takes precedence over the ip dscp command. |
|
Note The url-filter command takes precedence over the rule command to the extent that even the rule no-block command is executed only if the url-filter command has not blocked the request. |
This example sets the ToS value to "minimize delay" for outbound requests to a specified destination IP address, in this case 1.1.1.1:
Console(config)# rule dscp server set-tos min-delay dst-ip 1.1.1.1 255.255.255.255
This example sets the ToS value to "minimize delay" for all outbound requests:
Console(config)# ip dscp server set-tos min-delay
Using the ip command, this example uses the ToS or DSCP value that was originally sent by the server (when the object was first fetched) for all future cache hit responses for the same object:
Console(config)# ip dscp client cache-hit match-server
Before you enable the sshd command, use the ssh-key-generate command to generate a private and a public key, which the server and the client programs use to verify each other's identity.
When a user runs an SSH client and logs in to the Content Engine, the public key for the SSH daemon running on the Content Engine is recorded in the client machine known_hosts file in the user's home directory. If the Content Engine administrator subsequently regenerates the host key by issuing the ssh-key-generate command, the user must delete the old public key entry associated with the Content Engine in the known_hosts file before running the SSH client program to log in to the Content Engine. When the user runs the SSH client program after deleting the old entry, the known_hosts file is updated with the new SSH public key for the Content Engine.
|
Note The Telnet daemon can still be used with the Content Engine. SSH does not replace Telnet. |
This example generates a private and a public SSH host key:
Console# ssh-key-generate
This example enables SSH:
Console(config)# sshd enable
The Terminal Access Controller Access Control System Plus (TACACS+) validates users before they gain access to a router. TACACS+ is derived from the United States Department of Defense (RFC 1492) and is used by Cisco Systems as an additional control of nonprivileged and privileged mode access. This release supports TACACS+ only and not TACACS or Extended TACACS.
TACACS+ provides both authentication and authorization options. Authentication or login is the action of identifying and validating a user. It verifies a username with the password. Authorization or configuration is the action of determining what a user is allowed to do. To configure TACACS+, use the authentication and tacacs commands.
|
Note The TACACS+ feature existed in Cache software 2.x releases. |
The user global configuration commands or the Users GUI page provides a way to add, delete, or modify usernames, passwords, and access privileges in the local database. The TACACS+ remote database can also be used to maintain login and configuration privileges for administrative users. The tacacs command or the TACACS+ GUI page allows you to configure the network parameters required to access the remote database.
Login and configuration privileges can be obtained from both the local database or the TACACS+ remote database. If both databases are enabled, then both databases are queried; if the user data cannot be found in the first database queried, then the second database is tried. When the primary keyword is entered for TACACS+ login or configuration authentication, the TACACS+ database is queried first, and the local database is queried second. If the TACACS+ database is not designated as primary, and both the local and the TACACS+ database are enabled, the local database is queried first. If both the local and the TACACS+ databases are disabled (no authentication), the Content Engine verifies that both are disabled and if so, sets the Content Engine to the default state.
Use the tacacs key command to specify the TACACS+ key, used to encrypt the packets transmitted to the server. This key must be the same as the one specified on the server daemon. The maximum number of characters in the key should not exceed 99 printable ASCII characters (except tabs). An empty key string is the default. All leading spaces are ignored; spaces within and at the end of the key string are not ignored. Double quotes are not required even if there are spaces in the key, unless the quotes themselves are part of the key.
One primary and two backup TACACS+ servers can be configured; authentication is attempted on the primary server first, then on the others in the order in which they were configured. The primary server is the first server configured unless another is explicitly specified as primary with the tacacs server hostname primary command.
The tacacs timeout is the number of seconds the Content Engine waits before declaring a timeout on a request to a particular TACACS+ server. The range is from 1 to 20 seconds with 5 seconds as the default. The number of times the Content Engine repeats a retry-timeout cycle before trying the next TACACS+ server is specified by the tacacs retransmit command. The default is two retry attempts.
Three unsuccessful login attempts are permitted. TACACS+ logins may appear to take more time than local logins depending on the number of TACACS+ servers and the configured timeout and retry values.
This example configures the key used in encrypting packets:
Console(config)# tacacs key human789
This example configures the host named spearhead as the primary TACACS+ server:
Console(config)# tacacs server spearhead primary
This example sets the timeout interval for the TACACS+ server:
Console(config)# tacacs timeout 10
This example sets the number of times authentication requests are retried (retransmitted) after a timeout:
Console(config)# tacacs retransmit 5
Only one form of URL filtering can be active at a time.
|
Note The URL filtering feature existed in Cache software, 2.x releases. The URL filtering feature in ACNS 4.0 software differs from the URL feature in other releases as follows: There is now an enable command option for the good-list and bad-list options; the URL list filenames and the customized blocking message directory name are now specified in the command-line interface; you can now use the url-filter local-list-reload EXEC command to dynamically refresh a local URL list; and bad-sites-block has been changed to bad-sites-deny. |
You can configure the Content Engine to deny client requests for URLs that are listed in a badurl.lst file, or configure it to fulfill only requests for URLs in a goodurl.lst file.
To deny requests for specific URLs, do the following:
Step 1 Create a plain text file named badurl.lst.
In this file, enter the URLs that you want to block. The list of URLs in the badurl.lst file must be written in the form http://www.domain.com/ and delimited with carriage returns.
Step 2 Copy the badurl.lst file to the /local1 sysfs directory of the Content Engine.
|
Note We recommend creating a separate directory under local1 to hold the bad and good lists. For example, /local1/filtered_urls. |
Step 3 Use the url-filter bad-sites-deny command to point to the bad URL list.
Console(config)# url-filter bad-sites-deny local/local1/badurl.lst
Step 4 Use the url-filter enable bad-list command to actively deny the URLs.
Console(config)# url-filter enable bad-list
To permit specific URLs to the exclusion of all other URLs, do the following:
Step 1 Create a plain text file named goodurl.lst.
In this file, enter the URLs that you want to exclusively allow. The list of URLs in the goodurl.lst file must be written in the form www.domain.com and delimited with carriage returns.
Step 2 Copy the goodurl.lst file to the /local1 sysfs directory of the Content Engine.
|
Note We recommend creating a separate directory under local1 to hold the bad and good lists, for example, /local1/filtered_urls. |
Step 3 Use the url-filter good-sites-allow command to point to the goodurl.lst file.
Console(config)# url-filter good-sites-allow local/local1/goodurl.lst
Step 4 Use the url-filter enable good-list command to actively permit only the good URLs.
Console(config)# url-filter enable good-list
|
Note When you update the badurl.lst or goodurl.lst file, use the url-filter local-list-reload EXEC command to recopy the URL list file to the Content Engine. |
Use the no form of the command to disable blocking or Websense permission requests (for example, no url-filter bad-sites-deny).
The Content Engine with ACNS 4.0 software can be configured to return a customized blocking message to the client. The custom message must be an administrator-created HTML page named block.html. Make sure to copy all embedded graphics associated with the custom message HTML page to the same directory that contains the block.html file. To enable the customized blocking message, use the url-filter custom-message command and specify the directory name.
To disable the custom message, use the no url-filter custom-message command.
The url-filter custom-message command can be enabled and disabled without affecting the good-list and bad-list configuration.
|
Note Do not use local1 or local2 as directories. Create a separate directory under local1 or local2 for holding the custom message file. |
In the block.html file, objects (such as .gif, .jpeg, and so on) must be referenced with the string /content/engine/blocking/url, as shown in the example below.
The following is an example of a block.html file:
<TITLE>Cisco Content Engine example customized message for url-filtering</TITLE>
<p>
<H1>
<CENTER><B><I><BLINK>
<FONT COLOR="#800000">P</FONT>
<FONT COLOR="#FF00FF">R</FONT>
<FONT COLOR="#00FFFF">A</FONT>
<FONT COLOR="#FFFF00">D</FONT>
<FONT COLOR="#800000">E</FONT>
<FONT COLOR="#FF00FF">E</FONT>
<FONT COLOR="#00FFFF">P</FONT>
<FONT COLOR="#FF8040">'</FONT>
<FONT COLOR="#FFFF00">S</FONT>
</BLINK>
<FONT COLOR ="#0080FF">Blocked Page</FONT>
</I></B></CENTER>
</H1>
<p>
<p>
<IMG src="/content/engine/blocking/url/my.gif">
<p>
This page is blocked by the Content Engine.
<p>
The Content Engine can use a Websense Enterprise server as a filtering engine and enforce the filtering policy configured on the Websense server. Refer to the Websense documentation for further information on Websense filtering policies.
To enable Websense URL filtering on the Content Engine, specify the Websense server IP address or host name. The timeout option sets the maximum amount of time that the Content Engine will wait for a Websense response. The timeout default is 20 seconds. The port option specifies the port number on which the server will intercept requests from the Content Engine (the default port is 15868). Use the no url-filter websense server command to disable Websense URL filtering.
The url-filter websense allowmode enable command permits the Content Engine to fulfill the client request after a Websense server timeout.
The Websense server returns its own blocking message.
To use Websense URL filtering with a cluster of Content Engines, make sure to configure the url-filter websense server command on each Content Engine in the cluster to ensure that all traffic is filtered.
To enable Websense filtering, use the url-filter enable websense command.
Authentication, also referred to as "login," is the act of verifying usernames and passwords.
The authentication command has been added to allow the administrator to enable, disable, and prioritize the following different user authentication processes: local, Lightweight Directory Access Protocol (LDAP), RADIUS, and Terminal Access Controller Access Control System Plus (TACACS+).
|
Note The authentication command existed in Cache software 2.x releases. The syntax has changed for this release in order to incorporate LDAP and RADIUS authentication. |
The local authentication option uses the local password file (/etc/password) for authentication. By default, local authentication is enabled and LDAP, RADIUS, and TACACS+ authentications are disabled. Whenever LDAP, RADIUS, and TACACS+ authentications are disabled, local authentication is automatically enabled.
You can configure the priority order for authentication methods. For example, local authentication can be enabled to provide authentication when the TACACS+ server is not available.
The login option allows you establish how a user is verified. The configuration option lets you set user authentication for configuration modes.
The following example enables both local and TACACS+ authentication, and establishes TACACS+ as the first authentication used and local as the authentication used if TACACS+ is not available:
Console(config)# authentication login tacacs enable primary
Console(config)# authentication login local enable secondary
This is an example of the show authentication command:
Console# show authentication
Login Authentication: Console/Telnet Session
----------------------------- -----------------------
local enabled
tacacs enabled (primary)
Configuration Authentication: Console/Telnet Session
----------------------------- -----------------------
local enabled
tacacs enabled
This is an example of the show statistics authentication command:
Console# show statistics authentication
Authentication Statistics
--------------------------------------
Number of access requests: 37
Number of access deny responses: 14
Number of access allow responses: 23
Posted: Thu Nov 14 13:46:58 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.