Table Of Contents

Configuring Request Authentication and Authorization

Understanding Request Authentication and Authorization for Content Engines

About Proxied Authentication and Pass-Through Authentication Modes

Content Delivery Protocols Supported

Authentication Mechanisms Supported

About Authenticating Windows Media Requests

About Authenticating and Authorizing HTTP Requests

Using ACLs for Group-Based Authorization

Using Rules for Group-Based Authorization

Using Microsoft Active Directory for Group Searches

Using the Content Engine Authentication Cache

Understanding Proxy Server Mode HTTP Request Authentication

Understanding Transparent Mode HTTP Request Authentication

About Authenticating Native FTP Requests

Considerations When Configuring Native FTP Proxied Authentication

Configuring Request Authentication on Centrally Managed Content Engines

Configuring Authentication Server Settings

Configuring LDAP Server Settings

Configuring NTLM Server Settings

Configuring the NTLM Server LDAP Memory Cache Settings

Support for No Default NTLM Domain

About NTLM Load Balancing for HTTP Request Authentication

About NTLM Failover for HTTP Request Authentication

Configuring NTLM Allowed Domains for HTTP Request Authentication

Configuring RADIUS Server Settings

Configuring TACACS+ Server Settings

Setting the Authentication Scheme for Request Authentication

Configuring Request Authentication and Authorization

---

Request authentication and authorization is a means to manage employee use of the Internet and restrict access to online content.

This chapter explains how to configure request authentication and authorization for serving content from Content Engines in a centrally managed ACNS network. It contains the following sections:

•Understanding Request Authentication and Authorization for Content Engines

•Configuring Request Authentication on Centrally Managed Content Engines

•Configuring Authentication Server Settings

•Setting the Authentication Scheme for Request Authentication

---

Note In the ACNS network, Content Engines both authenticate themselves as clients when acquiring content from origin servers and must be prepared to authenticate others when serving content. Authentication for acquiring content is discussed in Chapter 6, "Configuring the ACNS Network for Content Acquisition." (See the "Authentication Support" section on page 6-43.)

---

---

Note Content request authentication and authorization is independent of login (user) authentication and authorization. For information about login authentication and authorization, see Chapter 12, "Configuring Login Authentication, Configuration Authorization, and Accounting."

---

Understanding Request Authentication and Authorization for Content Engines

Request authentication and authorization controls the serving of content through the Content Engine. When a Content Engine receives a request to serve content, it must determine whether to allow or deny that request. The determination to allow or deny the request might be made by the Content Engine itself, or it might be made by an external authentication service. If the request is allowed, the Content Engine undertakes to serve that content.

About Proxied Authentication and Pass-Through Authentication Modes

In making content request authentication decisions, ACNS software supports two modes of operation: proxied authentication and pass-through authentication. In proxied authentication mode, the Content Engine challenges the client for credentials, collects the response, and then passes that information to another authentication service, which will decide whether to allow or deny the request. The authentication service queries the configured user database to validate the credentials. Proxied authentication is available for HTTP and native FTP requests.

For a discussion about configuring 401 and 407 response messages in the proxy authentication header, see the "Understanding Proxy Server Mode HTTP Request Authentication" section and the "Understanding Transparent Mode HTTP Request Authentication" section.

---

Note In this chapter, HTTP request is used to refer collectively to requests over HTTP that include HTTP, FTP-over-HTTP, and HTTPS-over-HTTP requests. (See the "About Authenticating and Authorizing HTTP Requests" section.)

---

---

Note Native FTP requests use the FTP protocol (FTP-over-FTP) rather than FTP-over-HTTP. Native FTP can be used in proxied authentication mode only. (See the "About Authenticating Native FTP Requests" section.)

---

In pass-through authentication mode, the origin server challenges the client for credentials, and the Content Engine passes the authentication challenge to the client. If the origin server issues an HTTP basic authentication challenge, the client will prompt the end user for the credentials. If the origin server issues an NTLM challenge, the client will automatically respond with the network login credentials. The Content Engine then forwards the client challenge response to the upstream origin server. The origin server validates the credentials against the user database (or some other service). The Content Engine learns the net result of the decision (whether to allow or deny) based on the response code of the origin server. The Content Engine is not involved in the credential collection, evaluation, or validation.

Occasionally a website (origin server) requires the client's IP address to authenticate a client. This is typically used in older web servers and is not the preferred solution for client authentication. However, for such older websites there must be a way for the Content Engine "to get out of the way" between the client and the web server so that the client can be authenticated. The authentication traffic bypass feature can be used in these cases. For information on this topic, see the "Configuring Authentication Traffic Bypass" section on page 4-22.

Table 15-1 summarizes the relationship between protocols, challenge and response authentication mechanisms, authentication modes, and authentication decision services for the Content Engine as a server. It shows that in pass-through authentication mode, each authentication challenge mechanism that is supported can be passed only to an authentication server with a matching authentication service. For proxied authentication, the table shows that basic authentication of HTTP requests can be used with any of the supported decision services; NTLM authentication of HTTP can be proxied only to an NTLM service; and neither of the streaming protocols (MMS or RTSP) support proxied authentication. Native FTP requests can be proxied to LDAP, RADIUS, and TACAS+ decision services.

Table 15-1 Authentication for Content Delivery—Content Engine as Server

Protocol	Pass-Through Authentication Mode		Proxied Authentication Mode
	Auth. Mechanism	Decision Service	to NTLM Decision Service	to LDAP Decision Service	to RADIUS Decision Service	to TACACS+ Decision Service
HTTP1	Basic	to basic	Yes	Yes	Yes	Yes
	NTLM	to NTLM	Yes	No	No	No
FTP native	—	—	No	Yes	Yes	Yes
MMS	Basic	to basic	No	No	No	No
	NTLM	to NTLM	No	No	No	No
RTSP	Basic	to basic	No	No	No	No

1 HTTP refers collectively to HTTP, FTP-over-HTTP, and HTTPS-over-HTTP.

Content Delivery Protocols Supported

In ACNS software, four different content delivery protocols support authentication: HTTP, native FTP, MMS, and RTSP. These protocols are compatible with the following challenge and response authentication mechanisms:

•HTTP and MMS are compatible with both basic and NTLM authentication mechanisms. (See the "About NTLM Authentication" section.)

•RTSP is compatible with basic authentication only. (See the "About Basic Authentication" section.)

•Native FTP supports neither basic nor NTLM challenge and response authentication mechanisms.

With regard to supported protocols, note the following release-specific information:

