Cisco ACNS Software Caching Configuration Guide, Release 4.2 - Chapter 13: Configuring Authentication [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Configuring Authentication and Authorization

User Authentication and Authorization

HTTP Request Authentication

TACACS+ Authentication

NTLM Authentication

NTLM Authentication Transparency

RADIUS HTTP Request Authentication

RADIUS Authentication Redirection

LDAP HTTP Request Authentication

HTTP Request Considerations

Group Authentication Using Access Control Lists

LDAP Group Authentication with Access Lists

NTLM Group Authentication with Access Lists

Excluding Domains from HTTP Authentication Servers

Proxy Mode Server Authentication

Transparent Mode Authentication

Server Redundancy

Security Options

Hierarchical Caching in Proxy Mode

Hierarchical Caching in Transparent Mode

Hierarchical Caching, Content Engine in Transparent Mode with an Upstream Proxy

Authentication Cache Size Adjustments

Transaction Logging

End-to-End Authentication

Basic End-to-End Authentication

NTLM End-to-End Authentication

Configuring Authentication and Authorization

This chapter discusses authentication and authorization support on the Content Engine, and describes the HTTP request considerations when using authentication servers. This chapter contains the following sections:

•User Authentication and Authorization

•HTTP Request Authentication

•End-to-End Authentication

User Authentication and Authorization

Authentication, also referred to as "login," is the act of verifying usernames and passwords. Authorization, or "configuration," refers to the setting of privileges for authenticated users in a network. Generally, authentication precedes authorization in a network.

The authentication command configures both the authentication and authorization methods that govern login and configuration access to the Content Engine. Login and configuration privileges are maintained in three databases in ACNS 4.2 software: the local database, Terminal Access Controller Access Control System Plus (TACACS+) database, and Remote Authentication Dial-In User Service (RADIUS) database. If all databases are enabled, then all databases are queried; if the user data cannot be found in the first database queried, then the second and third databases are queried.

The authentication login command specifies the method that determines whether the user has any level of permission to access the Content Engine. The authentication configuration command specifies the method that authorizes the user with privileged access (configuration access) to the Content Engine.

The authentication login local and the authentication configuration local commands use a local database for authentication and authorization.

The authentication login tacacs and authentication configuration tacacs commands use a remote TACACS+ server to determine the level of user access.

Note The tacacs global configuration command and a TACACS+ server must be configured to use the TACACS+ authentication and authorization method.

The authentication login radius and authentication configuration radius commands use a remote RADIUS server to determine the level of user access.

Note The radius-server global configuration command and a RADIUS server must be configured to use the RADIUS authentication and authorization method.

By default, the local method is enabled, with TACACS+ and RADIUS both disabled for login and configuration. Whenever TACACS+ and RADIUS are disabled, local is automatically enabled. TACACS+, RADIUS, and local methods can be enabled at the same time. The primary option specifies the first method to attempt for login and configuration purposes; the secondary option specifies the method to use if the primary method fails. The tertiary option specifies the method to use if both primary and secondary methods fail. If all methods of an authentication login or authentication configuration command are configured as primary, or all as secondary or tertiary, local 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 primary
ContentEngine(config)# authentication login local enable secondary
ContentEngine(config)# authentication login radius enable tertiary
ContentEngine(config)# authentication configuration tacacs enable primary
ContentEngine(config)# authentication configuration local enable secondary
ContentEngine(config)# authentication configuration radius enable tertiary
This is an example of the show authentication user command:
ContentEngine# show authentication user
Login Authentication:         Console/Telnet Session
----------------------------- -----------------------
local                         enabled (secondary)
radius                        enabled (tertiary)
tacacs                        enabled (primary)
Configuration Authentication: Console/Telnet Session
----------------------------- -----------------------
local                         enabled (secondary)
radius                        enabled (tertiary)
tacacs                        enabled (primary)
HTTP Request Authentication

The ACNS 4.2 software Cache application supports TACACS+, Microsoft NT LAN Manager (NTLM), Lightweight Directory Access Protocol (LDAP), and RADIUS server HTTP request authentication. In the case of NTLM, HTTP request authentication authenticates a user's domain, username, and password with a preconfigured primary domain controller (PDC) before allowing requests from the user to be served by the Content Engine.

TACACS+ Authentication

The TACACS+ database validates users before they gain access to a Content Engine. 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. ACNS 4.1 or later software supports TACACS+ only and not TACACS or Extended TACACS.

To enable TACACS+ for HTTP request authentication, use the tacacs enable global configuration configuration command. This authentication is independent of the user authentication and authorization options shown in the "User Authentication and Authorization" section.

Note You must configure a TACACS+ server with the tacacs server global configuration command before you can enable the TACACS+ authentication method.

The Users GUI page or the user global configuration commands provide 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.

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 that 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 that 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
NTLM Authentication

The NTLM protocol can be used to authenticate and block user access to the Internet. When a user logs in to a Windows NT or a Windows 2000 domain and starts a browser, the authentication information is stored by the browser and later used as NTLM credentials to access the Internet. The browser sends the NTLM credentials with the domain name to the ACNS cache, which in turns sends a request to the Windows NT domain controller to check the validity of the user in the domain. If the user is not a valid user in the domain, then the request to access the Internet is denied. If authentication succeeds, the source IP address is entered in the authentication cache. Future requests from this IP address are not challenged until the authentication cache entry expires, or is cleared.

Use the ntlm server command to enable NTLM authentication and configure the NTLM server domain name, NT primary domain controller (PDC) name or IP address, and optionally set the host name or address as primary or secondary.

Before invoking an NTLM authentication request, make sure that the following conditions exist.

•The NTLM primary domain controller has an entry in the Domain Name System (DNS) that matches its NetBIOS-named computer account.

•The primary domain controller is both forward and reverse DNS-resolvable.

•The domain name configured on the Content Engine matches the domain of which the primary domain controller is a part.

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
NTLM Authentication Transparency

For clients within the domain using the Internet Explorer browser in proxy mode, authentication is "popless"; this is, the user is not prompted with a dialog box to enter a username and password. In transparent mode, authentication is transparent only if the Internet options security settings are customized and set to User Authentication > Logon > Automatic logon with current username and password.

This example configures a Content Engine for NTLM request authentication.
Console(config)# ntlm server enable 
Console(config)# ntlm server domain cisco_abc
Console(config)# ntlm server host 172.16.10.10 primary
Console(config)# ntlm server host 172.16.10.12 secondary
Console# show ntlm
Primary:       172.16.10.10 
Secondary:     172.16.10.12 
State:          Enabled
Domain name: cisco_abc
RADIUS HTTP Request Authentication

RADIUS authentication clients reside on the Content Engine running ACNS 4.2 software. When enabled, these clients send authentication requests to a central RADIUS server, which contains user authentication and network service access information.

To configure RADIUS parameters, use the radius-server command in global configuration mode. To disable RADIUS authentication parameters, use the no form of this command. For more information on the radius-server command, refer to the Cisco ACNS Software Command Reference, Release 4.2.

RADIUS Authentication Redirection

The redirect option of the radius-server command redirects an authentication response to a different authentication server if an authentication request using the RADIUS server fails.

Note The rule command is relevant to RADIUS only if redirect has been configured.

The following example enables the RADIUS client, specifies a RADIUS server, specifies the RADIUS key, accepts retransmit defaults, and excludes the domain name, mydomain.net, from RADIUS authentication. The configuration is verified with the show radius-server and show rule all commands.
Console(config)# radius-server enable
Console(config)# radius-server host 172.16.90.121 
Console(config)# radius-server key myradiuskey
Console(config)# rule enable 
Console(config)# rule no-auth domain mydomain.net 
Console# show radius-server
Radius Configuration:
---------------------
Radius Authentication is on
    Timeout       = 5
    Retransmit    = 3
    Key           = ****
    Servers
    -------
    IP 172.16.90.121 Port =   1645    State: ENABLED
Console# show rule all
Rules Template Configuration
----------------------------
Rule Processing Enabled
rule no-auth domain mydomain.net
The following example disables RADIUS authentication on the Content Engine.
Console(config)# no radius-server enable
LDAP HTTP Request Authentication

System administrators can use the Content Engine to restrict user Internet access using an LDAP server for autentication purposes, which provides most of the services of the X.500 protocol with less complexity and overhead.

Use the ldap global configuration command to enable LDAP authentication. 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.2 software supports LDAP Version 2 and Version 3 and supports all LDAP features except for Secure Authentication and Security Layer (SASL).

Note HTTP authentication featuring RADIUS and LDAP existed in Cache software 2.x releases and was configured through the radius-server and ldap commands, respectively. For ACNS 4.1 and later 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 option exclude has 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 server command has the following added options: enable and version.

HTTP Request Considerations

When the Content Engine authenticates a user through a TACACS+, NTLM, RADIUS, or LDAP server, a record of that authentication is stored locally in the Content Engine RAM (authentication cache). As long as the authentication entry is retained, subsequent attempts to access restricted Internet content by that user do not require 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.

An NTLM or LDAP authenticated must belong to an access list in order to access requested content. See the "Group Authentication Using Access Control Lists" section to enable this feature. Figure 13-1 shows the path that an HTTP request takes through the Content Engine authentication and authorization scheme.

Note ACNS 4.2 software only allows group authorization using access control lists for users who have been authenticated using either an NTLM or an LDAP server for HTTP requests.

Figure 13-1 HTTP Request Authentication Flow Chart

Note All authentication schemes using NTLM, TACACS+, LDAP, and RADIUS servers, which may require different user IDs and passwords, are mutually exclusive. In other words, only one authentication scheme can be enabled at a time.

Group Authentication Using Access Control Lists

In ACNS 4.2 software you can also configure group authorization using an access control list (ACL) after a user has been authenticated against an NTLM or LDAP server. The use of this list configures a group privilege when the group accesses content provided by the Content Engine. In other words, using an ACL allows or prevents users from certain groups from viewing specific content. This authorization feature offers more granular access control by specifying that access is only allowed to certain groups.

Use the access-lists enable global configuration command to enable the use of an ACL.

Use the access-lists 300 command to permit or deny a group from accessing the Internet using the Content Engine. For instance, use the access-list 300 deny groupname marketing to prevent any user from the Marketing group from accessing content through the Content Engine.

In this example, you can display the configuration of the ACL by using the show access-lists 300 command.
ContentEngine# show access-lists 300 
  Access Control List Configuration
  ---------------------------------
    Access Control List is enabled
    Groupname-based List (300)
    1.  permit  groupname techpubs                        
    2.  permit  groupname acme1                           
    3.  permit  groupname engineering                     
    4.  permit  groupname sales                           
    5.  permit  groupname marketing                       
    6.  deny    groupname any                             
You can also display statistical information for the ACL using the show statistics access-lists command.
ContentEngine# show statistics access-lists 300 
    Access Control Lists Statistics         
    -----------------------------------------
      Groupname and username-based List (300)
        Number of requests:         1
        Number of deny responses:   0
        Number of permit responses: 1
ContentEngine#
You can also clear statistical information for the ACL with the clear statistics access-lists 300 command.

Access List Design Considerations

Access lists are built using the following design considerations:

•A user can belong to several groups.

•The maximum number of groups that a user can belong to is 15.

•A groupname is a case-sensitive string with mixed-case alphanumeric characters.

•Each groupname cannot exceed 32 characters.

•Groups in a groupname string are separared by commas.

•The total groupname string cannot exceed 128 characters.

In this example, four groups are defined under a groupname string called Groupname.
Groupname = "engineering1,engineering2,marketing,sales"
Note that in this example, the number of characters for the groups under the groupname string Groupname is less than 129 characters. The number of groups in the string equals 4. The number of characters in each group is less than 32 characters.

LDAP Group Authentication with Access Lists

To configure group authentication and authorization using an LDAP server and access control lists, follow these steps. In this scenario, LDAP group access is allowed to the Engineering, Marketing, and Sales groups in company XYZ. The following parameters are configured in the LDAP server for user John Smith from the Engineering group:
# John Smith
dn: cn=John Smith,ou=Engineering,dc=xyz,dc=com
cn: John Smith
sn: Smith
telephoneNumber: 1 408 123 4567
uid: jsmith
userpassword: john123
Note Users from the marketing and sales groups have similar parameters, allowing for changes to the organizational units and individual user administration settings.

Step 1 Access the CLI command interface and enable access to the LDAP server using the ldap server host global configuration command. Enter either a host name or an IP address. In the following example, the IP address of the LDAP server is used.
ContentEngine(config)# ldap server host 10.1.1.1
Step 2 Enter the base distinguished name of the starting point for the search in the LDAP database, using the ldap server base command. In this example, the search on the LDAP server is done on the strings "xyz" and "com".
ContentEngine(config)# ldap server base "dc=xyz,dc=com"
Note The LDAP server parameters on the match the settings on the Content Engine must match the settings on the LDAP server. In other words, the distinguished names on the LDP server must have dc=xyz, and dc=com for the preceding example.

Step 3 Enable LDAP server authentication using the ldap server enable command.
ContentEngine(config)# ldap server enable
Step 4 Permit access to groups within the base string xyz based on organizational units such as Marketing, Engineering, or Sales using the access-lists 300 permit groupname command. In this example, group access is allowed for any user in the Engineering, Marketing, and Sales groups. A user who does not belong to any of these groups is denied access with the access-lists 300 deny groupname any command.
ContentEngine(config)# access-lists 300 permit groupname Engineering
ContentEngine(config)# access-lists 300 permit groupname Marketing
ContentEngine(config)# access-lists 300 permit groupname Sales
ContentEngine(config)# access-lists 300 deny groupname any
Step 5 Enable the use of access lists on your Content Engine with the access-lists enable command in global configuration mode.
ContentEngine(config)# access-lists enable
NTLM Group Authentication with Access Lists

To configure group authentication and authorization using an NTLM server and access control lists, follow these steps. In this scenario, NTLM group access is allowed to the Engineering, Marketing, and Sales groups in company XYZ.

Step 1 Access the CLI command interface and enable access to the NTLM server using the ntlm server host global configuration command. Enter either a host name or an IP address. In the following example, the IP address of the NTLM server is used. This NTLM server is designated the primary server.
ContentEngine(config)# ntlm server host 10.1.1.1 primary
Step 2 Configure the NTLM server domain name with the ntlm server domain command.
ContentEngine(config)# ntlm server domain domain
Step 3 Enable NTLM server authentication using the ntlm server enable command.
ContentEngine(config)# ntlm server enable
Step 4 Permit access to groups based on organizational units such as Marketing, Engineering or Sales using the access-lists 300 permit groupname command. In this example, group access is allowed for any user in the Engineering, Marketing, and Sales groups. A user who does not belong to any of these groups is denied access with the access-lists 300 deny groupname any command.
ContentEngine(config)# access-lists 300 permit groupname Engineering
ContentEngine(config)# access-lists 300 permit groupname Marketing
ContentEngine(config)# access-lists 300 permit groupname Sales
ContentEngine(config)# access-lists 300 deny groupname any
Step 5 Enable the use of access lists on your Content Engine with the access-lists enable command in global configuration mode.
ContentEngine(config)# access-lists enable
Excluding Domains from HTTP Authentication Servers

To exclude domains from HTTP authentication servers, use the rule no-auth domain command. TACACS+, NTLM, RADIUS, or LDAP authentication takes place only if the site requested does not match the specified pattern.

Proxy Mode Server Authentication

The events listed below occur when the Content Engine is configured for HTTP request authentication and one of the following two scenarios is true:

•The Content Engine receives a proxy-style request from a client.

•The Content Engine receives a transparent (WCCP-style) request from a client and the Content Engine http authentication header command parameter is set to 407 (Proxy Authorization Required), because there is an upstream proxy.

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 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 whether 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 authentication 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 message to the client.

Transparent Mode Authentication

The events listed below occur when the Content Engine is configured for HTTP request authentication and both of the following are true:

•The Content Engine receives a redirected request from a client.

•The http authentication header command parameter is set to 401 (Unauthorized), because there is no upstream proxy.

1. The Content Engine searches its authentication cache to see whether 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 authentication 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 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.

Server Redundancy

Two authentication servers can be specified with the host option for NTLM, RADIUS, and LDAP, or server hostname option for TACACS+. These additional servers provide authentication redundancy and improved throughput, especially when Content Engine load-balancing schemes distribute the requests evenly between the servers. If the Content Engine cannot connect to any of the authentication servers, no authentication takes place and users who have not been previously authenticated are denied access.

Security Options

The Content Engine uses simple (nonencrypted) authentication to communicate with the authentication server. Future expansion may allow for more security options based on Secure Socket Layer (SSL), SASL, or certificate-based authentication.

Hierarchical Caching in Proxy Mode

In some cases, users are located at branch offices. A Content Engine (CE1) can reside with them in the branch office and be configured in proxy mode. Another Content Engine (CE2) in proxy mode or another HTTP-compatible proxy device can reside upstream, with a TACACS+, NTLM, RADIUS, or LDAP server available to both Content Engines or proxy devices 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 eight 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 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 HTTP request authentication 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 authentication server to authenticate user 2. Assuming authentication 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 authentication 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.

Note If you wish to avoid authentication on an upstream Content Engine after authentication is performed downstream, you can use the rule no-auth command to exclude the downstream Content Engine IP address.

Hierarchical Caching in Transparent Mode

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.

Hierarchical Caching, Content Engine in Transparent Mode with an Upstream Proxy

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.

Authentication Cache Size Adjustments

If the authentication cache is not large enough to accommodate all authenticated users at the same time, the Content Engine purges older entries that have not yet timed out. The Content Engine has a timeout value range from 1 to 1440 minutes. Its default timeout value is 480 minutes.

Use the http authentication cache command to configure the authentication cache size parameters if necessary.

The maximum number of entries that is maintained in authentication cache is 32000. The minimum number is 500. The default value is 16000. Use the http authentication max-entries command to configure this parameter if necessary.

The http authentication command has a header option that can be set to display a message to the client when authorization has failed. In this scenario you can choose http authentication header 401 (Unauthorized) or http authentication header 407 (Proxy Authorization Required). By default, the Content Engine authenticates cache loads based on the URL syntax of the incoming request.

Use the show http authentication command in EXEC mode to display the authentication cache parameters.

Transaction Logging

Once a user has been authenticated through TACACS+, LDAP, NTLM, or a RADIUS server, 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 
End-to-End Authentication

The ACNS 4.2 software Cache application supports both basic and NTLM end-to-end 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 Windows NT domain controller.

Basic End-to-End Authentication

The ACNS software Cache application can strip NTLM authentication headers to allow fallback to a basic-style authentication challenge against Microsoft Internet Information System (IIS) servers.

This feature is designed to allow browsers to authenticate against a Microsoft IIS web server that issues an NTLM-based challenge. NTLM is proprietary and undocumented. Removing the NTLM headers allows the browser to fall back on the basic authentication method. If IIS is configured to still accept basic authentication, IIS authentication credentials can proceed through a Content Engine, but with reduced security. Use the http authenticate-strip-ntlm global configuration command to enable stripping of NTLM headers.

NTLM End-to-End Authentication

The two levels of NTLM end-to-end support can be summarized as follows:

•NTLM pass-through service

If NTLM pass-through service is set on the server, the Content Engine sets up a secure persistent connection between the client and the server through the Content Engine. NTLM authentication messages pass through this virtual persistent connection. The Content Engine does not cache any object transferred on the virtual connection. All the client requests are served by the origin server.

•NTLM object caching

The ACNS 4.2 software Cache application 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 cacheable. 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.

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.

	Cisco ACNS Software Caching Configuration Guide, Release 4.2
	Chapter 13: Configuring Authentication
Cisco ACNS Software Caching Configuration Guide, Release 4.2 Cisco ACNS Software Caching Configuration Guide, Release 4.2 Preface Chapter 1: Cisco Cache Application Product Overview Chapter 2: Content Engine Management Configuration and Features Chapter 3: HTTP Caching Parameter Settings Chapter 4: Streaming Media Overview Parameter Settings Chapter 5: Transparent Caching Chapter 6: Proxy-Style Caching Chapter 7: Reverse Proxy Caching Chapter 8: Configuring a Primary Proxy Server Chapter 9: Configuring Windows Media Technologies Streaming Media Caching Chapter 10: Configuring RealProxy Streaming Media caching Chapter 11: Configuring URL Filtering Chapter 12: Configuring the Rules Template Chapter 13: Configuring Authentication Chapter 14: Configuring Transaction Logging Chapter 15: Configuring Network Management Chapter 16: Configuring TCP Stack Parameters Chapter 17: Miscellaneous Features Appendix A: Web Cache Communication Protocol Version 1 Appendix B: Web Cache Communication Protocol Version 2 Index	Download this chapter Chapter 13: Configuring Authentication Download the complete book Cisco ACNS Software Caching Configuration Guide, Release 4.2 (PDF - 3 MB) Table Of Contents Configuring Authentication and Authorization User Authentication and Authorization HTTP Request Authentication TACACS+ Authentication NTLM Authentication NTLM Authentication Transparency RADIUS HTTP Request Authentication RADIUS Authentication Redirection LDAP HTTP Request Authentication HTTP Request Considerations Group Authentication Using Access Control Lists LDAP Group Authentication with Access Lists NTLM Group Authentication with Access Lists Excluding Domains from HTTP Authentication Servers Proxy Mode Server Authentication Transparent Mode Authentication Server Redundancy Security Options Hierarchical Caching in Proxy Mode Hierarchical Caching in Transparent Mode Hierarchical Caching, Content Engine in Transparent Mode with an Upstream Proxy Authentication Cache Size Adjustments Transaction Logging End-to-End Authentication Basic End-to-End Authentication NTLM End-to-End Authentication Configuring Authentication and Authorization This chapter discusses authentication and authorization support on the Content Engine, and describes the HTTP request considerations when using authentication servers. This chapter contains the following sections: •User Authentication and Authorization •HTTP Request Authentication •End-to-End Authentication User Authentication and Authorization Authentication, also referred to as "login," is the act of verifying usernames and passwords. Authorization, or "configuration," refers to the setting of privileges for authenticated users in a network. Generally, authentication precedes authorization in a network. The authentication command configures both the authentication and authorization methods that govern login and configuration access to the Content Engine. Login and configuration privileges are maintained in three databases in ACNS 4.2 software: the local database, Terminal Access Controller Access Control System Plus (TACACS+) database, and Remote Authentication Dial-In User Service (RADIUS) database. If all databases are enabled, then all databases are queried; if the user data cannot be found in the first database queried, then the second and third databases are queried. The authentication login command specifies the method that determines whether the user has any level of permission to access the Content Engine. The authentication configuration command specifies the method that authorizes the user with privileged access (configuration access) to the Content Engine. The authentication login local and the authentication configuration local commands use a local database for authentication and authorization. The authentication login tacacs and authentication configuration tacacs commands use a remote TACACS+ server to determine the level of user access. Note The tacacs global configuration command and a TACACS+ server must be configured to use the TACACS+ authentication and authorization method. The authentication login radius and authentication configuration radius commands use a remote RADIUS server to determine the level of user access. Note The radius-server global configuration command and a RADIUS server must be configured to use the RADIUS authentication and authorization method. By default, the local method is enabled, with TACACS+ and RADIUS both disabled for login and configuration. Whenever TACACS+ and RADIUS are disabled, local is automatically enabled. TACACS+, RADIUS, and local methods can be enabled at the same time. The primary option specifies the first method to attempt for login and configuration purposes; the secondary option specifies the method to use if the primary method fails. The tertiary option specifies the method to use if both primary and secondary methods fail. If all methods of an authentication login or authentication configuration command are configured as primary, or all as secondary or tertiary, local 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 primary ContentEngine(config)# authentication login local enable secondary ContentEngine(config)# authentication login radius enable tertiary ContentEngine(config)# authentication configuration tacacs enable primary ContentEngine(config)# authentication configuration local enable secondary ContentEngine(config)# authentication configuration radius enable tertiary This is an example of the show authentication user command: ContentEngine# show authentication user Login Authentication: Console/Telnet Session ----------------------------- ----------------------- local enabled (secondary) radius enabled (tertiary) tacacs enabled (primary) Configuration Authentication: Console/Telnet Session ----------------------------- ----------------------- local enabled (secondary) radius enabled (tertiary) tacacs enabled (primary) HTTP Request Authentication The ACNS 4.2 software Cache application supports TACACS+, Microsoft NT LAN Manager (NTLM), Lightweight Directory Access Protocol (LDAP), and RADIUS server HTTP request authentication. In the case of NTLM, HTTP request authentication authenticates a user's domain, username, and password with a preconfigured primary domain controller (PDC) before allowing requests from the user to be served by the Content Engine. TACACS+ Authentication The TACACS+ database validates users before they gain access to a Content Engine. 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. ACNS 4.1 or later software supports TACACS+ only and not TACACS or Extended TACACS. To enable TACACS+ for HTTP request authentication, use the tacacs enable global configuration configuration command. This authentication is independent of the user authentication and authorization options shown in the "User Authentication and Authorization" section. Note You must configure a TACACS+ server with the tacacs server global configuration command before you can enable the TACACS+ authentication method. The Users GUI page or the user global configuration commands provide 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. 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 that 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 that 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 NTLM Authentication The NTLM protocol can be used to authenticate and block user access to the Internet. When a user logs in to a Windows NT or a Windows 2000 domain and starts a browser, the authentication information is stored by the browser and later used as NTLM credentials to access the Internet. The browser sends the NTLM credentials with the domain name to the ACNS cache, which in turns sends a request to the Windows NT domain controller to check the validity of the user in the domain. If the user is not a valid user in the domain, then the request to access the Internet is denied. If authentication succeeds, the source IP address is entered in the authentication cache. Future requests from this IP address are not challenged until the authentication cache entry expires, or is cleared. Use the ntlm server command to enable NTLM authentication and configure the NTLM server domain name, NT primary domain controller (PDC) name or IP address, and optionally set the host name or address as primary or secondary. Before invoking an NTLM authentication request, make sure that the following conditions exist. •The NTLM primary domain controller has an entry in the Domain Name System (DNS) that matches its NetBIOS-named computer account. •The primary domain controller is both forward and reverse DNS-resolvable. •The domain name configured on the Content Engine matches the domain of which the primary domain controller is a part. 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 NTLM Authentication Transparency For clients within the domain using the Internet Explorer browser in proxy mode, authentication is "popless"; this is, the user is not prompted with a dialog box to enter a username and password. In transparent mode, authentication is transparent only if the Internet options security settings are customized and set to User Authentication > Logon > Automatic logon with current username and password. This example configures a Content Engine for NTLM request authentication. Console(config)# ntlm server enable Console(config)# ntlm server domain cisco_abc Console(config)# ntlm server host 172.16.10.10 primary Console(config)# ntlm server host 172.16.10.12 secondary Console# show ntlm Primary: 172.16.10.10 Secondary: 172.16.10.12 State: Enabled Domain name: cisco_abc RADIUS HTTP Request Authentication RADIUS authentication clients reside on the Content Engine running ACNS 4.2 software. When enabled, these clients send authentication requests to a central RADIUS server, which contains user authentication and network service access information. To configure RADIUS parameters, use the radius-server command in global configuration mode. To disable RADIUS authentication parameters, use the no form of this command. For more information on the radius-server command, refer to the Cisco ACNS Software Command Reference, Release 4.2. RADIUS Authentication Redirection The redirect option of the radius-server command redirects an authentication response to a different authentication server if an authentication request using the RADIUS server fails. Note The rule command is relevant to RADIUS only if redirect has been configured. The following example enables the RADIUS client, specifies a RADIUS server, specifies the RADIUS key, accepts retransmit defaults, and excludes the domain name, mydomain.net, from RADIUS authentication. The configuration is verified with the show radius-server and show rule all commands. Console(config)# radius-server enable Console(config)# radius-server host 172.16.90.121 Console(config)# radius-server key myradiuskey Console(config)# rule enable Console(config)# rule no-auth domain mydomain.net Console# show radius-server Radius Configuration: --------------------- Radius Authentication is on Timeout = 5 Retransmit = 3 Key = ** Servers ------- IP 172.16.90.121 Port = 1645 State: ENABLED Console# show rule all Rules Template Configuration ---------------------------- Rule Processing Enabled rule no-auth domain mydomain.net The following example disables RADIUS authentication on the Content Engine. Console(config)# no radius-server enable LDAP HTTP Request Authentication System administrators can use the Content Engine to restrict user Internet access using an LDAP server for autentication purposes, which provides most of the services of the X.500 protocol with less complexity and overhead. Use the ldap global configuration command to enable LDAP authentication. 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.2 software supports LDAP Version 2 and Version 3 and supports all LDAP features except for Secure Authentication and Security Layer (SASL). Note HTTP authentication featuring RADIUS and LDAP existed in Cache software 2.x releases and was configured through the radius-server and ldap commands, respectively. For ACNS 4.1 and later 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 option exclude has 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 server command has the following added options: enable and version. HTTP Request Considerations When the Content Engine authenticates a user through a TACACS+, NTLM, RADIUS, or LDAP server, a record of that authentication is stored locally in the Content Engine RAM (authentication cache). As long as the authentication entry is retained, subsequent attempts to access restricted Internet content by that user do not require 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. An NTLM or LDAP authenticated must belong to an access list in order to access requested content. See the "Group Authentication Using Access Control Lists" section to enable this feature. Figure 13-1 shows the path that an HTTP request takes through the Content Engine authentication and authorization scheme. Note ACNS 4.2 software only allows group authorization using access control lists for users who have been authenticated using either an NTLM or an LDAP server for HTTP requests. Figure 13-1 HTTP Request Authentication Flow Chart Note All authentication schemes using NTLM, TACACS+, LDAP, and RADIUS servers, which may require different user IDs and passwords, are mutually exclusive. In other words, only one authentication scheme can be enabled at a time. Group Authentication Using Access Control Lists In ACNS 4.2 software you can also configure group authorization using an access control list (ACL) after a user has been authenticated against an NTLM or LDAP server. The use of this list configures a group privilege when the group accesses content provided by the Content Engine. In other words, using an ACL allows or prevents users from certain groups from viewing specific content. This authorization feature offers more granular access control by specifying that access is only allowed to certain groups. Use the access-lists enable global configuration command to enable the use of an ACL. Use the access-lists 300 command to permit or deny a group from accessing the Internet using the Content Engine. For instance, use the access-list 300 deny groupname marketing to prevent any user from the Marketing group from accessing content through the Content Engine. In this example, you can display the configuration of the ACL by using the show access-lists 300 command. ContentEngine# show access-lists 300 Access Control List Configuration --------------------------------- Access Control List is enabled Groupname-based List (300) 1. permit groupname techpubs 2. permit groupname acme1 3. permit groupname engineering 4. permit groupname sales 5. permit groupname marketing 6. deny groupname any You can also display statistical information for the ACL using the show statistics access-lists command. ContentEngine# show statistics access-lists 300 Access Control Lists Statistics ----------------------------------------- Groupname and username-based List (300) Number of requests: 1 Number of deny responses: 0 Number of permit responses: 1 ContentEngine# You can also clear statistical information for the ACL with the clear statistics access-lists 300 command*. Access List Design Considerations Access lists are built using the following design considerations: •A user can belong to several groups. •The maximum number of groups that a user can belong to is 15. •A groupname is a case-sensitive string with mixed-case alphanumeric characters. •Each groupname cannot exceed 32 characters. •Groups in a groupname string are separared by commas. •The total groupname string cannot exceed 128 characters. In this example, four groups are defined under a groupname string called Groupname. Groupname = "engineering1,engineering2,marketing,sales" Note that in this example, the number of characters for the groups under the groupname string Groupname* is less than 129 characters. The number of groups in the string equals 4. The number of characters in each group is less than 32 characters. LDAP Group Authentication with Access Lists To configure group authentication and authorization using an LDAP server and access control lists, follow these steps. In this scenario, LDAP group access is allowed to the Engineering, Marketing, and Sales groups in company XYZ. The following parameters are configured in the LDAP server for user John Smith from the Engineering group: # John Smith dn: cn=John Smith,ou=Engineering,dc=xyz,dc=com cn: John Smith sn: Smith telephoneNumber: 1 408 123 4567 uid: jsmith userpassword: john123 Note Users from the marketing and sales groups have similar parameters, allowing for changes to the organizational units and individual user administration settings. Step 1 Access the CLI command interface and enable access to the LDAP server using the ldap server host global configuration command. Enter either a host name or an IP address. In the following example, the IP address of the LDAP server is used. ContentEngine(config)# ldap server host 10.1.1.1 Step 2 Enter the base distinguished name of the starting point for the search in the LDAP database, using the ldap server base command. In this example, the search on the LDAP server is done on the strings "xyz" and "com". ContentEngine(config)# ldap server base "dc=xyz,dc=com" Note The LDAP server parameters on the match the settings on the Content Engine must match the settings on the LDAP server. In other words, the distinguished names on the LDP server must have dc=xyz, and dc=com for the preceding example. Step 3 Enable LDAP server authentication using the ldap server enable command. ContentEngine(config)# ldap server enable Step 4 Permit access to groups within the base string xyz based on organizational units such as Marketing, Engineering, or Sales using the access-lists 300 permit groupname command. In this example, group access is allowed for any user in the Engineering, Marketing, and Sales groups. A user who does not belong to any of these groups is denied access with the access-lists 300 deny groupname any command. ContentEngine(config)# access-lists 300 permit groupname Engineering ContentEngine(config)# access-lists 300 permit groupname Marketing ContentEngine(config)# access-lists 300 permit groupname Sales ContentEngine(config)# access-lists 300 deny groupname any Step 5 Enable the use of access lists on your Content Engine with the access-lists enable command in global configuration mode. ContentEngine(config)# access-lists enable NTLM Group Authentication with Access Lists To configure group authentication and authorization using an NTLM server and access control lists, follow these steps. In this scenario, NTLM group access is allowed to the Engineering, Marketing, and Sales groups in company XYZ. Step 1 Access the CLI command interface and enable access to the NTLM server using the ntlm server host global configuration command. Enter either a host name or an IP address. In the following example, the IP address of the NTLM server is used. This NTLM server is designated the primary server. ContentEngine(config)# ntlm server host 10.1.1.1 primary Step 2 Configure the NTLM server domain name with the ntlm server domain command. ContentEngine(config)# ntlm server domain domain Step 3 Enable NTLM server authentication using the ntlm server enable command. ContentEngine(config)# ntlm server enable Step 4 Permit access to groups based on organizational units such as Marketing, Engineering or Sales using the access-lists 300 permit groupname command. In this example, group access is allowed for any user in the Engineering, Marketing, and Sales groups. A user who does not belong to any of these groups is denied access with the access-lists 300 deny groupname any command. ContentEngine(config)# access-lists 300 permit groupname Engineering ContentEngine(config)# access-lists 300 permit groupname Marketing ContentEngine(config)# access-lists 300 permit groupname Sales ContentEngine(config)# access-lists 300 deny groupname any Step 5 Enable the use of access lists on your Content Engine with the access-lists enable command in global configuration mode. ContentEngine(config)# access-lists enable Excluding Domains from HTTP Authentication Servers To exclude domains from HTTP authentication servers, use the rule no-auth domain command. TACACS+, NTLM, RADIUS, or LDAP authentication takes place only if the site requested does not match the specified pattern. Proxy Mode Server Authentication The events listed below occur when the Content Engine is configured for HTTP request authentication and one of the following two scenarios is true: •The Content Engine receives a proxy-style request from a client. •The Content Engine receives a transparent (WCCP-style) request from a client and the Content Engine http authentication header command parameter is set to 407 (Proxy Authorization Required), because there is an upstream proxy. 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 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 whether 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 authentication 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 message to the client. Transparent Mode Authentication The events listed below occur when the Content Engine is configured for HTTP request authentication and both of the following are true: •The Content Engine receives a redirected request from a client. •The http authentication header command parameter is set to 401 (Unauthorized), because there is no upstream proxy. 1. The Content Engine searches its authentication cache to see whether 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 authentication 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 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. Server Redundancy Two authentication servers can be specified with the host option for NTLM, RADIUS, and LDAP, or server hostname option for TACACS+. These additional servers provide authentication redundancy and improved throughput, especially when Content Engine load-balancing schemes distribute the requests evenly between the servers. If the Content Engine cannot connect to any of the authentication servers, no authentication takes place and users who have not been previously authenticated are denied access. Security Options The Content Engine uses simple (nonencrypted) authentication to communicate with the authentication server. Future expansion may allow for more security options based on Secure Socket Layer (SSL), SASL, or certificate-based authentication. Hierarchical Caching in Proxy Mode In some cases, users are located at branch offices. A Content Engine (CE1) can reside with them in the branch office and be configured in proxy mode. Another Content Engine (CE2) in proxy mode or another HTTP-compatible proxy device can reside upstream, with a TACACS+, NTLM, RADIUS, or LDAP server available to both Content Engines or proxy devices 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 eight 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 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 HTTP request authentication 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 authentication server to authenticate user 2. Assuming authentication 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 authentication 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. Note If you wish to avoid authentication on an upstream Content Engine after authentication is performed downstream, you can use the rule no-auth command to exclude the downstream Content Engine IP address. Hierarchical Caching in Transparent Mode 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. Hierarchical Caching, Content Engine in Transparent Mode with an Upstream Proxy 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. Authentication Cache Size Adjustments If the authentication cache is not large enough to accommodate all authenticated users at the same time, the Content Engine purges older entries that have not yet timed out. The Content Engine has a timeout value range from 1 to 1440 minutes. Its default timeout value is 480 minutes. Use the http authentication cache command to configure the authentication cache size parameters if necessary. The maximum number of entries that is maintained in authentication cache is 32000. The minimum number is 500. The default value is 16000. Use the http authentication max-entries command to configure this parameter if necessary. The http authentication command has a header option that can be set to display a message to the client when authorization has failed. In this scenario you can choose http authentication header 401 (Unauthorized) or http authentication header 407 (Proxy Authorization Required). By default, the Content Engine authenticates cache loads based on the URL syntax of the incoming request. Use the show http authentication command in EXEC mode to display the authentication cache parameters. Transaction Logging Once a user has been authenticated through TACACS+, LDAP, NTLM, or a RADIUS server, 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 End-to-End Authentication The ACNS 4.2 software Cache application supports both basic and NTLM end-to-end 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 Windows NT domain controller. Basic End-to-End Authentication The ACNS software Cache application can strip NTLM authentication headers to allow fallback to a basic-style authentication challenge against Microsoft Internet Information System (IIS) servers. This feature is designed to allow browsers to authenticate against a Microsoft IIS web server that issues an NTLM-based challenge. NTLM is proprietary and undocumented. Removing the NTLM headers allows the browser to fall back on the basic authentication method. If IIS is configured to still accept basic authentication, IIS authentication credentials can proceed through a Content Engine, but with reduced security. Use the http authenticate-strip-ntlm global configuration command to enable stripping of NTLM headers. NTLM End-to-End Authentication The two levels of NTLM end-to-end support can be summarized as follows: •NTLM pass-through service If NTLM pass-through service is set on the server, the Content Engine sets up a secure persistent connection between the client and the server through the Content Engine. NTLM authentication messages pass through this virtual persistent connection. The Content Engine does not cache any object transferred on the virtual connection. All the client requests are served by the origin server. •NTLM object caching The ACNS 4.2 software Cache application 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 cacheable. 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. 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.
	© 1992-2009 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.