•ACNS 5.2 software and later releases support HTTP request authentication. Throughout this chapter, the term HTTP request refers collectively to requests over HTTP that include HTTP, FTP-over-HTTP, and HTTPS-over-HTTP requests. (For more information, see the "About Authenticating and Authorizing HTTP Requests" section.")

•ACNS 5.4 software and later releases include proxy authentication of nontransparent native FTP requests. (That is, authentication of FTP-over-FTP requests from such FTP clients as a Reflection X client or a UNIX command line program by the Content Engine that is acting as the FTP proxy.) (For more information, see the "About Authenticating Native FTP Requests" section.)

•ACNS 5.4 software and later releases enable you to use IP access control lists (ACLs) to control access for FTP native request (for example, enable the Content Engine that is acting as an FTP proxy to grant or deny access requests for incoming FTP connections from such FTP clients as a Reflection X client or a UNIX command line program). (For more information, see the "Using IP ACLs to Control FTP Access" section on page 19-19.)

Authentication Mechanisms Supported

The Content Engine in proxied authentication mode supports both basic and NTLM authentication challenges.

About Basic Authentication

Basic authentication is a simple challenge and response authentication mechanism. When basic authentication is used, credentials, such as username and password, are transmitted to the origin server in clear text format. For this reason, basic authentication poses some security risks.

About NTLM Authentication

Windows NT LAN Manager (NTLM) is the challenge and response authentication mechanism used by Microsoft browsers (Internet Explorer), proxies, and web servers (IIS). When NTLM is used, clients encrypt the server challenge with their password hash and send the response to the server for validation. The main advantage of using NTLM for HTTP request authentication is that NTLM sends the password in an encrypted format to the server, which is more secure than transmitting in clear text across the Internet as is the case with basic authentication.

NTLM support on the Content Engine includes the following three types of support: (1) NTLM to NTLM pass-through authentication support, (2) NTLM proxied authentication of HTTP requests, and (3) NTLM group information query for authorization purposes. (See Table 15-1.)

When the Content Engine is configured to use the NTLM challenge response mechanism, a preconfigured primary domain controller (PDC) validates the user's domain, username, and password before it allows the Content Engine to serve the request. In ACNS 5.2 software and later releases you can specify the list of domains that are allowed to perform NTLM authentication through the Content Engine.

NTLM Version 1 and 2 Support on the Content Engine

ACNS 5.4 software supports both NTLM version 1 and version 2 for both pass-through and proxied authentication of HTTP requests. (Earlier ACNS releases support NTLM version 1 only.)

NTLM version 2 is the successor to NTLM version 1 and is more secure than NTLM version 1. The algorithm that is used by NTLM version 2 to encrypt the challenge is more complex than the algorithm used by NTLM version 1, and the NTLM version 2-encrypted response includes a timestamp to prevent replay attacks.

Unlike NTLM version 1, NTLM version 2 is not negotiated between the client and the server (or proxy), but it is configured separately on Windows-based clients and servers by modifying a registry variable. (For information about how to change a Microsoft Windows client registry or a Windows server registry, see your Microsoft Windows documentation.)

When an HTTP response to the client indicates that the server (or the proxy) requires authentication, and the NTLM credentials are accepted, the client generates the appropriate NTLM response based on the client configuration:

•If NTLM version 1 is configured on the client, the client generates an NTLM version 1 response when it receives the server challenge.

•If NTLM version 2 is configured on the client, the client generates an NTLM version 2 response when it receives the server challenge.

In the ACNS network, it is important that the NTLM version configurations be kept in sync between the client, proxy, and server. By default, NTLM version 2 is disabled on the Content Engine, and the Content Engine automatically uses NTLM version 1, unless you enable NTLM version 2.

To enable the Content Engine to use NTLM version 2 to communicate with a specific NTLM server, use the v2 option of the ntlm server host global configuration command, or choose the v2 option in the Content Distribution Manager GUI. When you enter the v2 command option, you are specifying that the Content Engine should use NTLM version 2 for request authentication with that particular NTLM server.

Specifying that the Content Engine use NTLM version 2 when communicating with a specific NTLM host server is especially important for basic authentication because during basic authentication the Content Engine generates the NTLM response and communicates directly with the NTLM server.

In the following example, the Content Engine is configured to use a host list that consists of eight NTLM servers:

ContentEngine(config)# ntlm server host 172.16.10.10

ContentEngine(config)# ntlm server host 172.16.10.12

ContentEngine(config)# ntlm server host 172.16.10.14

ContentEngine(config)# ntlm server host 172.16.10.16

ContentEngine(config)# ntlm server host 172.16.10.18

ContentEngine(config)# ntlm server host 172.16.10.20

ContentEngine(config)# ntlm server host 172.16.10.22

ContentEngine(config)# ntlm server host 172.16.10.24

---

Note In software releases that do not support NTLM version 2, the Content Engine will fail to authenticate the client if the client attempts to use NTLM version 2.

---

---

Note In ACNS 5.4 software and later releases, when NTLM version 2 is enabled on the Content Engine, if the domain controller accepts an NTLM version 1 response, the Content Engine will successfully authenticate the client if the client is using NTLM version 1.

---

NTLM Version 2 Pass-Through Authentication Support for NTLM-Enabled Browsers

If the Content Engine is using ACNS 5.4 software or a later release, and the client browser is configured for NTLM version 2, then pass-through authentication and proxied authentication are both supported.

For pass-through authentication, the following process occurs:

1. After the client browser receives an NTLM challenge from the Content Engine, the client browser generates an NTLM version 2 response and sends it to the Content Engine.

2. The Content Engine performs the pass-through authentication, and forwards the NTLM version 2 response to the domain controller that sent the Content Engine the authentication challenge.

3. The Content Engine grants or denies the client access to the requested content based on the domain controller decision.

For proxied authentication, after the user is validated by the domain controller, the Content Engine saves the client username and domain name information in its authentication cache and does not challenge future requests from the same IP address. (See the "Using the Content Engine Authentication Cache" section.)

NTLM Version 2 Proxied Authentication Support for Non-NTLM Enabled Browsers

With non-NTLM-enabled browsers (that is, browsers that must rely on basic authentication) you can configure the Content Engine to communicate with the domain controller using NTLMv2 and thereby prevent the Content Engine from passing clear-text passwords over the network.

To have the Content Engine use NTLMv2 to communicate with the domain controller, you must satisfy all of the following conditions:

•The Content Engine is configured to use NTLM version 2.

•The Content Engine is using ACNS 5.4 software or a later release.

•Basic authentication is not disabled on the Content Engine.

If you set up these conditions, when the client browser receives an HTTP response from the Content Engine that indicates that client authentication is required, the client browser performs basic authentication instead of NTLM authentication. The client browser sends the user credentials to the Content Engine in clear text over the network. The Content Engine requests the challenge from the domain controller, generates an NTLM version 2 response using the password, and then sends the NTLM version 2 response to the domain controller for validation. (See the "NTLM Version 1 and 2 Support on the Content Engine" section.)

---

Note Even though the client browser sends the Content Engine its password in clear text, the Content Engine does not forward the clear-text password over the network to the domain controller.

---

About Authenticating Windows Media Requests

ACNS 5.2 software and later releases include pass-through basic and NTLM authentication support for MMS requests from Windows Media clients. ACNS 5.3 software and later releases include pass-through basic authentication support for Windows Media RTSP requests from Windows Media 9 players. With this support, the Content Engine establishes a tunnel between the client and the origin server for the origin server to authenticate the client. The Content Engine does a pass through and does not function as the proxy authentication server.

When the Content Engine is operating in direct proxy routing mode, the Content Engine Windows Media 9 server supports two authentication mechanisms for pass-through authentication of WMT requests:

•Anonymous authentication

•Network authentication

–Negotiates plug-in (NTLM or Kerberos) authentication

–Digests plug-in authentication

About Authenticating and Authorizing HTTP Requests

Organizations can use HTTP request authentication as a means to restrict access to online content. If HTTP authentication is configured on a Content Engine, the Content Engine checks a remote database (for example, a RADIUS, TACACS+, LDAP, or NTLM database) for user password authentication to determine if the user should be granted or denied access to the requested content.

For example, the BigCorp company may want to limit Internet access to its employees and not allow their temporary employees to access the web. In this scenario, BigCorp has placed a Content Engine at their Internet gateway. The Content Engine is being used to enforce the company's employee Internet access policy. When the Content Engine receives a client request to access content that is served through the Content Engine, the following occurs:

1. The Content Engine sends an authentication challenge to the client, and prompts the client to enter authentication information such as the username and password.

2. The Content Engine communicates with the AAA server to determine if the supplied authentication information is valid.

3. Based on the responses from the AAA server, the following occurs:

a. If the AAA server validates the user, the Content Engine allows the request to go through (that is, it allows the client to access the requested content).

b. If the AAA server does not validate the user, the Content Engine denies the request and sends the client an authentication failed message.

Using ACLs for Group-Based Authorization

Organizations that want to exercise more control can use group-based authorization (for NTLM and LDAP users) in addition to HTTP authentication. In the ACNS 5.x software, you can specify which groups of users are allowed to access the Internet and which groups are not allowed by creating access control lists (ACLs).

When you configure the Content Engine for group-based authorization, the Content Engine asks the AAA server not only whether clients are who they claim to be but also which groups they belong to. The Content Engine then checks its ACLs to determine if the group that the user belongs to should be granted or denied access to the requested content.

Using Rules for Group-Based Authorization

The Content Engine also supports group-based rules for group-based authorization. With this feature, you can require that end users who are making an HTTP request be authenticated by an external AAA server, and then authorized by the configured Rules Template.

---

Note Group-based authorization occurs only after HTTP request authentication has occurred.

---

The Rules Template feature allows you to configure a set of rules, each clearly identified by an action and a pattern or a group of patterns that the Content Engine uses to filter HTTP requests, as well as HTTPS, MMS, and RTSP requests. If you have enabled the Rules Template feature on the Content Engine and configured rules for the Content Engine, the Content Engine checks every incoming client request to determine if a rule pattern matches the requested content. If a rule pattern matches the given request, the Content Engine uses the specified action (or policy) to filter this incoming content.

In the ACNS 5.2 software release, three new rule patterns were added (groupname, username, and groupname-regex). These new rule patterns support access control policies that are based on the group name and username of the authenticated NTLM and LDAP users. Rules based on group names apply to users who have been authenticated through NTLM and LDAP. Rules based on usernames apply to users who are authenticated through LDAP, NTLM, RADIUS, and TACACS+, which are request authentication methods that involve a username for authentication.

Figure 15-1 shows how HTTP request authentication and group-based authorization can be used as mechanisms to control access to content.

Figure 15-1 HTTP Request Authentication and Group-Based Authorization

Using Microsoft Active Directory for Group Searches

A feature used with group-based authorization, Microsoft Active Directory is a software application that runs on a Windows 2000 server. An Active Directory (AD) database is a user database that resides on a Windows 2000 server that is running the Microsoft Active Directory program. The LDAP client on a Content Engine provides LDAP support for Active Directory group searches.

---

Note Microsoft Active Directory only supports LDAP version 3. By default, the Content Engine uses LDAP version 2. Therefore, configure the Content Engine to use LDAP version 3 before enabling the LDAP Active Directory feature on the Content Engine.

---

In ACNS software, Release 5.1 and later releases, you can retrieve nested group names using an LDAP recursive search and apply all the access lists configured for the nested groups. When you use nested groups with Active Directory servers, the policies configured for parent groups are automatically applied to members in subgroups.

The following items can be used to trigger an Active Directory group search:

•Group name-based access lists are configured.

•Group-based rules are configured in the Rules Template.

•ICAP is configured to append the authenticated-group header.

•SmartFilter is enabled on the Content Engine.

Using the Content Engine Authentication Cache

Another area of access control is the caching of authenticated content. That is, if the website requires client authentication before passing an object to the client, and the object is cached on the Content Engine, then the Content Engine authenticates the client before delivering the object to another client.

---

Note The Content Engine must also guarantee that if it caches any objects that required client authentication (that is, if it caches authenticated content), then it will not deliver cached authenticated content to other clients unless those clients are authenticated to access the cached content.

---

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 the authentication server database. When the Content Engine authenticates a user through an authentication 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 particular user do not require authentication server lookups.

The Content Engine routing method being used affects the way authenticated content is entered and indexed in the authentication cache. The routing methods supported for HTTP request authentication are direct proxy routing and transparent WCCP-enabled router redirection. The Content Engine stores and indexes authentication records differently, depending on the routing method being used, as follows:

•When the Content Engine is operating in direct proxy routing mode, it uses the client's user ID as a key for the its authentication cache.

When LDAP, RADIUS, and TACACS+ are used in direct proxy routing mode, the authentication record kept in the authentication cache is indexed by the username and the password entered. The username is entered with each client GET request.

•When the Content Engine is operating in transparent WCCP-enabled router redirection mode, it uses the client's IP address as a key for its authentication cache.

When LDAP, RADIUS, and TACACS+ are used in transparent WCCP-enabled router redirection mode, the authentication record is indexed by the IP address of the Content Engine that is sending the request in transparent mode. The client credentials are only submitted upon challenge, not with each request.

---

Note When an NTLM server is used in either direct proxy routing mode or in transparent WCCP-enabled router redirection mode, all authentication records are indexed by using the IP address of the requesting Content Engine.

---

Authentication Cache 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 default time interval between the user's last Internet access and the removal of that user's entry from the authorization cache is 480 minutes.

You can make adjustments to the authentication cache timeout value by using the http authentication cache timeout global configuration command, either through the CLI or through the Content Distribution Manager GUI. The minimum time interval is 1 minute, and the maximum is 1440 minutes (24 hours). The Content Engine forces reauthentication with the authentication server once this time interval expires.

If you are using HTTP request authentication in transparent mode, we recommend that you configure the authentication cache timeout interval to be short. IP addresses can be reallocated, or different users can access the Internet through an already authenticated device (PC, workstation, and so on). Shorter timeout values help reduce the possibility that individuals can gain access by using previously authenticated devices. (When the Content Engine operates in proxy mode, however, unauthorized users cannot gain Internet access as easily because in proxy mode, the end user must supply a valid user ID and password.)

In the ACNS 5.2 software release, an absolute timeout configuration option was introduced with the http authentication cache ttl global configuration command. This absolute timeout can also be configured to help reduce the possibility of individuals gaining access by using previously authenticated browsers. For more information, see the "Specifying a Reauthentication Interval" section on page 8-19.

Understanding Proxy Server Mode HTTP Request Authentication

When the Content Engine is operating in proxy server mode and is configured for HTTP request authentication, the following events occur if one of the following two situations is true: (1) the Content Engine receives a proxy-style request directly from a client, or (2) the Content Engine receives a WCCP-redirected request and the Content Engine http authentication header global configuration command option 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 (Proxy Authorization Required) 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.

In some cases, Content Engine (CE1) resides in the branch office and is configured in proxy mode, and another Content Engine (CE2) in proxy mode or another HTTP-compatible proxy device resides upstream with a TACACS+, RADIUS, NTLM, or LDAP server available to both Content Engines or proxy devices for login 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. (This credential forwarding capability is not configured by default. If you want credential forwarding, you must explicitly configure it through the http append proxy-auth-header host CE2ipaddress global configuration command.)

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.

---

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

---

Understanding Transparent Mode HTTP Request Authentication

When the Content Engine is operating in transparent mode (using WCCP-enabled router redirection), the user IP address is used as a key to the authentication cache. The Content Engine will always first look for an X-Forwarded-For header, then the source IP address.

If there are two levels of Content Engines in a proxy chain (CE1 at the first level [the Content Engine that is nearest to the client] and CE2 at the second level), and CE1 and CE2 both have the http append x-forwarded-for-header multiple-ip-address global configuration command configured on them, then the following will occur:

1. After receiving a request from the client, CE1 will append the default client's IP address to the X-Forwarded-for header and then forward the request to CE2. For example, if the client's IP address is 10.1.1.20, the X-Forwarded-For header would be "X-Forwarded-for: 10.1.1.20").

2. After CE2 receives the request from CE1, CE2 will append the IP address of CE1 to the X-Forwarded-for header. Consequently, the X-Forwarded-For header will contain the client's IP address (which is already present in the header) and the CE1's IP address separated by comma. For example, if the IP address of CE1 is 10.40.1.40, the X-Forwarded-For header would be "X-Forwarded-for: 10.1.1.20, 10.40.1.40".

In the ACNS 5.4.1 software and later releases, multiple IP addresses in the X-Forwarded-For header are supported. Enter the http append x-forwarded-for-header multiple-ip-address global configuration command to enable support for appending multiple IP addresses to the X-Forwarded-for header. If you specify this command and if the request arrives at CE2 from CE1 with an X-Forwarded-For header, then CE1's IP address is appended to the existing client's IP address in the X-Forwarded-For header separated by a comma.

---

Note 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 (Proxy Authorization Required) 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.

When the Content Engine is operating in transparent mode and is configured for HTTP request authentication, the following events occur if either of the following is true: (1) the Content Engine receives a redirected request from a client, or (2) the http authentication header global configuration command option 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 Content Engine authentication cache.

In the ACNS 5.4.1 software and later releases, multiple IP addresses in the X-Forwarded-For header are supported.

---

Note See the "Configuring Authenticated HTTP Cache Settings" section on page 8-13 for how to configure HTTP headers using the Content Distribution Manager GUI.)

---

You can configure one of the following authentication and authorization services to control HTTP request authentication on the Content Engine:

•Configuring LDAP Server Settings

•Configuring NTLM Server Settings

•Configuring RADIUS Server Settings

•Configuring TACACS+ Server Settings

---

Note NTLM support on the Content Engine includes the following three types of support: (NTLM pass-through authentication support, NTLM authentication of HTTP requests, and NTLM group information query for authorization purposes.

---

About Authenticating Native FTP Requests

ACNS 5.4 software and later releases support proxied authentication for nontransparent connections between FTP clients and FTP proxies. The FTP proxy communicates with the authentication daemon on the Content Engine to provide proxy authentication services for RADIUS, TACACS, LDAP, and NTLM protocols.

---

Note In the case of NTLM, the FTP proxy uses the default NTLM domain name as configured on the Content Engine. The FTP client authenticates with the FTP server (origin server) using basic authentication. No NTLM authentication credentials are passed to the server.

---

The following is a sample FTP client session with NTLM proxy authentication enabled.

bash-2.04$ ftp -d 10.19.228.108 8021

Connected to 10.19.228.108.

220 Welcome to FTP-proxy.  Login to the proxy using username and password.

Name (10.19.228.108:cisco_user): cnbu1\cisco_user

---> USER cnbu1\cisco_user

331 Password required for cnbu1\cisco_user.

Password:

---> PASS XXXX

220-Welcome to FTP-proxy.

220-Login to origin server using the 'USER username@server-hostname' command, or

220 Login to origin server using the 'SITE server-hostname' followed by the 'USER 
username' command.

ftp>

ftp> user admin@22.9.192.10

---> USER admin@22.9.192.10

331 Password required for admin.

Password: 

---> PASS XXXX

230 User admin logged in.  Access restrictions apply.

ftp> pwd

---> PWD

257 "/" is current directory.

ftp> 

Considerations When Configuring Native FTP Proxied Authentication

When you configure request authentication for nontransparent native FTP requests on a Content Engine, remember the following important points:

•For security reasons, native FTP proxy authentication is disabled on the Content Engine by default. The FTP protocol is inherently insecure, and user credentials that would otherwise have been provided over a secure channel (such as, when using HTTP proxy authentication) can be exposed when native FTP proxy authentication is being used.

•If you configure native FTP proxy authentication and you have not already configured an authentication service (such as, RADIUS, LDAP, TACACS+, or NTLM) on the Content Engine, a warning message is displayed. This message indicates that you must configure an authentication service on the Content Engine before you can enable the FTP proxy authentication feature on the Content Engine.

•For request authentication for nontransparent native FTP requests, ACNS supports TACACS+, RADIUS, and LDAP as authentication services. The FTP client that is sending the native FTP request is queried for proxy authentication by the Content Engine only when one of the supported authentication services (TACACS+, RADIUS, and LDAP) is enabled on that Content Engine.

---

Note If NTLM is configured on the Content Engine, the Content Engine does not query the FTP client (that has sent a native FTP request) for proxied authentication.

---

In ACNS 5.4 software and later releases, you can use the same process to enable and configure an authentication service for HTTP requests and nontransparent FTP native requests. (For example, you use the same process to enable and configure RADIUS as an authentication service for HTTP requests and nontransparent native FTP requests.)

However, the following restrictions apply to native FTP caching support:

–No support for FTP request proxy rules

–No support for any URL filtering schemes (good list, bad list, N2H2, Websense, and SmartFilter)

•In ACNS 5.4 software and later releases, you can use IP access control lists (ACLs) to control access for nontransparent and transparent FTP native requests that are sent to the Content Engine that is acting as an FTP proxy for the user (an FTP client). (For more information, see Chapter 17, "Creating and Managing IP Access Control Lists.")

•In ACNS 5.4 software and later releases, you can configure customized messages, which the Content Engine sends to an FTP client in response to an incoming proxy mode connection. (For more information, see the "Configuring Native FTP Custom Messages" section on page 8-62.)

Configuring Request Authentication on Centrally Managed Content Engines

To configure request authentication on the Content Engine, you must complete the following tasks:

1. Determine which one of the supported external authentication servers that you want the device to use when authenticating content requests.

2. Configure the authentication server settings that you wish to use on the Content Engine. (See the next section, "Configuring Authentication Server Settings.")

3. Specify which authentication database the device should check to process the request authentication. (See the "Setting the Authentication Scheme for Request Authentication" section.)

Configuring Authentication Server Settings

Some Cisco ACNS network users use an external access server as a centralized location for controlling the authentication, authorization, and accounting of user accounts and activities. External authentication servers are implemented at the protocol and application level with TACACS+, RADIUS, LDAP, and NTLM.

Only one type of request authentication can be enabled at a time. For example, you cannot enable both LDAP authentication and NTLM authentication at the same time.

The following sections describe how to configure LDAP, NTLM, RADIUS, and TACACS+ server settings for the Content Engine.

Configuring LDAP Server Settings

System administrators can use the Content Engine to restrict user Internet access using an LDAP server for authentication purposes. ACNS 5.x software supports LDAP version 2 and version 3 and supports all LDAP features except for Secure Authentication and Security Layer (SASL).

To configure LDAP server settings using the Content Distribution Manager GUI, follow these steps:

---

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 To display the entire table of contents, click the Show All button above the Contents pane.

Step 4 In the Contents pane, choose General Settings > Authentication > LDAP Server. The LDAP Server Settings window appears. (See Figure 15-2.) Table 15-2 describes the fields shown in this figure.

Figure 15-2 LDAP Server Settings Window

Step 5 To enable LDAP request authentication, check the Enable LDAP Servers check box.

Step 6 From the LDAP Version drop-down list, choose the LDAP protocol version to be used.

Step 7 In the Time to wait field, specify the number of seconds that the Content Engine waits before timing out.

Step 8 In the Number of Retransmits field, specify the number of times that the Content Engine can try to reestablish its connection to the LDAP server if the timeout value is exceeded while it tries to contact the LDAP server. The number of transmission attempts can be from 1 to 3. The default is two attempts.

Step 9 In the User-id Attribute field, enter the user ID attribute.

Step 10 In the Filter field, enter the filter string to be used by the LDAP server.

Step 11 In the Base Distinguished Name field, enter the base distinguished name string for the search in the LDAP server.

Step 12 In the Administrative DN field, enter the administrative distinguished name.

Step 13 In the Administrative DN password field, enter the administrative distinguished name password.

Step 14 To enable access to users when the LDAP server is unavailable, check the Allow-Mode check box.

Step 15 To allow the use of Windows Active Directory groups, check the Active Directory Groups check box.

Step 16 In the Server Port field, specify a TCP port number for LDAP server authentication. We suggest using the default port value of 389.

Step 17 In the Primary Host field, enter the IP address of the primary LDAP server.

Step 18 In the Secondary Host field, enter the IP address of the secondary LDAP server.

Step 19 To save the settings, click Submit.

Table 15-2 LDAP Server Settings 

GUI Parameter	Function	CLI Command
Enable LDAP Servers	Enables HTTP authentication using LDAP servers.	ldap server enable
LDAP Version	LDAP protocol version (version 2 or version 3) to be used.	ldap server version
Time to wait	Number of seconds that the Content Engine waits for a response before timing out on a connection to a particular LDAP server. The default value is 5 seconds.	ldap server timeout
Number of Retransmits	Number of attempts allowed to connect to an LDAP server. The default value is 2 times.	ldap server retransmit
User-id Attribute	Name of the user ID attribute on the LDAP server. The default is "uid."	ldap server userid-attribute
Filter	LDAP filter string. There is no default value.	ldap server filter
Base Distinguished Name	Base distinguished name of the starting point for the search of the LDAP server. This allows for a search on a particular string, such as the domain "com."	ldap server base
Administrative DN	Administrative distinguished name. Allows a search for a particular user associated with the base distinguished name.	ldap server administrative-dn
Administrative DN Password	Password for the administrative distinguished name.	ldap server administrative-passwd
Allow-Mode	Allows access to users when the LDAP server is unavailable.	ldap server allow-mode
Active Directory Group	Allows access to Windows Active Directory groups.	ldap server active-directory-group
Server Port	Port number on which the LDAP server is listening. The default port number is 389.	ldap server port
Primary Host	IP address of the primary LDAP server.	ldap server host
Secondary Host	IP address of the secondary LDAP server.	ldap server host

---

In ACNS 5.4 software, the LDAP server password expiration, policy redirection, and group settings can be configured from the Content Distribution Manager GUI.

To configure the settings, follow these steps:

---

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 To display the entire table of contents, click the Show All button above the Contents pane.

Step 4 In the Contents pane, choose General Settings > Authentication > LDAP Server. The LDAP Server Settings window appears. (See Figure 15-3.) Table 15-3 describes the fields shown in this figure.

Figure 15-3 Additional LDAP Server Settings

Step 5 Under the LDAP Password Expiry Settings heading, configure the following:

a. To enable support for the expiration of authorization passwords, check the Enable Password Expiry Support check box.

b. To direct users to a URL where they can reset their expired passwords, enter the URL in the Redirect URL to Reset Expired Password field.

Step 6 Under the Policy Redirection Settings heading, configure the following:

a. To enable policy redirection support, check the Enable Policy Redirection check box.

b. To define the LDAP attribute under which the policy version number is stored, enter a name in the Attribute Name field.

c. To define the policy version number, enter a value from 1 to 99999999 in the Current Policy Version Number field.

d. To redirect the user to a Usage Policy acceptance web page, enter the URL of the web page in the URL to Redirect field.

e. Upon acceptance of the Usage Policy, if you want the browser to go directly to the requested URL, check the Append Request URL to Redirect URL check box.

Step 7 Under the Group Settings heading, configure the following:

a. To obtain the group name from the memberOf attribute of a user's account and enable group membership based on that attribute, check the Active Directory Groups check box. This check box can be checked only if the LDAP version chosen from the LDAP Version drop-down list is version 3. (See Figure 15-2.)

b. To obtain the group name from the custom attribute of a user's account and enable group membership based on that attribute, enter a name in the Custom Group Name field. The maximum number of characters that you can enter for a name is 256 characters.

c. To obtain the group name from the organizationUnit attribute of a user's account and enable group membership based on that attribute, check the Enable Organization Unit Group check box.

d. To enable static group queries for group membership, check the Enable Static Group check box.

e. To configure the static group attribute name, enter a name in the Static Group Attribute field.

f. Choose one of the following static group member attributes by clicking the corresponding radio button:

•Do Not Set

•Member

•Unique Member

•Custom Member

If you choose Custom Member, enter the custom member name of the static group in the text field.

g. To enable nested static group queries for a user's membership, check the Enable Nested Static Group check box.

h. To configure the level of nested static groups to query, enter a number from 1 to 100 in the Level of Nested Static Group field.

Step 8 To save the settings, click Submit.

Table 15-3 Additional LDAP Server Settings 

GUI Parameter	Function	CLI Command
LDAP Password Expiry Settings
Enable Password Expiry Support	Enables support for the expiration of authorization passwords.	ldap server password-expiry enable
Redirect URL to Reset Expired Password	Directs users to a URL where they can reset their expired passwords. This parameter accepts any URL with a valid format, such as the following: http://www.someserver.com/file.html	ldap server password-expiry redirect-url url
Policy Redirection Settings
Enable Policy Redirection	Enables policy redirection support.	ldap server policy-redirect enable
Attribute Name	Defines the LDAP attribute under which the policy version number is stored.	ldap server policy-redirect attribute name
Current Policy Version Number	Defines the policy version number. The range is from 1 to 99999999.	ldap server policy-redirect version-number number
URL to Redirect	Redirects the user to a Usage Policy acceptance web page.	ldap server policy-redirect redirect-url url
Append Request URL to Redirect URL	Directs the user to the requested URL upon acceptance of the Usage Policy.	ldap server policy-redirect append-request-url
Group Settings
Active Directory Groups	Queries the memberOf attribute of a user's account and enables group membership based on that attribute. To enable active directory query, the LDAP version must be configured, and the version must be version 3.	ldap server group active-directory enable
Custom Group Name	Queries the custom attribute of a user's account and enables group membership based on that attribute. Maximum characters for the custom group name is 256.	ldap server group custom name enable
Enable Organization Unit Group	Queries the organizationUnit attribute of a user's account and enables group membership based on that attribute.	ldap server group organizationUnit enable
Enable Static Group	Enables static group queries for group membership.	ldap server group static enable
Static Group Attribute	Configures the static group attribute name. Maximum characters for the static group attribute is 256. Cannot be configured if active directory group is enabled.	ldap server group static group-attribute name
Group Settings
Static Member Attribute:	Configures a static group member attribute. Maximum characters for the custom static member attribute is 256. Cannot be configured if active directory group is enabled or if the LDAP version is other than version 3.	ldap server group static member-attribute {custom-member name | member | uniquemember}
Do Not Set
Member
Unique Member
Custom Member
Enable Nested Static Group	Enables nested queries for static group membership.	ldap server group static nested enable
Level of Nested Static Group	Configures the level of nested static groups to query. Number of levels must be from 1 to 100. The default is 1.	ldap server group static nested level number

---

Configuring NTLM Server Settings

To configure NTLM server settings using the Content Distribution Manager GUI, follow these steps:

---

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 In the Contents pane, choose General Settings > Authentication > NTLM Server. The NTLM Server Settings window appears. (See Figure 15-4.) Table 15-4 describes the fields shown in this window.

Figure 15-4 NTLM Server Settings Window—Top of Window

Step 4 To enable NTLM authentication, configure the NTLM server domain name, NT primary domain controller name or IP address, and optionally set the host name or address as primary or secondary, check the Enable NTLM Servers check box.

Before making an NTLM authentication request, make sure that the following conditions are met:

•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. This domain can be either a domain hosted by the PDC, or a trusted domain that the PDC can authenticate by contacting other PDCs.

---

Note This domain can be either a domain hosted by the PDC or a trusted domain that the PDC can authenticate by contacting other PDCs.

---

Step 5 In the Domain Name field, specify the domain name in which the user should be authenticated. (See the "Support for No Default NTLM Domain" section.)

Step 6 From the Select NTLM scheme drop-down list, choose an option to specify the scheme for the NTLM servers for HTTP request authentication. This option allows you to specify the scheme (load balancing or failover) that is to be used among the configured NTLM servers. The default scheme is fail-over; the other supported scheme is load-balanced.

When the load balancing scheme is enabled, only the first request is sent to the first configured server, and then round robin is used among the configured servers. (See the "About NTLM Load Balancing for HTTP Request Authentication" section.) When the failover scheme is enabled, the Content Engine sends all the requests to the first configured server. (See the "About NTLM Failover for HTTP Request Authentication" section.)

Step 7 In the Domain Server1 field, enter the host name or IP address for the domain server. The server configured as Server1 becomes the primary NTLM domain server when multiple servers are configured for failover purposes.

---

Note Only if the fail-over scheme is enabled, the first server configured is the "primary" server and is sent all of the requests first. If the load-balancing scheme is enabled, the definition of a "primary" server is not applicable.

---

Step 8 In the Domain Server fields 2 through 8, enter the host names or IP addresses of each NTLM server that you want the Content Engine to use for HTTP request authentication. This list of configured NTLM servers is referred to as the "host list."

In ACNS software, you can configure a Content Engine to use up to eight NTLM servers for HTTP request authentication. The order of the server configuration determines the order of load balancing or failover.

Step 9 To configure the number of connection attempts, enter a number in the Maximum attempts to connect to server field.

Step 10 To configure the wait time before a server connection fails, enter the number of seconds in the Time to wait when connecting to server field.

Step 11 To enable support for active directory group search, check the Enable Active Directory group search check box. (See Figure 15-5.)

Figure 15-5 NTLM Server Settings Window—Bottom of Window

Active directory group search enables the ACNS software to interoperate with the Microsoft Active Directory database for NTLM group authentication.

Step 12 In the Domain Name field, enter the enumeration user's domain.

---

Note An enumeration user is an account defined on the Content Engine to allow the Content Engine to perform a search in the Microsoft Active Directory database. This enumeration user needs to have read privileges throughout the whole directory.

---

Step 13 In the Username field, enter the enumeration username.

Step 14 In the Password field, enter the password of the enumeration user.

Step 15 In the Confirm Password field, renter the enumeration user password.

Step 16 To allow searching in the Microsoft Active Directory database, check the Enable Referral Chasing check box.

Step 17 In the No. of Nested Referrals field, enter the directory level to which you want the search made.

Step 18 In the LDAP search server port field, enter the port number for the LDAP search server. The default is 389.

Step 19 In the Groupname attribute field, enter the groupname attribute in the Microsoft Active Directory database. The default is cn.

Step 20 In the Membership attribute field, enter the membership attribute in the Microsoft Active Directory database. The default is MemberOf.

Step 21 In the Object class for user object field, enter the object class for the user object in the Microsoft Active Directory database. The default is user.

Step 22 In the Username attribute field, enter the username attribute in the Microsoft Active Directory database. The default is sAMAccountName.

Step 23 From the Select scheme to use for the host list drop-down list, choose a scheme:

•If you want failover to occur between the hosts, choose failover.

•If you want round-robin load balancing to occur among the hosts, choose load-balanced.

Step 24 In the Port for global catalog server field, enter the port number for the global catalog server. The default port number is 3268.

Step 25 In the Host field, enter the global catalog server host name or IP address. You can add up to eight global catalog server host names.

Step 26 In the Domain field that corresponds to the host name, enter the global catalog server domain name. You can enter up to eight global catalog server domain names.

Step 27 To save the settings, click Submit.

Table 15-4 NTLM Server Settings 

GUI Parameter	Function	CLI Command
Domain Name	Domain name in which the user should be authenticated.	ntlm server domain name
Select NTLM Scheme	Scheme for the NTLM servers for HTTP request authentication.	ntlm server scheme {fail-over | load-balanced}
Domain Server1	NTLM server that serves as the primary host.	ntlm server host {hostname | ipaddress} primary
Domain Server2-8	NTLM servers that serve as backup hosts.	ntlm server host {hostname | ipaddress} secondary
Maximum attempts to connect to server	Maximum number of attempts (1-3) to connect to the server. The default is 2 attempts.	ntlm server connection-retry number
Time to wait when connecting to server	Number of seconds (1-20) to wait to connect to the server. The default is 5 seconds.	ntlm server connection-timeout seconds
Enable Active Directory group search	Enables the ACNS software to interoperate with the Microsoft Active Directory database for NTLM group authentication.	ntlm server ad-group-search enable
Domain Name	The enumeration user's domain.	ntlm server ad-group-search enum-user domain domainname
Username	The enumeration user's username.	ntlm server ad-group-search enum-user username username
Password/Confirm Password	The enumeration user's password.	ntlm server ad-group-search enum-user password password
Enable Referral Chasing	Enables LDAP referral. The default is disabled.	ntlm server ad-group-search ldap-referral enable
No. of Nested Referrals	the directory level to which you want the search made.	ntlm server ad-group-search ldap-referral limit number
LDAP search server port	Port number for the LDAP search server.	ntlm server ad-group-search ldap-search-port portnum
Groupname attribute	The groupname attribute in the Active Directory database. The default attribute is cn.	ntlm server ad-group-search groupname-attribute attribute
Membership attribute	The membership attribute in the Active Directory database. The default is memberOf.	ntlm server ad-group-search membership-attribute attribute
Object class for user object	The object class for the user object. The default is user.	ntlm server ad-group-search user-objectclass class
Username attribute	The username attribute in the Active Directory database. The default attribute is sAMAccountName.	ntlm server ad-group-search username-attribute attribute
Select scheme to use for the host list	Scheme to use for the global catalog host list. Options are fail-over or load-balanced.	ntlm server ad-group-search gc-server scheme {fail-over | load-balanced}
Port for global catalog server	Global catalog server port. The default port is 3268.	ntlm server ad-group-search gc-server port portnum
Host	Global catalog server IP address or host name.	ntlm server ad-group-search gc-server host {hostname | ipaddress}
Domain	Host domain name for the global catalog server being configured.	ntlm server ad-group-search gc-server host {hostname | ipaddress} domain domain

---

Configuring the NTLM Server LDAP Memory Cache Settings

The ACNS 5.4 software release supports LDAP memory cache for nested group searches. This feature enables the Content Engine to store the results of a nested group search locally in its LDAP cache. By default, this feature is enabled on the Content Engine.

In previous ACNS releases, when the Content Engine performed an NTLM group search, it had to contact the LDAP Global Catalog server to get group information for every request. If the user belonged to a nested group with many levels, queries were sent from the Content Engine to the Active Directory server to search each parent level in the group, and the Content Engine needed to contact the LDAP Global Catalog server several times before obtaining all group information for the user.

To enhance performance for nested group searches, ACNS 5.4 software uses the LDAP memory cache on the Content Engine to cache the search results of LDAP queries. If the same search request is submitted again, the results are fetched from the LDAP memory cache on the Content Engine, reducing the number times the Content Engine must connect to the LDAP Global Catalog server.

To configure the NTLM server LDAP memory cache settings, follow these steps:

---

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure.

Step 3 In the Contents pane, choose General Settings > Authentication > NTLM Server. The NTLM Server Settings for Content Engine window appears.

Step 4 To locate the LDAP memory cache configuration settings, scroll to the bottom of the window. (See Figure 15-6.)

Figure 15-6 NTLM Server LDAP Memory Cache Settings for the Content Engine

(Table 15-5 describes the fields in this window and lists the corresponding CLI commands.)

Step 5 To enable caching of nested group query results, check the Enable LDAP memory cache check box.

Step 6 To configure the size of the LDAP memory cache, enter a value (in kilobytes) in the Size of memory cache field.

Step 7 To configure the time for an entry to remain in the cache, enter a value (in minutes) in the Time to live for the cache field.

Step 8 To save the settings, click Submit.

---

Note All of the required fields in the NTLM Server Settings for Content Engine window must also be configured, or you will see an error message when you click Submit. (See the "Configuring NTLM Server Settings" section.)

---

Table 15-5 NTLM Server LDAP Memory Cache Settings for the Content Engine 

GUI Parameter	Function	CLI Command
Enable LDAP memory cache	Enables the LDAP in-memory cache on the Content Engine. The default is enabled.	[no] ntlm server ad-group-search mem-cache enable
Size of memory cache	Number of kilobytes to allocate in the in-memory cache for the results of LDAP queries. The range is 128-10240 KB. The default is 140 KB.	ntlm server ad-group-search mem-cache size size
Time to live for the cache	Time (in minutes) that an entry remains valid in the LDAP in-memory cache. The range is 1-1440 minutes. The default is 400 minutes.	ntlm server ad-group-search mem-cache max-ttl max-ttl

---

Support for No Default NTLM Domain

ACNS software sends a "no domain configuration" error message to the client when the user does not supply a domain name in the request authentication credential and has not configured a default domain on the Content Engine. The error message contains text indicating the reason for the error.

---

Note The no domain configuration feature is only supported with browsers that do not support NTLM (for example, Netscape browsers). For the Netscape browser, the user must specify the domain if the Content Engine does not have an NTLM default domain configured; otherwise, the client receives an error. Note that for the Netscape browser, the domain can only be supplied as part of the username in the format of "domain\username." Browsers that do support NTLM, such as Internet Explorer, always include a domain name in the authentication credentials that originate from either the users being prompted to specify the credentials or from the domain that was used to logon users to their desktops.

---

About NTLM Load Balancing for HTTP Request Authentication

In large-scale networks where all network traffic passes through the Content Engine, even though the Content Engine authentication cache helps reduce the load on the domain controller, it might still be impractical to have a single domain controller handling all the authentication queries from end users. ACNS 5.4 software provides the ability to configure up to eight servers (domain controllers) for load balancing and failover purposes.

When you choose load-balanced as the authentication scheme, requests follow the round-robin process among the domain controllers. The order in which the domain controllers (servers) are configured determines the order of load balancing. For example, if you have n servers, the first request is sent to Server 0 and the second request is sent to Server 1, the nth request is sent to Server n - 1 and the n +1 request is sent to Server 0. If Server 0 fails, the Content Engine attempts to send the request to the next alive server (in this case, Server 1). However, failover to the next alive server occurs a maximum of one time. For example, if Server 1 goes down when handling request 1, then request 1 does not fail over again.

If load balancing is enabled and the server information is changed during run time, the change is picked up at run-time without disrupting the service.

About NTLM Failover for HTTP Request Authentication

ACNS 5.4 software supports failover between domain controllers. The order in which the domain controllers (servers) are configured determines the order of failover. The first server configured (Server 0) is the first server to be contacted. The last server configured (Server 7) is the last server to be contacted.

If the timeout period for one connection attempt is exceeded, the Content Engine drops the connection and attempts to reconnect to the same server. The Content Engine retries the connection up to the specified number of retries configured (ntlm server connection-retry global configuration command) before attempting to connect to the next configured server on the host list.

Configuring NTLM Allowed Domains for HTTP Request 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 Content Engine, 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 Content Engine authentication cache. Future requests from this IP address are not challenged until the authentication cache entry expires or is cleared.

To configure NTLM allowed domains for HTTP request authentication on Content Engines,
follow these steps:

---

Step 1 Choose Devices > Device Groups. The Device Groups window appears.

Step 2 Click the Edit icon next to the device group for which you want to configure the domains for NTLM HTTP request authentication. The Modifying Device Group window appears.

Step 3 In the Contents pane, choose General Settings > Authentication > NTLM Allow Domain. The NTLM Allow Domain Settings window appears.

Step 4 To enable NTLM HTTP request authentication on the Content Engine, check the Enable Use of the List of Domains Allowed to Authenticate check box.

Step 5 In the Domain field, enter the name of domain for which you want to support NTLM HTTP request authentication.

Step 6 To add the domain name to the list of domains allowed for NTLM HTTP request authentication, click Add. You can add up to 32 domains in this list. The newly added domain name appears in the window.

Step 7 To edit a domain name, click the Edit icon next to the domain name in the list of domains that are allowed for NTLM HTTP authentication.

Step 8 Edit the domain name field, and click Edit to save the changes.

Step 9 To delete a domain name from the list of domains supported for NTLM HTTP authentication, click the Delete icon next to the domain name.

Step 10 To save the changes, click Submit.

---

To enable NTLM HTTP request authentication from the CLI, use the ntlm allow-domain {enable | domain domainname} global configuration command.

Configuring RADIUS Server Settings

RADIUS authentication clients reside on devices running ACNS 5.x software. When enabled, these clients send authentication requests to a central RADIUS server, which contains user authentication and network service access information.

---

Tip The Content Distribution Manager does not cache the user authentication information, so the user is reauthenticated against the RADIUS server for every request. To prevent performance degradation caused by many authentication requests, install the Content Distribution Manager in the same location as the RADIUS server, or as close as possible to it, to ensure that authentication requests can occur as quickly as possible.

---

To configure RADIUS server settings using the Content Distribution Manager GUI, follow these steps:

---

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 In the Contents pane, choose General Settings > Authentication > RADIUS Server. The RADIUS Server Settings window appears. (See Figure 15-7.) Table 15-6 describes the fields in this window.

Figure 15-7 RADIUS Server Settings Window

Step 4 To enable RADIUS authentication, check the Enable RADIUS Servers check box.

Step 5 In the Time to wait field, specify how long the Content Engine should wait before timing out. The default value is 5 seconds.

Step 6 In the Number of Retransmits field, specify the number of attempts allowed to connect to a RADIUS server.

Step 7 To enable RADIUS redirection, check the Enable Redirect check box.

Step 8 In the Redirect Message field, enter a redirect message for the user. Three redirect messages are allowed.

Step 9 In the Location field, enter a location where the redirect message should be sent. Three separate locations are allowed.

Step 10 In the Shared Encryption Key field, enter the secret key that is used to communicate with the RADIUS server.

Step 11 In the Server Name field, enter an IP address or host name information. Five different hosts are allowed.

Step 12 In the Server Port field, enter the port number on which the RADIUS server is listening. Five different ports are allowed.

Step 13 To save the settings, click Submit.

Table 15-6 RADIUS Server Settings 

GUI Parameter	Function	CLI Command
Enable RADIUS Servers	Enables HTTP authentication using RADIUS servers.	radius-server enable
Time to wait	Number of seconds to wait for a response before timing out on a connection to a particular RADIUS server. The range is from 1 to 20 seconds. The default value is 5 seconds.	radius-server timeout
Number of retransmits	Number of attempts allowed to connect to a RADIUS server. The default value is 2 times.	radius-server retransmit
Enable redirect	Redirects an authentication response to a different authentication server if an authentication request using the RADIUS server fails.	radius-server redirect enable
Redirect Message	Message sent to the user if redirection occurs.	radius-server redirect message
Location	Sets an HTML page location. This is the URL destination of the redirect message that is sent when authentication fails.	radius-server redirect message reply location url
Shared Encryption Key	Encryption key shared with the RADIUS server.	radius-server key keyword
Server Name	IP address or host name of the RADIUS server.	radius-server host {hostname | ipaddress}
Server Port	Port number on which the RADIUS server is listening.	radius-server host auth-port port

---

Configuring TACACS+ Server Settings

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 5.x 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.

---

Tip The Content Distribution Manager does not cache user authentication information. Therefore, the user is reauthenticated against the TACACS+ server for every request. To prevent performance degradation caused by many authentication requests, install the Content Distribution Manager in the same location as the TACACS+ server, or as close as possible to it, to ensure that authentication requests can occur as quickly as possible.

---

To configure TACACS+ server settings using the Content Distribution Manager GUI, follow these steps:

---

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 In the Contents pane, choose General Settings > Authentication > TACACS+ Server. The TACACS+ Server Settings window appears. (See Figure 15-8.) Table 15-7 describes the fields in this window.

Figure 15-8 TACACS+ Server Settings Window

Step 4 To enable TACACS+ authentication, check the Enable TACACS+ Servers check box.

Step 5 To use the ASCII password type for authentication, check the Use ASCII Password Authentication check box. The default password type is PAP (Password Authentication Protocol). However, you can change the password type to ASCII when the authentication packets are to be sent in ASCII clear text format.

Step 6 In the Time to wait field, specify how long the Content Engine should wait before timing out. The default value is 5 seconds.

Step 7 In the Number of Retransmits field, specify the number of attempts allowed to connect to a TACACS+ server. The default value is 2.

Step 8 In the Security Word field, enter the secret key that is used to communicate with the TACACS+ server.

Step 9 In the Primary Server field, enter an IP address or host name information for the primary TACACS+ server.

Step 10 In the Secondary Server field, enter an IP address or host name information for a secondary TACACS+ server.

Step 11 In the Tertiary Server field, enter an IP address or host name information for a tertiary TACACS+ server.

Step 12 To save the settings, click Submit.

Table 15-7 TACACS+ Server Key Parameter Settings

GUI Parameter	Function	CLI Command
Enable TACACS+ Servers	Enables TACACS+ authentication.	tacacs enable
Use ASCII Password Authentication	Changes the default password type from PAP (Password Authentication Protocol) to ASCII clear text format.	tacacs password ascii
Time to wait	Number of seconds to wait for a response before timing out on a connection to a particular TACACS+ server. The range is from 1 to 20 seconds. The default value is 5 seconds.	tacacs timeout
Number of retransmits	Number of attempts allowed to connect to a TACACS+ server. The default value is 2 times.	tacacs retransmit
Security Word	Encryption key shared with the TACACS+ server.	tacacs key
Primary Server	IP address or host name of the primary TACACS+ server.	tacacs host {hostname | ipaddress} [primary]
Secondary Server Tertiary Server	IP address or host name of the backup TACACS+ server. Up to 2 backup servers are allowed.	tacacs host {hostname | ipaddress}

---

Setting the Authentication Scheme for Request Authentication

To enable an authentication scheme for request authentication, follow these steps:

---

Step 1 From the Content Distribution Manager GUI, choose Devices > Devices.

Step 2 Click the Edit icon next to the name of the Content Engine that you want to configure. The Contents pane appears on the left.

Step 3 In the Contents pane, choose General Settings > Authentication > Authentication Scheme.

Step 4 From the Authentication Scheme drop-down list, choose one of the following authentication schemes:

•Disable Authentication

•RADIUS

•LDAP

•NTLM

•TACACS+

---

Note You must configure and enable an authentication server before you can save the authentication scheme settings from this window.

---

Step 5 To save the settings, click Submit.

---