Cisco ACNS Software Configuration Guide for Locally Managed Deployments, Release 5.5 - Chapter 10: Configuring Content Authentication and Authorization on Standalone Content Engines [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Configuring Content Authentication and Authorization on Standalone Content Engines

About Authentication and Authorization of Content Requests

About End-to-End and Pass-through Authentication

About NTLM Support on Content Engines

About NTLM Support

Configuring Pass-Through Authentication for WMT Requests

Configuring End-to-End Authentication for HTTP Requests

Basic End-to-End Authentication

NTLM End-to-End Authentication

Configuring Request Authentication for HTTP Requests

Controlling Content Access for HTTP Requests

Authenticating Web Clients Through Pass-Through Authentication

Authenticating Web Clients Through HTTP Request Authentication

Guidelines for Configuring Request Authentication for HTTP Requests

Configuring an Authentication Service on Standalone Content Engines

Configuring the RADIUS Authentication Service

Configuring the TACACS+ Authentication Service

Configuring the LDAP Authentication Service

Example of Configuring LDAP Authentication Service

Understanding the Structure of the LDAP Database

Configuring the LDAP Cache on Standalone Content Engines

Querying LDAP Servers for User Membership Information

Configuring the NTLM Authentication Service

About NTLM Load Balancing for HTTP Request Authentication

Configuring the Content Engine to Use NTLM Servers for HTTP Request Authentication

Configuring a List of Allowed Domains List NTLM HTTP Request Authentication

Configuring the Authentication Method Control for NTLM HTTP Request Authentication

Displaying the Current NTLM Configuration for Standalone Content Engines

Configuring Group-Based Authorization for HTTP Requests

Configuring Group-Based Access Lists on Standalone Content Engines

Configuring Content Engines for Active Directory Group Searches

Disabling Group Name-Based Access Lists

Configuring the LDAP Acceptable Use Policy Feature

Configuring the LDAP Password Expiration Feature

Configuring Request Authentication for Nontransparent FTP Native Requests

Configuring Content Authentication and Authorization on Standalone Content Engines

This chapter describes how to configure content authentication and authorization on standalone Content Engines that are running the ACNS 5.4.1 software and later releases. Content authentication and authorization controls whether an end user (for example, a client browser that issued an HTTP request or an FTP client that issued a nontransparent FTP native request) can access the requested content that is served through the Content Engine.

Note In the ACNS 5.2.1 software and later releases, HTTP request authentication is supported. Throughout this chapter, the term HTTP request is used to refer collectively to requests over HTTP that include HTTP, FTP-over-HTTP, and HTTPS-over-HTTP requests. In the ACNS 5.4.1 software and later releases, proxy authentication of nontransparent FTP native requests is also available.

This chapter contains the following sections:

•About Authentication and Authorization of Content Requests

•Configuring Pass-Through Authentication for WMT Requests

•Configuring End-to-End Authentication for HTTP Requests

•Configuring Request Authentication for HTTP Requests

•Configuring an Authentication Service on Standalone Content Engines

•Configuring the LDAP Acceptable Use Policy Feature

•Configuring Request Authentication for Nontransparent FTP Native Requests

Note For complete syntax and usage information for the CLI commands used in this chapter, see the Cisco ACNS Software Command Reference, Release 5.5 publication. For information about configuring content authentication, authorization, and accounting for Content Engines that are registered with a Content Distribution Manager, see the ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.5.

Another type of authentication and authorization method, login authentication and authorization, is used to configure the Content Engine to control the privilege levels that are granted to an administrative user who logs in to the Content Engine for administrative purposes (configuring, monitoring, or troubleshooting the Content Engine). Content authentication and authorization is independent of login authentication and authorization. For information about administrative login authentication and authorization, see Chapter 17, "Configuring Administrative Login Authentication and Authorization on Standalone Content Engines."

About Authentication and Authorization of Content Requests

As organizations extend the use of web applications and Internet access to their employees, they are confronted with the following challenges:

•How to manage employee use of the Internet

•How to restrict access to online content

Organizations can use content authentication and authorization to address these concerns. Content authentication and authorization can be implemented through various protocols, as summarized in Table 10-1.

Table 10-1 Content Authentication and Authorization Methods Supported by the ACNS 5.4.1 Software or Later

Method

More Information

Pass-through authentication
for WMT requests

See the "Configuring Pass-Through Authentication for WMT Requests" section.

End-to-end authentication for HTTP requests

See the "Configuring End-to-End Authentication for HTTP Requests" section.

Basic

See the "Basic End-to-End Authentication" section.

Microsoft NTLM

See the "NTLM End-to-End Authentication" section.

Request authentication for HTTP requests

See the "Configuring Request Authentication for HTTP Requests" section.

RADIUS

See the "Configuring the RADIUS Authentication Service" section.

TACACS+

See the "Configuring the TACACS+ Authentication Service" section.

LDAP

See the "Configuring the LDAP Authentication Service" section.

NTLM

See the "Configuring the NTLM Authentication Service" section.

Group-based authorization for HTTP requests

See the "Configuring Group-Based Authorization for HTTP Requests" section.

Request authentication for nontransparent FTP native requests

See the "Configuring Request Authentication for Nontransparent FTP Native Requests" section.

RADIUS

See the "Configuring the RADIUS Authentication Service" section.

TACACS+

See the "Configuring the TACACS+ Authentication Service" section.

LDAP

See the "Configuring the LDAP Authentication Service" section.

NTLM

See the "Configuring the NTLM Authentication Service" section.

In the ACNS 5.2.1 software and later releases, HTTP request authentication is supported. (The term HTTP request is used to refer collectively to requests over HTTP that include HTTP, FTP-over-HTTP, and HTTPS-over-HTTP requests.) For more information, see the "Configuring Request Authentication for HTTP Requests" section.

In the ACNS 5.4.1 software and later releases, proxy authentication of nontransparent FTP native requests is also available. This feature provides authentication of nontransparent FTP native 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 "Configuring Request Authentication for Nontransparent FTP Native Requests" section.

Note In ACNS 5.4.1 software and later releases, you can use IP access control lists (ACLs) to control access to the native FTP proxy service that is running on a standalone Content Engine. For more information, see the "Using IP ACLs to Control Native FTP Access" section on page 19-19.

The same process is used to enable and configure RADIUS, TACACS+, NTLM, or LDAP authentication for HTTP requests and nontransparent FTP native requests (for example, you can configure the RADIUS server settings on the Content Engine and enable RADIUS authentication on the Content Engine). However, the following restrictions apply to FTP native caching support:

•No support for FTP request proxy rules

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

The preceding two restrictions do not apply to HTTP caching support.

About End-to-End and Pass-through Authentication

End-to-end authentication is authentication that occurs between the client and the origin server. Pass-through authentication is how the Content Engine handles end-to-end authentication. With pass-through authentication, the Content Engine passes through the authentication request and response between the client and the origin server without examining such requests and responses.

About NTLM Support on Content Engines

Windows NT LAN Manager (NTLM) is the authentication protocol that is used by Microsoft's browsers (Internet Explorer), proxies, and web servers (IIS). The NTLM protocol is a challenge-response-based protocol and can be used to authenticate and block user access to the Internet. Because NTLM is a challenge-response-based authentication scheme, the 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 originated the authentication challenge. Consequently, the clients can prove their identity without sending a password over the network to the server that originated the authentication challenge.

Typically, enterprises are already using NTLM to enforce access control to information that is stored on their intranet sites. Additionally, enterprises want to protect Internet browsing but not have to prompt their end users for usenames and passwords. NTLM provides this authentication scheme through Microsoft Internet Explorer and domain controllers (DCs). Content Engines support NTLM HTTP request authentication in order to support both of these models. A client (web browser) attempts to perform NTLM HTTP request authentication with the Content Engine in order to be allowed to use the Content Engine (the HTTP proxy server) to access the requested content.

NTLM support on a standalone Content Engine includes the following four types of support: (1) NTLM end-to-end authentication support, (2) NTLM authentication of HTTP requests, and (3) NTLM group information query for authorization purposes, and (4) NTLM support of preloading NTLM-protected objects. See Table 10-2 for a summary of the types of NTLM support on standalone Content Engines that are running the ACNS 5.x software.

Table 10-2 Summary of NTLM Support on Content Engines

Type of NTLM Support

Comments

NTLM authentication of HTTP requests

For HTTP request authentication, the ACNS 5.3.x and earlier releases only support NTLMv1. (NTLMv1 is also referred to as simply "NTLM".)

In the ACNS 5.4.1 software and later releases, both NTLMv1 and NTLMv2 are supported for HTTP request authentication.

For more information, see the "Configuring the NTLM Authentication Service" section.

NTLM group information query for authorization purposes

In the ACNS 5.x software releases, both NTLMv1 and NTLMv2 are supported for NTLM group information query for authorization purposes.

For more information, see the "Configuring Group-Based Authorization for HTTP Requests" section.

NTLM end-to-end authentication

In the ACNS 5.x software releases, both NTLMv1 and NTLMv2 are supported for NTLM end-to-end authentication.

For more information, see the "NTLM End-to-End Authentication" section.

NTLM support of preloading NTLM-protected objects

In the ACNS 5.1.1 software and later releases, NTLMv1 support of preloading NTLM authenticated objects on standalone Content Engines is available. In the ACNS 5.4.1 software release, NTLMv2 support of preloading NTLM authenticated objects was added.

For more information, see the "Configuring Content Preloading for Standalone Content Engines" section on page 11-2.

The ntlm version global configuration command, which was added in the ACNS 5.4.1 software release, has two command options: the version 1 option to reenable NTLMv1, and the version 2 option to enable NTLMv2 on a standalone Content Engine. The version 1 command option is the default option.

For Content Engines that are registered with a Content Distribution Manager, NTLMv2 support for acquisition and distribution of NTLM-protected content was also added in the ACNS 5.4.1 software release. For information about configuring Content Engines that are registered with a Content Distribution Manager, see the ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.5.

About NTLM Support

In the ACNS 5.4.1 software and later releases, both NTLMv1 and NTLMv2 are supported for NTLM HTTP request authentication. In the ACNS 5.3.x software and earlier releases, only NTLMv1 is supported for NTLM HTTP request authentication (that is, NTLM request authentication for requests over the HTTP protocol).

With NTLMv1, 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.

NTLMv2 is the successor of NTLMv1. NTLMv2 is designed to be more secure than NTLMv1. The algorithm that is used by NTLMv2 to create the password hash, which is used to encrypt the challenge, is more complex than the algorithm used by NTLMv1. The NTLMv2-encrypted response also includes a timestamp to prevent replay attacks.

In the ACNS 5.4.1 software release, the ACNS software was enhanced to support NTLMv2. In the ACNS 5.3.x software and earlier releases, client authentication will fail if the client attempts to use NTLMv2.

NTLMv2 is not negotiated between the browser and the server (or the proxy). On Windows-based clients and servers, you enable NTLMv2 by modifying a registry variable on the client and the server. When an HTTP response to the client indicates that the server (or the proxy) requires authentication and NTLM is accepted, the client generates a different NTLM response based on the client configuration:

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

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

Pass-through Authentication Support for NTLM-Enabled Browsers

If the Content Engine is running the ACNS 5.4.1 software or a later release and the client browser is configured for NTLMv2, then pass-through authentication and NTLM HTTP request 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 NTLMv2 response and sends it to the Content Engine.

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

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

For an NTLM HTTP request authentication, after the user is validated by the domain controller, the Content Engine saves the information about the client's username and domain name in its authentication cache so that it will not challenge future requests from the same IP address.

Basic Authentication Support for Non-NTLM Enabled Browsers

With non-NTLM enabled browsers (that is, browsers that do not support NTLMv1 or NTLMv2) the Content Engine will only use NTLMv2 to communicate with the domain controller if all of the following conditions exist:

•The Content Engine has been configured to use NTLMv2 (that is, you have specified the v2 command option for the ntlm server host global configuration command).

•The Content Engine is running the ACNS 5.4.1 software or a later release.

•Basic authentication has not been disabled on the Content Engine (that is, you have not disabled basic authentication on the Content Engine by entering the no ntlm basic-auth enable global configuration command).

In this situation, when the client browser receives an HTTP response from the Content Engine indicating that client authentication is required, the client browser will perform 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 NTLMv2 response using the password, and then sends the NTLMv2 response to the domain controller for validation.

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

About NTLM v2 Support for Request Authentication

By default, the Content Engine uses NTLMv1 instead of NTLMv2 when communicating with each of these eight configured NTLM servers during the request authentication process unless you enable the NTLMv2 feature.

In the ACNS 5.4.1 software release, NTMLv2 support for request authentication of HTTP requests was added. Because NTLMv2 is not negotiated between the client and the server (it is configured separately on both the client and server by changing the Windows registry on the client and the server), there is no configuration parameters that you need to specify on the Content Engine in order for the Content Engine to support NTLMv2. However, if you want the Content Engine to support NTLMv2 when communicating with any of the configured NTLM servers (that is, any of the NTLM servers that have been added to the host list through the ntlm server host global configuration command), you must enter the ntlm version 2 global configuration command on the Content Engine:
ContentEngine(config)# ntlm version 2
The ntlm version global configuration command, which was added in the ACNS 5.4.1 software release, has two command options: the version 1 option to re-enable NTLMv1, and the version 2 option to enable NTLMv2 on a standalone Content Engine. The version 1 option is the default option.

It is very important that you specify that the Content Engine use NTLMv2 when communicating with any of the configured NTLM servers, especially for basic authentication, because with basic authentication the Content Engine is actually generating the NTLMv2 response and is communicating directly with the NTLM server.

Note The default behavior for Microsoft Windows clients is to send the LM and NTLM responses, and by default a Microsoft Windows server will accept these responses. If you want to change the default behavior of either the Microsoft Windows client or server (for example, you want the client and the server to send and receive NTLMv2 responses instead of LM and NTLM responses [NTLM version 1 is also sometimes referred to as simply NTLM]), then you must modify the Windows registry.

For instance, you must change the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibility variable on Windows 9.x systems, or you must change the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel variable on Windows NT and 2000 systems. For information about how to change a Microsoft Windows client registry or a Windows server registry server, refer to your Microsoft Windows documentation.

Note If the domain controller has been configured to support only NTLMv2 for security purposes, you must enter the ntlm version 2 command on the Content Engine to configure the Content Engine to use NTLMv2.

For more information about configuring a list of NTLM servers for a standalone Content Engine, see the "Configuring the NTLM Authentication Service" section.

Configuring Pass-Through Authentication for WMT Requests

In the ACNS 5.2.1 to ACNS 5.4.x software, pass-through authentication support for WMT MMS requests from WMT clients is available. In the ACNS 5.3.1 software and later releases, pass-through authentication support for WMT RTSP requests from Windows Media 9 players is also available. With this support, the Content Engine establishes a virtual connection between the client and the origin server in order for the origin server to authenticate the client. The Content Engine does a pass through and does not function as the proxy authentication server. Consequently, proxy server authentication is not supported for WMT requests.

Note End-to-end authentication is authentication that occurs between the client and the origin server. Pass-through authentication is how the Content Engine handles end-to-end authentication. With pass-through authentication, the Content Engine passes through the authentication request and response between the client and the origin server without examining such requests and responses.

Pass-through authentication for WMT live streams is supported with the following exceptions and requirements:

•Pass-through authentication for a WMT managed live program is not supported. (Managed live programs can be configured in centrally managed deployments only.)

•Pass-through authentication for a static broadcast alias on a Content Engine or for a broadcast point on a Windows Media server is supported. However, when you configure the static broadcast alias on the Content Engine, the client URL to the alias and the source URL to the server must use the same protocol. ACNS software does not support cross-protocol authentication for WMT streams.

In proxy mode, the Windows Media 9 server supports two authentication mechanisms for pass-through authentication of WMT requests:

•Anonymous authentication

•Network authentication

–Negotiate plug-in (NTLM or Kerberos) authentication

–Digest plug-in authentication

Configuring End-to-End Authentication for HTTP Requests

End-to-end authentication is authentication that occurs between the client and the origin server. The HTTP protocol has three ways to authenticate a web client that has issued an HTTP request:

•Basic mode

•NTLM mode

•Microsoft Active Directory (AD)/Kerberos

Note RTP/RTSP supports basic mode for client authentication.

The ACNS 5.2.1 software and later releases support all three modes of client authentication (basic, NTLM, and Active Directory/Kerberos) for pass-through authentication.

End-to-end NTLM authentication using the NTLM method includes pass-through servicing and the caching of web objects that require NTLM authentication.

Basic End-to-End Authentication

The ACNS software can strip NTLM authentication headers to allow fallback to a basic-style authentication challenge against Microsoft IIS servers. Basic authentication is designed to allow browsers to authenticate entered user IDs 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 to the basic authentication method. If the Microsoft IIS server is configured to still accept basic authentication, IIS authentication credentials can proceed through a Content Engine, but with reduced security. Basic authentication is less secure than NTLM authentication because it transmits the user credential information in clear text format.

To configure a standalone Content Engine to strip NTLM headers, enter the http authenticate-strip-ntlm global configuration command.

Basic end-to-end authentication support also includes the ability to configure the Content Engine to cache web objects that are authenticated with the basic authentication method. By default, the Content Engine does not cache such objects. However, you can configure the Content Engine to cache objects that are authenticated with the basic authentication method by entering the http cache-authenticated basic global configuration command.

NTLM End-to-End Authentication

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

•NTLM pass-through service

The Content Engine sets up a secure persistent connection between the client and the server. 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 Content Engine 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 content request from a client already connected with the intended NTLM server, the Content Engine 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.

Note For end-to-end NTLM authentication, both NTLM Version 1 (NTLMv1) and Version 2 (NTLMv2) are supported.

In the following example, the Content Engine is configured for end-to-end NTLM authentication. By default, basic and NTLM authenticated objects are not cached.
ContentEngine(config)# no http authenticate-strip-ntlm
ContentEngine(config)# http cache-authenticated ntlm
ContentEngine# show http cache-authenticated ntlm
NTLM authenticated objects are cached.
Configuring Request Authentication for HTTP Requests

Organizations can use HTTP request authentication (content authentication) as a way to restrict access to online content. If HTTP authentication is configured on a standalone Content Engine, the Content Engine checks with an external authentication, authorization, and accounting (AAA) server for user password authentication to determine if the user should be granted or denied access to the requested content. (See Figure 10-1.)

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

Note ACNS 5.x supports the Lightweight Directory Access Protocol (LDAP), Microsoft NT LAN Manager (NTLM), RADIUS, and TACACS+ protocols, which are used by common AAA servers.

Request authentication and authorization pertain to end user requests that are going through the Content Engine. With request authentication and authorization, the Content Engine is verifying the end user. In contrast, end-to-end authentication and caching of authenticated objects deals with authentication for a particular object, and it is the origin server and not the Content Engine that verifies the end user.

Controlling Content Access for HTTP Requests

For request authentication, ACNS supports LDAP, NTLM, TACACS+, and RADIUS. For request authorization, the ACNS 5.x software supports group-based access lists. In the ACNS 5.2.1 software release, group-based rules were also added and can be used for group-based authorization. With these features, you can require that end users who are making an HTTP request must be authenticated by an external AAA server, and then authorized by the configured access lists or Rules Template.

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 a standalone Content Engine uses to filter HTTP requests (HTTP traffic) as well as HTTPS and RTSP traffic. If you have enabled rules processing on a Content Engine (that is, 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 (policy) to handle this incoming traffic.

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.

For example, the following shows how to enable rule processing on the Content Engine using the rule enable global configuration command and then configure the Content Engine to block all end users in the Engineering group from downloading FTP URLs (FTP requests from a client browser) that contain the expression "java":
ContentEngine(config)# rule enable
ContentEngine(config)# rule pattern-list 1 group-type and
ContentEngine(config)# rule pattern-list 1 groupname Engineering
ContentEngine(config)# rule pattern-list 1 url-regex java
ContentEngine(config)# rule action block pattern-list 1 protocol ftp
Note Authorization through rules based on group names or usernames occurs only after HTTP request authentication and authorization through group-based access lists have occurred. If the configuration in the Rules Template and the group-based access lists match, the access list takes precedence. For more information about configuring the Rules Template for standalone Content Engines, see Chapter 13, "Configuring the Rules Template on Standalone Content Engines."

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 should also authenticate the client before delivering the object to another client. This type of object is called authenticated content.

The following types of content access controls for HTTP requests are supported by standalone Content Engines:

•Authenticating Web Clients Through Pass-Through Authentication

•Authenticating Web Clients Through HTTP Request Authentication

•Configuring Group-Based Access Lists on Standalone Content Engines

Authenticating Web Clients Through Pass-Through Authentication

The HTTP protocol itself has three ways to authenticate end users (web clients) who issue an HTTP request for content that is served through the Content Engine:

•Basic mode

•NTLM mode

•Microsoft Active Directory (AD)/Kerberos

Note RTP/RTSP supports basic mode for client authentication.

Pass-through authentication is used when clients request access to content on a website that requires clients to authenticate themselves (that is, clients must enter their username and password in a popup login window) before the content is sent to requesters. The Content Engine, which is between the client and the website (either through proxy-configuration or transparent interception methods), should not hinder this client authentication. In order to support this authentication exchange between the client and the web server, the Content Engine must pass the authentication exchange between the client and the web server (it must tunnel the authentication exchanges).

Occasionally a website uses 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 on Standalone Content Engines" section on page 15-4.

Note The Content Engine must also guarantee that if it caches any objects that required client authentication (that is, 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.

Authenticating Web Clients Through HTTP Request Authentication

HTTP request authentication is used when the Content Engine communicates with an external AAA server to authenticate the client who is requesting content. This type of authentication is used to allow or prevent a client from accessing the Internet. 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 case, the Content Engine is located at the Internet gateway of the BigCorp company and can be used to enforce this 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.

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. In this case, 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 performs the appropriate actions based on the responses from the AAA server. This type of access control is referred to as HTTP request authentication, and controls what content the client can access through the Content Engine. The ACNS 5.x software supports the LDAP, NTLM, RADIUS, and TACACS+ protocols, which are used by common AAA servers. (See Table 10-1.)

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 the requests from the user to be served by the Content Engine.

In the ACNS 5.2 software release, the ability to specify the list of domains that are allowed to perform NTLM HTTP request authentication through the Content Engine was added.

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 user do not require authentication server lookups.

The Content Engine supports HTTP request authentication for both proxy mode and transparent (WCCP) mode access.

•In proxy mode, the Content Engine uses the client's user ID (UID) as a key for the Content Engine's authentication cache for TACACS+, LDAP, and RADIUS authentication methods.

•In transparent mode for all methods and in proxy mode for NTLM, the Content Engine uses the client's IP address as a key for the Content Engine's authentication cache.

If you are using HTTP request authentication in transparent mode or NTLM in either transparent or proxy mode, we recommend that the AuthTimeout interval configured with the http authentication cache timeout global configuration command be short, because the key for the Content Engine's authentication cache is the client's IP address. IP addresses can be reallocated, or different users can access the Internet through an already authenticated device (such as a PC workstation). Shorter AuthTimeout values help reduce the possibility that individuals can gain access using previously authenticated devices. 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 7-14.

Understanding Proxy Server Mode HTTP Request Authentication

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+, 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.

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.

Understanding Transparent Mode HTTP Request Authentication

When the Content Engine is operating in transparent mode, 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.

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

•Configuring the RADIUS Authentication Service

•Configuring the TACACS+ Authentication Service

•Configuring the LDAP Authentication Service

•Configuring the NTLM Authentication Service

Note NTLM support on the Content Engine includes the following three types of support: (NTLM end-to-end authentication support, NTLM authentication of HTTP requests, and NTLM group information query for authorization purposes. See Table 10-2 for a summary of the types of NTLM support on standalone Content Engines that are running the ACNS 5.x software.

Guidelines for Configuring Request Authentication for HTTP Requests

When configuring HTTP request authentication on a standalone Content Engine, remember the following important points:

•Only one request authentication scheme can be enabled on the Content Engine at a time.

•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. For information about adjusting the size of the authentication cache, see the "Configuring Authenticated HTTP Cache Settings" section on page 7-12.

•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 global configuration 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 client reauthentication.

•For security purposes, the ability to specify an absolute Time To Live (TTL) for HTTP request authentication cache entries was added in the ACNS 5.2 software release. For more information, see the "Specifying a Reauthentication Interval" section on page 7-14.

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

•For additional security, when using NTLM for HTTP request authentication, use the no ntlm basic-auth enable global configuration command. This command prevents the Content Engine from offering the basic authentication method to the client, or prevents the Content Engine from honoring a basic authentication request from the client.

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 5.x 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. The multi-user-prompt has been removed and replaced by the http avoid-multiple-user-prompts option. 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.

The Content Engine uses simple (nonencrypted) authentication to communicate with an LDAP authentication server.

•Authentication servers can be specified with the host option for NTLM, RADIUS, and LDAP servers, or server hostname option for TACACS+ servers.

–NTLM allows up to eight authentication servers for HTTP request authentication. The order of server configuration determines the order of load balancing or failover. For example, the first server configured (server 1) is the primary server and is sent all of the requests first. The last server configured (server 8) is the last server that the Content Engine contacts.

–LDAP allows two authentication servers to be specified.

–RADIUS allows five authentication servers to be specified.

–TACACS+ allows three authentication servers to be specified.

These additional authentication servers act as backup authentication servers and will only be used when the primary authentication server is not available. 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.

•Once a user has been authenticated through a TACACS+, LDAP, NTLM, or RADIUS server, all transaction logs generated by the Content Engine for that user contain user information if a transaction log format containing the username is configured (Extended-Squid format or custom format with %u in the format string).

–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 global configuration command is specified, the user information is suppressed. For more information on transaction logging, see Chapter 21, "Monitoring Standalone Content Engines and Transactions."

•The following are some examples of using the Content Engine CLI to configure HTTP request authentication on a standalone Content Engine:

In this example, the host for the LDAP server is configured:
ContentEngine(config)# ldap server host www.someDomain.com port 390
In this example, the host for the RADIUS authentication server is configured:
ContentEngine(config)# radius-server 172.16.90.121
Configuring an Authentication Service on Standalone Content Engines

For information about how to configure an authentication service on a standalone Content Engine, see the following section:

•Configuring the RADIUS Authentication Service

•Configuring the TACACS+ Authentication Service

•Configuring the LDAP Authentication Service

•Configuring the NTLM Authentication Service

Configuring the RADIUS Authentication Service

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

When the Content Engine communicates with a RADIUS authentication server, the RADIUS server requires that the RADIUS client (Content Engine) to be registered. Additionally, the RADIUS client and server use the secret key. This secret key has to be configured on both the RADIUS server and RADIUS client (Content Engine); the RADIUS client uses this RADIUS key to encrypt and decrypt authentication packets.

In the ACNS 5.4.1 software and later releases, RADIUS authentication for nontransparent FTP native requests is supported. The same process is used to enable and configure RADIUS authentication for HTTP requests and nontransparent FTP native requests. However, the following restrictions apply to FTP native caching support:

•No support for FTP request proxy rules

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

Note No RADIUS authentication will be performed if no RADIUS servers are configured, as described in the "Specifying RADIUS Authentication Settings for Standalone Content Engines" section on page 17-10.

The following is an example of how to configure RADIUS authentication for HTTP requests on a standalone Content Engine:

Step 1 Configure the RADIUS server settings on the Content Engine, as described in the "Specifying RADIUS Authentication Settings for Standalone Content Engines" section on page 17-10.

Step 2 Enable RADIUS authentication for HTTP requests on the Content Engine:

•From the Content Engine GUI, choose Caching > RADIUS to display the RADIUS window. Click the Enable RADIUS On radio button to enable RADIUS authentication on this Content Engine. Click Update to save the settings.

•From the Content Engine CLI, use the radius-server global configuration command.
The redirect option of the radius-server global configuration command redirects an authentication response to a different authentication server if an authentication request using the RADIUS server fails.

The following example enables the RADIUS client on the Content Engine, specifies an external RADIUS server, specifies the RADIUS key, accepts retransmit defaults, and excludes the domain name mydomain.net from RADIUS authentication:
ContentEngine(config)# radius-server enable
ContentEngine(config)# radius-server host 172.16.90.121 
ContentEngine(config)# radius-server key myradiuskey
ContentEngine(config)# rule enable 
ContentEngine(config)# rule no-auth domain mydomain.net 
Note The rule command is relevant to RADIUS only if the radius-server redirect option has been configured.

The configuration is displayed and verified with the show radius-server and show rule all EXEC commands:
ContentEngine# show radius-server
Radius Configuration:
---------------------
Radius Authentication is on
    Timeout       = 5
    Retransmit    = 3
    Key           = ****
    Servers
    -------
    IP 172.16.90.121 Port =   1645    State: ENABLED
ContentEngine# show rule all
Rules Template Configuration
----------------------------
Rule Processing Enabled
rule no-auth domain mydomain.net
Note To disable RADIUS authentication on the Content Engine, use the no radius-server enable global configuration command.

Configuring the TACACS+ Authentication Service

When the Content Engine communicates with a TACACS+ authentication server, the same secret key (for example, tackey) has to be configured on the TACACS+ server and each of the TACACS+ clients (Content Engine, routers, and so forth) that want to communicate with this TACACS+ server.
ContentEngine(config)# tacacs key "tackey"
The TACACS+ server uses this common client key to encrypt or decrypt. The TACACS+ authentication server does not require that the TACACS+ client be registered.

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. The ACNS 4.1 software and later releases support TACACS+ only and not TACACS or Extended TACACS.

In the ACNS 5.4.1 software and later releases, RADIUS authentication for nontransparent FTP native requests is supported. The same process is used to enable and configure RADIUS authentication for HTTP requests and nontransparent FTP native requests. However, the following restrictions apply to FTP native caching support:

•No support for FTP request proxy rules

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

The following example shows how to configure TACACS+ authentication for HTTP requests on a standalone Content Engine:

Step 1 Configure the Content Engine to use one or more TACACS+ servers.
ContentEngine(config)# tacacs server ip_addr [primary]
This example shows how to specify a specific TACACS+ server as a primary server:
ContentEngine(config)# tacacs server 172.16.50.1 primary
This example shows how to specify a specific TACACS+ server as a backup server. This can be achieved by not specifying the primary option:
ContentEngine(config)# tacacs server 172.16.50.2
Step 2 Specify the TACACS+ key.

ContentEngine(config)# tacacs key key

Step 3 Specify the TACACS+ timeout interval. For example, configure the Content Engine to wait 15 seconds before declaring a timeout if it has not received a response from the TACACS+ server:
ContentEngine(config)# tacacs timeout 15
Step 4 Specify the TACACS+ retransmit count.

For example, configure the Content Engine to retransmit only one time to the TACACS+ server if a TACACS+ timeout occurs:
ContentEngine(config)# tacacs retransmit 1
Step 5 Specify the mechanism for TACACS+ password authentication.

For example, use ASCII clear text as the mechanism by entering the ascii keyword:
ContentEngine(config)# tacacs password ascii
Step 6 Enable TACACS+ authentication on the Content Engine.
ContentEngine(config)# tacacs enable
Note For more information about a TACACS+ authentication setting (for example, specifying a TACACS+ key), see Table 17-3. For more detailed information about the tacacs server global configuration command, see the Cisco ACNS Software Command Reference Guide, Release 5.5 publication.

Configuring the LDAP Authentication Service

To address the issue that the X.500 protocol Directory Access Protocol (DAP) was too complex for many directory implementations, the University of Michigan developed the Lightweight Directory Access Protocol (LDAP). LDAP is a directory service protocol that is simpler than the TCP/IP-based version of DAP, and can be used to access information directories.

A standalone Content Engine can be configured to restrict user Internet access by using an LDAP server for authentication purposes, which provides most of the services of the X.500 protocol with less complexity and overhead.

Note To exclude domains from LDAP authentication, use the rule no-auth domain global configuration command. Authentication challenges from LDAP, RADIUS, TACACS+, or SSH take place only if the request does not match the specified no-auth pattern.

Typically, an LDAP client (the Content Engine) queries an LDAP server and obtains the user's credentials such as user's account expiration, privileges, and group membership from the remote LDAP directory on an OpenLDAP or third-party LDAP server. In the ACNS 5.1 software and later releases, the Content Engine can also authenticate and authorize a user who is configured in a remote Active Directory user database on a Microsoft Active Directory server.

Figure 10-2 shows how the Content Engine (an LDAP client) works with any of the following types of servers to perform LDAP authentication of HTTP requests:

•OpenLDAP servers (shareware servers)

•Third-party LDAP servers (for example, a Sun Microsystems iPlanet server)

•Microsoft Active Directory (AD) servers

Note Figure 10-2 shows how the Content Engine performs HTTP request authentication with LDAP if the Content Engine is operating in proxy mode. If the Content Engine were operating in transparent mode, there would also be a WCCP-enabled router between the web clients and the Content Engine (LDAP client).

Figure 10-2 LDAP Authentication of HTTP Requests in Proxy Mode

Note The ACNS 5.x software supports LDAP Version 2 and Version 3 and supports all LDAP features except for Secure Authentication and Security Layer (SASL). The Content Engine uses simple (nonencrypted) authentication to communicate with the LDAP server. Future expansion may allow for more security options based on Secure Socket Layer (SSL), SASL, or certificate-based authentication.

The Active Directory group attribute is an LDAP Version 3 extension. Consequently, the Content Engine must use LDAP Version 3 to query a Microsoft Active Directory server separately for this information.

Table 10-3 lists the features that are supported on the different types of LDAP servers (shown in Figure 10-2). An "x" indicates support of a particular feature.

Table 10-3 Supported Features on LDAP Servers

Feature

Third-Party
LDAP Servers

Open LDAP
Servers

Microsoft Active Directory
Servers

LDAP Version 2

x

x

LDAP Version 3

x

x

x

Organizational units (ou)

x

x

x

Active Directories (AD)

x

Static groups

x

x

x

In the ACNS 5.4.1 software and later releases, LDAP authentication for nontransparent FTP native requests is supported. The same process is used to enable and configure LDAP authentication for HTTP requests and nontransparent FTP native requests. However, the following restrictions apply to FTP native caching support:

•No support for FTP request proxy rules

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

When you configure LDAP authentication of HTTP requests and nontransparent FTP native requests, remember these important points:

•You can configure LDAP authentication of HTTP requests and nontransparent FTP native requests through the Content Engine GUI or the CLI.

•From the Content Engine GUI, choose Caching > LDAP. In the displayed LDAP window, click the Enable LDAP On radio button to enable LDAP authentication, and use the window to configure LDAP authentication. For more information on this topic, click the HELP button in the window.

•From the Content Engine CLI, use the ldap server global configuration command.

–To enable LDAP authentication, use the ldap server enable command

–To specify the LDAP protocol version to be used, use the ldap server version ver_num global configuration command. The options are Version 2 or Version 3. The following example show how to specify LDAP Version 3:
ContentEngine(config)# ldap server enable ldap server version 3
–To specify the number of seconds that the Content Engine is to wait for a response before timing out on a connection to a particular LDAP server, Use the ldap server timeout seconds global configuration command. The default value is 5 seconds.

–To specify the number of connection attempts that are allowed to an LDAP server, Use the ldap server retransmit retries global configuration command. The default is two attempts. This example shows how to set the LDAP retransmit count to 3:
ContentEngine(config)# ldap server retransmit 3
–To specify the user ID attribute, use the ldap server userid-attribute useridword command. By default, uid is specified.

–To specify the filter string (for example, objectclass=user) to be used in the database search, use the ldap server filter filterword global configuration command. There is no default.

–To specify the base distinguished name string for the database search, Use the ldap server base baseword global configuration command. There is no default value for this field. This example shows how to specify the base distinguished name that specifies the starting point for this database search.
ContentEngine(config)# ldap server base dc=cisco,dc=com
–To specify the administrative distinguished name for the database search, use the ldap server administrative-dn name global configuration command. There is no default value for this field.

–To specify the administrative distinguished password for the database search, Use the ldap server administrative-passwd passwd global configuration command. There is no default value for this field.

–To specify the port number on which the LDAP server is listening, use the ldap server port port-num global configuration command. The default port number is 389.

–Specify the LDAP server that the Content Engine should use for authentication. (A primary and secondary LDAP server can be specified.)

To designate an LDAP server as the primary server, use the ldap server host {hostname | hostipaddress} primary global configuration command. Specify the IP address or hostname of the primary LDAP server.

To designate an LDAP server as the secondary server, use the ldap server host {hostname | hostipaddress} secondary global configuration command. Specify the IP address or hostname of the primary LDAP server.

This example shows how to specify two LDAP servers as primary and secondary HTTP request authentication servers:
ContentEngine(configure)# ldap server 172.16.1.1 primary
ContentEngine(configure)# ldap server 172.16.1.2 secondary
Note No LDAP authentication will be performed if no LDAP servers are configured.

–To retrieve group names from the LDAP database for group-based authorization, use the ldap server group global configuration command. Use this command to instruct the LDAP server, which is performing the database query, to retrieve the names of the groups that the authenticated user belongs to (for example, Marketing or Engineering). The Content Engine uses these retrieved group names to perform LDAP group-based authorization by checking its access lists to determine whether the groups should be granted or denied access to the requested content.

Note The ACNS 5.1 software and later releases support LDAP Version 2 and Version 3 and supports all LDAP features except for Secure Authentication and Security Layer (SASL).

Table 10-4 lists the Content Engine's default configuration for LDAP authentication of HTTP requests.

Table 10-4 Default Configuration for LDAP Authentication of HTTP Requests

Feature or Setting

Default Value

LDAP authentication

Disabled

Allow mode

Disabled

Base distinguished name

None specified (an empty string)

Filter for database searches

None specified

LDAP retransmit attempts

2 times

LDAP server timeout

5 seconds

User ID attribute

uid

Group attribute

•Organization unit (ou)

•Custom attribute

•Active Directory (memberOf)

Enabled

Disabled

Disabled

Static group database queries

•Group attribute

•Group member

•Nested groups

•Nested level

Disabled

None specified

None specified

Disabled

1 level

Administrative distinguished name

None specified

Administrative password

None specified

LDAP version

LDAP Version 2

LDAP port

Port 389

Policy redirect feature

Disabled

Password expiry feature

Disabled

Primary LDAP server

None specified

Secondary LDAP server

None specified

Example of Configuring LDAP Authentication Service

The following example shows how to use the Content Engine CLI to configure LDAP authentication for HTTP requests and nontransparent FTP native requests on a standalone Content Engine:

Step 1 Specify the IP address or hostname of the LDAP authentication server that the Content Engine should use to authenticate HTTP requests and nontransparent FTP native requests.
ContentEngine(config)# ldap server host 10.1.1.1
Step 2 Configure the Content Engine to use LDAP Version 3 versus LDAP Version 2 (the default), if necessary.

Figure 10-2 shows that the LDAP client on the Content Engine can send LDAP Version 2 or Version 3 requests to an OpenLDAP server or a third-party LDAP server. However, the Content Engine must use LDAP Version 3 to communicate with a Microsoft Active Directory server. By default, the Content Engine uses LDAP Version 2. To change this default, use the ldap server version 3 global configuration command.
ContentEngine(config)# ldap server version 3
Step 3 By default, LDAP authentication of HTTP requests and nontransparent FTP native requests is disabled on a Content Engine. Enable LDAP authentication on the Content Engine, as follows:
ContentEngine(config)# ldap server enable
Step 4 Specify the search criteria.

These search criteria are passed to the LDAP server, which uses these criteria to search through its user database. The LDAP server retrieves the user's password for authentication. If the user is authenticated, then the LDAP server searches through its database for the requested user membership information, and returns this information to the Content Engine.

Search criteria can include such information as the group attribute (for example, organizationUnit or Active Directory), the name of the user identification (UID) attribute, and the starting point of the search. You can also specify a filter (for example, objectclass=users) to restrict the scope of the database search. If the Content Engine is configured for group-based authorization, then the Content Engine will use the retrieved group names to perform group-based authorization for authenticated users. For more information on group-based authorization through access lists, see the "Configuring Group-Based Authorization for HTTP Requests" section.

To specify the search criteria, you must understand the structure of the user database being queried. For example, the Content Engine by default will request that the authentication server search its database for organizational unit (ou) group membership.

Note You can search an OpenLDAP server, a third-party LDAP server, or a Microsoft Active Directory server for organizational unit group membership information. You can only search for Active Directory group membership if the authentication server is a Microsoft Active Directory server.

The organizational unit option and the Active Directory option are independent parameters. You can configure a Content Engine to search a Microsoft Active Directory server database for organizational unit group membership as well as Active Directory group membership.

You can change this default. The following example shows how to configure the Content Engine to query a Microsoft Active Directory server for only the Active Directory group membership and not the organizational unit group membership for authenticated users:
Content Engine(config)# ldap server group active-directory enable
The following sample output shows that the Content Engine is now configured to search the Microsoft Active Directory server database for Active Directory group membership (memberOf) for authenticated users:
ContentEngine# show ldap
LDAP Configuration:
-------------------
 LDAP Authentication is enabled
        Allow mode:     disabled
        Base DN: 	"DC=cisco,DC=com"
        Filter:         <none>
        Retransmits:    2
        Timeout:        5 seconds
        UID Attribute:  sAMAccountname
        Group Attribute:
           organizationUnit: 	 disabled  (ou)
           Custom Attribute:     disabled
           Active Directory:	 enabled (memberOf)
Note For more information on the structure of the LDAP database, see the "Understanding the Structure of the LDAP Database" section.
You can also configure the Content Engine to perform group-based authorization for HTTP requests after a user has been successfully authenticated. If the Content Engine is configured for group-based authorization, then the Content Engine checks its access lists to determine whether the groups that the authenticated user belongs to should be granted or denied access to the requested content. Based on the results of this LDAP group-based authorization, the Content Engine grants or denies user access to the requested content. (See Figure 10-1.)

In order for LDAP group-based authorization to occur, you must have completed the following prerequisite tasks on the Content Engine:

•Enabled and configured group name-based access lists, as described in the "Example of Configuring LDAP Group Authorization with Group-Based Access Lists" section.

•Configured the Content Engine to request that the LDAP server retrieve the names of the groups that the authenticated user belongs to (for example, Marketing or Engineering). You must understand the structure of the user database being queried in order to configure the Content Engine to request this information retrieval. For more information on this topic, see the next section, "Understanding the Structure of the LDAP Database."

Understanding the Structure of the LDAP Database

In order to configure the LDAP client on the Content Engine to query a remote user database, you must understand the structure of the user database being queried.

LDAP database entries are arranged in a hierarchical directory tree that reflects logical or geographic boundaries. The LDAP directory has the following structure. (See Figure 10-3.)

•The topmost node of the LDAP directory tree is named root.

•Below the root, there are organization nodes (o) for companies, states, or national organizations (for example, o=cisco, o=texas, and o=redcross).

•Below organization nodes, there are LDAP group nodes for such organizational units as departments (for example, ou=Marketing and ou=Engineering) and branch offices.

•At the bottom of the tree, there are individual nodes (cn) for common names of people (for example, cn=Jane Smith), documents, and such shared resources as printers.

Figure 10-3 LDAP Database Structure

Note Because the groups named Hardware Engineers and Software Developers are nested under the parent group named Engineering, they are called nested groups. Nested groups allow the LDAP server administrator to create hierarchical relationships that can be used to define inherited group membership.

An LDAP directory can contain such information as text, photographs (JPEGs), URLs, binary data, and public key certificates.

About LDAP User Database Entries

An entry in an LDAP user database (an LDAP directory) is a collection of attributes that has a name, called a distinguished name (dn). Each of the entry's attributes has a type, name, and one or more values.

•Attribute type—An integer, string, or character

•Attribute name—Name of the attribute (for example, cn for a common name, givenName for a given name [first name], or mail for an e-mail address)

•Attribute value—Value of the attribute (for example, Jane Smith, Jane, or jsmith50@cisco.com)

The following example shows the complete database entry for Jane Smith in an OpenLDAP or third-party LDAP server database:
# Jane Smith, cisco, com
dn: cn=Jane Smith,dc=cisco,dc=com
telephoneNumber: (408) 123-9100
mail: jsmith50@cisco.com
uid: jsmith50
givenName: Jane
sn: Smith
cn: Jane Smith
The following example shows the complete entry for Jane Smith in a Microsoft Active Directory server database:
# Jane Smith, cisco, com
dn: CN=Jane Smith,DC=cisco,DC=com
memberOf: CN=Users,DC=cisco,DC=com
telephoneNumber: (408) 123-9100
mail: jsmith50@cisco.com
uid: jsmith50
givenName: Jane
sn: Smith
cn: Jane Smith
An entry in an LDAP user database is referenced by its distinguished name (dn). A distinguished name is constructed by taking the name of the entry itself and concatenating the names of its ancestor entries in the hierarchical directory structure of the LDAP database. For example, if the common name (cn) is Jane Smith and this individual belongs to the organization named cisco, then the distinguished name for this LDAP directory entry is as follows:

•cn=Jane Smith,dc=cisco,dc=com for an OpenLDAP server or a third-party LDAP server

•CN=Jane Smith,DC=cisco,DC=com for a Microsoft Active Directory server

About User Groups in an LDAP Directory

An LDAP directory can contain groups of users that are part of an LDAP group (for example, groups named Marketing and Engineering). An LDAP group is a list, which is a collection of names. An LDAP group has an objectclass attribute of groupOfNames, and consists of one or more members. (A group cannot be empty.)

As part of an LDAP database search, the LDAP server can be instructed to retrieve the group names of the authenticated user. The Content Engine uses the retrieved group names and its group name-based access lists to perform group-based authorization for these LDAP users.

Note LDAP allows you to control which attributes are required and allowed in an entry through the special attribute named objectclass. The values of the objectclass attribute determine the schema rules the entry must obey. For more details on LDAP, see the RFC 1777 Lightweight Directory Access Protocol.

There are multiple ways to support LDAP grouping in a user database:

•Grouping LDAP Users into Organizational Units

•Grouping LDAP Users into Static Groups

•Grouping Users into Active Directory Groups

The method that the database administrator used to group users in a database determines how you must configure the Content Engine to query that database for user membership information. For examples of how to use the CLI to configure the Content Engine to perform LDAP directory queries, see the "Querying LDAP Servers for User Membership Information" section.

In LDAP Version 3, groups can be defined as static, dynamic, or organizationUnit (organizational units). The groups can be nested. The ACNS 5.1 software and later releases support static and organizationUnit groups but do not support dynamic groups.

Grouping LDAP Users into Organizational Units

When the LDAP server administrator groups LDAP users based on organizational units (for example, Marketing), the administrator can assign a user to any group, and can nest groups. An organizational unit is synonymous with a native LDAP group. This method is also referred to as native LDAP group configuration. All conventional LDAP Version 3 servers support native LDAP group configuration in the user database.

By default, the Content Engine is configured to query an LDAP server for organizational unit group membership. The following example shows the two entries in the LDAP database that are used to assign the LDAP user named Penny Gold to the organizational unit named Marketing.

In the first database entry, the LDAP server administrator defines the group node for the organizational unit named Marketing.
dn: cn=Marketing,dc=cisco,dc=com
cn: Marketing
objectclass: groupOfNames
In the second database entry, the administrator defines the individual node for Penny Gold. This node contains all of Penny Gold's user membership information.
# Penny Gold, marketing, cisco, com
dn: cn=Penny Gold,ou=Marketing,dc=cisco,dc=com
telephoneNumber: (408) 123-4444
mail: pgold@cisco.com
uid: pgold
givenName: Penny
sn: Gold
cn: Penny Gold
Because Penny Gold's organizational unit (ou) is specified as Marketing, she is assigned the group privileges of this particular group. If you have configured the Content Engine for group-based authorization (for example, configured an access list that permits the members of the Marketing group to access content that is served through the Content Engine). And when the Content Engine has authenticated Penny Gold, it will grant her access to the requested content because she is a member of the Marketing group.

Based on the above database structure, the following example shows how you would configure the Content Engine to query this database for user membership information for such users as Penny Gold. The server with an IP address of 172.16.1.1 (an OpenLDAP server or the third-party LDAP server) is instructed to start the database search at the node named Marketing, to search for the user identification (username and user password), and to retrieve the group names of the authenticated user.
ContentEngine(config)# ldap server 172.16.1.1
ContentEngine(config)# ldap server userid-attribute uid
ContentEngine(config)# ldap server organizationUnit enable
ContentEngine(config)# ldap server base "dc=cisco,dc=com"
ContentEngine(config)# ldap server enable
Because the organizationUnit option is enabled, the LDAP server queries the database for the organizationUnit configuration (ou attribute) of the user account. If the user belongs to more than one organizational unit, the LDAP server will return a string that contains all of the group names to which the user belongs. If the Content Engine is configured for LDAP group-based authorization, it uses the retrieved group names and its access lists to perform group-based authorization on the authenticated user.

Grouping LDAP Users into Static Groups

When the LDAP server administrator uses static groups to group LDAP users in a user database, the administrator explicitly specifies each member of the static group individually. LDAP administrators assign users to an LDAP static group in order to set up a user's authorization privileges. A user's access to the Internet is allowed or denied based on the privileges that have been assigned to the static group (for example, Engineering or Hardware Engineers).

A static group defines each member individually using the object class attribute of groupOfNames or groupOfUniqueNames. These object classes require the attribute member (groupOfNames) or uniqueMember (groupOfUniqueNames). There is a one-to-one correspondence between the object class name and the member name attribute. A static group that uses these structural object classes must have at least one member; it cannot be empty.

The Content Engine LDAP static group feature allows you to query both object classes (groupOfNames and groupOfUniqueNames) for group members.

•The following example shows how to query the database for the object class named groupOfNames:
ContentEngine(config)# ldap server group static member-attribute member
ContentEngine(config)# ldap server group static enable
•The following example shows how to query the database for the object class named groupOfUniqueNames:
ContentEngine(config)# ldap server group static member-attribute uniquemember
ContentEngine(config)# ldap server group static enable
Note The ACNS 5.x software now supports static group queries of an LDAP user database. Static groups are supported on OpenLDAP servers, third-party LDAP servers, and Microsoft Active Directory servers.

The following example shows how an LDAP server administrator can configure static groups in an LDAP database:

1. The LDAP server administrator defines the following nodes in the LDAP database:

–The root node named .com

–The organization node named cisco

–A node for the organizational unit (ou) named Engineering

–A node for the Hardware Engineers group that is nested under the Engineering group

–A node for the Software Developers group that is nested under the Engineering group

–An individual node for the user named Jay Doe

–An individual node for the user named Don Smith

The following example shows how the LDAP server administrator defines a node for the user Jay Doe:
# Jay Doe, Engineers, cisco, com
dn: cn=Jay Doe,ou=Engineering,dc=cisco,dc=com
telephoneNumber: (408) 123-8910
mail: jdoe8@cisco.com
uid: jdoe8
givenName: Jay
sn: Doe
cn: Jay Doe
The following example shows how the LDAP server administrator defines a node for the user Don Smith:
# Don Smith, Engineers, cisco, com
dn: cn=Don Smith,ou=Engineering,dc=cisco,dc=com
telephoneNumber: (408) 123-4567
mail: dsmith7@cisco.com
uid: dsmith7
givenName: Don
sn: Smith
cn: Don Smith
2. The LDAP server administrator assigns specific members to static groups.

The following example shows how the LDAP server administrator explicitly specifies that the parent group named Engineering has two static members (the groups named Hardware Engineers and Software Developers). The groups named Hardware Engineers and Software Developers are nested static groups; they are nested under the parent group.
dn: cn=Engineering,dc=cisco,dc=com
cn: Engineering
objectclass: groupOfNames
member: cn:Hardware Engineers,dc=cisco,dc=com
member: cn:Software Developers,dc=cisco,dc=com
The following example shows how the LDAP server administrator explicitly assigns Jay Doe and Don Smith to the static group named Hardware Engineers. This is a one-way link between the two connected nodes because the member attribute is used. If the member of attribute were used; a two-way link would be created between the two connected nodes. Connecting nodes with a two-way link reduces the number of TCP requests that are required to search through the database for user membership information.
dn: cn=Engineers,dc=cisco,dc=com
cn: Hardware Engineers
object: groupOfNames
member: cn:Jay Doe,ou=Engineering,dc=cisco,dc=com
member: cn:Don Smith,ou=Engineering,dc=cisco,dc=com
By default, static group queries and nested group queries are disabled on the Content Engine (as shown in the following excerpt of sample output from the show ldap EXEC command).
ContentEngine# show ldap 
LDAP Configuration:
-------------------
Static Groups:           disabled
           Group Attribute:
           Group Member:
           Nested Groups:        disabled
           Nested Level:         1
However, you can use the CLI to enable and configure such queries on a standalone Content Engine, as described in these sections:

•Searching for User Account Information for LDAP Direct Static Groups

•Searching for User Account Information for LDAP Nested Static Groups

Grouping Users into Active Directory Groups

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.

In the ACNS 5.1 software and later releases, the LDAP client on a Content Engine provides LDAP support for Active Directory groups. Microsoft Active Directory only supports LDAP Version 3. By default, the Content Engine uses LDAP Version 2. Therefore, use the ldap server version 3 global configuration command to configure the Content Engine to use LDAP Version 3 before enabling the LDAP Active Directory feature on the Content Engine.
ContentEngine(config)# ldap server version 3
To request that the LDAP server query the Active Directory group membership:
ContentEngine(config)# ldap server group active-directory enable
Note The Active Directory group attribute is an LDAP Version 3 extension, and must be queried separately.

The following is an entry sample from a user account in an Active Directory database:
dn: CN=Penny Gold,CN=Users,DC=cisco,DC=local 
memberOf: CN=Marketing,DC=cisco,DC=local
The memberOf attribute and a group name for each individual group were added to the user's account configuration. The memberOf attribute does not support the nested group structure.

About LDAP Directory Searches

The LDAP directory service is a global directory service that allows LDAP clients (Content Engines) to access information that is stored in an LDAP directory, as follows:

1. The Content Engine connects to the specified LDAP server and queries the LDAP server for specific user membership information (for example, user identification [userid] and user password [userpassword]).

The following example shows how to configure the Content Engine to query a standard LDAP server for user identifications (user ID and password), and to ask the LDAP server to retrieve the names of any organizational units (groups) that a user belongs to:
ContentEngine(config)# ldap server userid-attribute uid 
ContentEngine(config)# ldap server organizationUnit enable

The Content Engine administrator configures the search criteria on the Content Engine. For more information on this topic, see the "Querying LDAP Servers for User Membership Information" section.

2. The LDAP server searches its user database (an LDAP directory) for any entry that matches the specified search criteria.

a. The LDAP server checks whether the organizationUnit option is enabled on the Content Engine:

–If the organizationUnit option is enabled, the LDAP server queries the database for the organizationUnit configuration (ou attribute) of the user account. If the user belongs to more than one organizational unit, the LDAP server returns a string that contains all of the group names to which the user belongs (for example, Marketing,Engineering).

–If the organizationUnit option is disabled, then the LDAP server does not perform the query.

b. The LDAP server checks whether the Active Directory group (memberOf) option is enabled:

–If the memberOf option is disabled, then the LDAP server (the Microsoft Active Directory server) does not perform the query.

–If the memberOf option is enabled, then the LDAP server queries the Microsoft Active Directory server database for the Active Directory group configuration of the user account. The Microsoft Active Directory server collects the group names from the memberOf attribute of the user account, and returns this information to the Content Engine.

Note The Active Directory group attribute is an LDAP Version 3 extension, and therefore must be queried separately.

c. The LDAP server checks whether the custom group option is enabled on the Content Engine:

–If the custom group option is disabled, then the LDAP server does not perform this query.

–If the custom group option is enabled, the LDAP server collects the group names from the custom attribute of the user account and returns this information to the Content Engine.

d. The LDAP server checks whether the static group option is enabled on the Content Engine:

–If the static group option is disabled, the LDAP server does not perform the query.

–If the static group option is enabled, the LDAP server queries the database for the static group configuration. The server collects the names of the groups and returns this information to the Content Engine.

3. The LDAP server responds to the query from the Content Engine with the requested information or with a message that it was unable to find the requested information:

–If the user is not a valid user, then HTTP authentication fails. In this case, the Content Engine denies the user's request to access the content.

–If the user is a valid user, then HTTP authentication succeeds. If group-based authorization has not been enabled on the Content Engine, then the Content Engine grants the user access to the content at this point. If the Content Engine is configured for group-based authorization (for example, the access-lists 300 enable global configuration command has been used and the access lists have been defined), then the Content Engine uses the retrieved group names to determine whether the user should be granted access to the requested content.

Note The retrieved user membership information is used for group-based authorization only. For more information about group-based authorization for LDAP users, see the "Example of Configuring LDAP Group Authorization with Group-Based Access Lists" section.

Configuring the LDAP Cache on Standalone Content Engines

In the ACNS 5.4.1 software release, LDAP memory cache support for nested group searches was added. This feature enables the Content Engine to store the results of a nested group search locally in its LDAP cache. To support this new feature, the mem-cache option was added to the ntlm server ad-group-search global configuration command.

Use the ntlm server ad-group-search mem-cache global configuration command to enable and configure the LDAP cache on standalone Content Engines:

ContentEngine(config)# ntlm server ad-group-search mem-cache ?

enable Enable ldap in-memory cache. (Default is Enabled)

max-ttl Maximum amount of time from creation an entry is valid in the ldap

in-memory cache

size Maximum size of ldap in-memory cache to allocate in KBytes.

Note The LDAP cache is sometimes called the "LDAP in-memory cache" because this cache resides on the Content Engine. "AD" is an abbreviation for Active Directory.

By default, the LDAP memory cache is enabled on the Content Engine, the cache size is set to 128 KB, and the maximum time to live (max-ttl) is set to 480 minutes. Valid values for the cache size are 128 to 10240 KB. Valid values for the maximum time to live are 1 to 1440 minutes.

To disable the LDAP memory cache feature, enter the no ntlm server ad-group-search mem-cache global configuration command.

Querying LDAP Servers for User Membership Information

This section provides some examples of how to configure the Content Engine to perform LDAP directory queries:

•Searching for User Account Information for Individuals in an LDAP Database

•Searching for User Account Information for LDAP Direct Static Groups

•Searching for User Account Information for LDAP Nested Static Groups

Note All of these examples assume that the LDAP directory that is being queried has the structure depicted in Figure 10-3.

Searching for User Account Information for Individuals in an LDAP Database

The following example shows how to configure a Content Engine to search for user account information for individuals (for example, Jane Doe) in an LDAP user database:

Step 1 Specify the LDAP server that the Content Engine should use for this database search.
ContentEngine(config)# ldap server 172.16.1.1
By default, port 389 is configured as the TCP port for the LDAP authentication server. To specify another port for the LDAP server, use the ldap server port port-num command. Valid port numbers are 1 through 65535.

Step 2 Specify the base distinguished name that is the starting point for this database search.
ContentEngine(config)# ldap server base "dc=cisco,dc=com"
Step 3 Enable LDAP authentication on the Content Engine.
ContentEngine(config)# ldap server enable
Step 4 Specify the search criteria.

a. In this case, the LDAP server is requested to search for user IDs (username and user password).
ContentEngine(config)# ldap server userid-attribute uid 
b. Enable the organizationUnit option on the Content Engine. This instructs the LDAP server to retrieve the group name from the ou attribute of the user account.
ontentEngine(config)# ldap server organizationUnit enable
Searching for User Account Information for LDAP Direct Static Groups

The following example shows how to configure the Content Engine to request that the specified LDAP server perform a direct (nonnested) static group database query. This type of query enables the Content Engine to perform HTTP request authentication for users who have been assigned to a direct static group (a parent static group).

In this example, the LDAP database is queried for user account information for the direct static group named Engineering.

Step 1 Specify the LDAP server that the Content Engine should use for this database search.
ContentEngine(config)# ldap server 172.16.1.1
Step 2 Specify the group attribute to query.

In this example, the LDAP server will search the static group configurations for the group attribute named cn for common name:
ContentEngine(config)# ldap server group static group-attribute cn
Step 3 Specify the group member attribute to query.

In this example, the LDAP server searches the static group configurations for the group member attribute named member:
ContentEngine(config)# ldap server group static member-attribute member
Step 4 Specify the base distinguished name that is the starting point for this database search.
ContentEngine(config)# ldap server base "dc=cisco,dc=com"
Step 5 Enable LDAP authentication on the Content Engine.
ContentEngine(config)# ldap server enable
Step 6 Enable static group queries of an LDAP user database.
ContentEngine(config)# ldap server group static enable
Searching for User Account Information for LDAP Nested Static Groups

The following example shows how to configure the Content Engine to request that the specified LDAP server perform a nested static group database query. In this case, the LDAP directory is searched for user account information for any static groups that are nested under the parent group named Engineering.

Step 1 Specify the LDAP server that the Content Engine should use for this database search.
ContentEngine(config)# ldap server 172.16.1.1
Step 2 Specify the nested level of the static group that you want to search for in the LDAP directory.

By default, the LDAP server searches the LDAP directory one level down from the starting point of the search. In this case, the two nested static groups Hardware Engineers and Software Developers are nested two levels down from the starting point of the search (the organizational node named cisco). In this example the LDAP server is instructed to search two levels down.
ContentEngine(config)# ldap server group static nested level 2
Step 3 Specify the group attribute to query.

In this example, the LDAP server searches the nested static group configurations for the group attribute named cn for common name:
ContentEngine(config)# ldap server group static group-attribute cn
Step 4 Specify the group member attribute to query.

In this example, the LDAP server searches the static group configurations for the group member attribute named member:
ContentEngine(config)# ldap server group static member-attribute member
Step 5 Specify the base distinguished name that is the starting point for this database search.
ContentEngine(config)# ldap server base "dc=cisco,dc=com"
Step 6 Enable LDAP authentication on the Content Engine.
ContentEngine(config)# ldap server enable
Step 7 Enable nested static group queries of the LDAP database.
ContentEngine(config)# ldap server group static nested enable
Configuring the NTLM Authentication Service

In the ACNS 5.4.1 software release, support of NTLM authentication for nontransparent FTP native requests was added.

In the ACNS 5.2.1 software and later releases, the following enhancements for NTLM HTTP request authentication are available:

•Support for up to eight NTLM servers for HTTP request authentication—Ability to configure the Content Engine to use up to eight NTLM servers for HTTP request authentication for load-balancing purposes. The ACNS 5.1.x software and earlier releases supported failover only. For more information, see the "About NTLM Load Balancing for HTTP Request Authentication" section.

•Support for up to eight Global Catalog servers for Active Directory group searches—Ability to configure the Content Engine to use up to eight Global Catalog servers for Active Directory group searches. See the "Configuring Content Engines for Active Directory Group Searches" section.

Note The order of server configuration determines the order of load balancing or failover. For example, if failover is enabled, then the first server configured (Server 1) is the primary server and is sent all of the requests first. The last server configured (Server 8) is the last server that the Content Engine contacts. If load balancing is enabled, only the first request is sent to the first configured server (Server 1), after which round-robin is used among the remaining servers (for example, the second request is sent to Server 2, and the third request is sent to Server 3).

•Changes to the Active Directory group search feature—LDAP queries are sent to the same Active Directory server that is assigned to perform the authentication unless the LDAP query fails, in which case the Content Engine sends the authorization request to the next configured server (the Content Engine only tries one more server).

•If the NTLM nested group search feature is enabled, you no longer need to configure the ldap-search-server host global configuration command. The Content Engine automatically uses the IP address of the configured NTLM server to send the LDAP queries.

•New scheme command option for NTLM servers—A scheme option was added to the ntlm server and ntlm server ad-group-search gc-server global configuration commands. This option allows you to specify the scheme (load balancing or failover) that is to be used among the configured NTLM or Global Catalog servers. The default scheme is failover. To specify the scheme for the NTLM servers for HTTP request authentication, use the ntlm server scheme global configuration command. To change the scheme for the Global Catalog servers for Active Directory group searches, use the ntlm server ad-group-search gc-server scheme global configuration command as shown in the second example:
ContentEngine(config)# ntlm server ?
  ad-group-search     Active Directory group search options
  connection-retry    Maximum attempts to connect to server
  connection-timeout  Time to wait connecting to server (second
  domain              Specify Domain name
  enable              Enable NTLM Authentication
  host                Host options
  scheme              Scheme to use for the host list
ContentEngine(config)# ntlm server ad-group-search gc-server ?
  host    Specify global catalog server address
  port    Specify global catalog server port, default 3268
  scheme  Scheme to use for the host list
•Polling thread—Once one of the configured NTLM or Global Catalog servers is marked as dead, it is removed from the load-balancing or failover farm to prevent the Content Engine from directing incoming requests to it. The Content Engine periodically polls the dead server (every 30 seconds). If the Content Engine receives a response from the server, it adds the server back into the load-balancing or failover farm.

•Authentication method controls for NTLM—Ability to enable or disable the Content Engine from sending a basic authentication response header along with an NTLM authentication header. For more information, see the "Configuring the Authentication Method Control for NTLM HTTP Request Authentication" section.

•Support for no default NTLM domain—If the client does not supply a domain name in the request authentication credential and there is no default domain configured on the Content Engine, then an authentication error is returned to the client. A predetermined error page that contains text indicating the reason for the error is sent to the client. This feature is also referred to as the "no domain configuration" feature.

Note The no domain configuration feature is only supported with browsers that do not support NTLM (for example, Netscape 7.1 or earlier browsers [Netscape 7.2 and later browsers support NTLM]). 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 message. For the Netscape browser, the domain can only be supplied as part of the username in the format 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 user being prompted to specify the credentials or from the domain that was used to log in the user on to the desktop.

•Configurable allow domain list—Ability to specify the list of domains that are allowed to perform NTLM HTTP request authentication with the Content Engine. For more information, see the "Configuring a List of Allowed Domains List NTLM HTTP Request Authentication" section.

•To configure the Content Engine to send the username and domain name to the transaction log, use the transaction-logs log-window-domain global configuration command. The Windows domain name that is used for NTLM authentication appears in the usename field of the transaction log. The username appears in the format domain\username in those formats that contain usernames that are in Extended Squid-style or custom format using the %u format token.

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.

For clients outside the domain using the Netscape 7.1 or earlier browser, a dialog box appears and the first authentication request asks the client to enter a username and password. Once the client is successfully authenticated, the entry is placed in the cache, and no reauthentication requests are made to the client until the authentication cache entry expires.

•In the ACNS 5.3.x software and earlier releases, NTLMv1 is supported for NTLM HTTP request authentication (that is, NTLM request authentication for requests over the HTTP protocol). In the ACNS 5.4.1 software and later releases, both NTLMv1 and NTLMv2 are supported for NTLM HTTP request authentication. For more information on this topic, see the "About NTLM Support on Content Engines" section.

About NTLM Load Balancing for HTTP Request Authentication

In the ACNS 4.x software to the ACNS 5.1.x software, you needed to configure one primary domain controller for HTTP request authentication and a secondary domain controller for failover. However, in large-scale networks, if all the traffic passes through the Content Engine, even though the Content Engine authentication cache can help reduce the load on the domain controller, it may still be impractical to have a single domain controller handle authentication queries from all of the end users.

To address this concern, load balancing between domain controllers was added in the ACNS 5.2 software. With the ACNS 5.2.1 software and later releases, you can configure up to eight servers (domain controllers) for load-balancing and failover purposes. The order of server configuration determines the order of load balancing or failover.

When load balancing is selected as the scheme, the requests are round-robined between the domain controllers. For example, if you have n servers (domain controllers), the first request goes to Server 1, the second request is sent to Server 2, the nth request is sent to Server n, and the (n+1)th request is sent to Server 1. If Server 1 fails, the Content Engine attempts to send the request to the next configured server that is alive (in this case, Server 2). However, failover to the next alive server occurs only once. For example, if Server 2 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. The configuration of each configured NTLM or Global Catalog server is available through the show ntlm EXEC command. Statistics about the total number of requests going through the servers is collected and available through the show statistics ntlm EXEC command. Statistics about requests going through each domain controller are also collected and available through the show statistics ntlm EXEC command.

Note If the Active Directory nested group search is enabled, only servers in the same domain are supported. If the Active Directory nested group search is not enabled, servers in multiple domains are supported if the servers have a trusted relationship.

Configuring the Content Engine to Use NTLM Servers for HTTP Request Authentication

You can use the Content Engine GUI or the CLI to configure a standalone Content Engine to use external NTLM servers for HTTP request authentication.

In the ACNS 5.1.x software and earlier releases, you explicitly designated a primary NTLM server and a secondary NTLM server by using the primary and secondary options of the ntlm server host global configuration command, as shown below:
ContentEngine(config)# ntlm server host 172.16.10.10 primary
ContentEngine(config)# ntlm server host 172.16.10.12 secondary
In the ACNS 5.2.1 software and later releases, 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. For example, if the failover is enabled then the first server configured (Server 1 that has an IP address of 172.16.10.10) is the primary server and is sent all of the requests first. The last server configured (Server 3 that has the IP address of 172.16.10.14) is the last server that the Content Engine contacts. If the load balancing is enabled, only the first request is sent to the first configured server (Server 1), after which round-robin is used among the remaining servers (for example, the second request is sent to Server 2, and the third request is sent to Server 3).
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
Note In the ACNS 5.2 software release, the ntlm server host primary option and the ntlm server host secondary options were removed because up to eight servers are now supported. In the ACNS 5.2.1 software release, the ntlm server host scheme load-balanced option was added.

You can use the Content Engine GUI or the CLI to configure the Content Engine to use up to eight NTLM servers for HTTP request authentication.

From the Content Engine GUI, choose Caching > NTLM to access the NTLM window. Use the NTLM window to specify NTLM server settings on the Content Engine, and click Update. For more information about the fields on the NTLM window, click the HELP button in the window.

From the Content Engine CLI, use the ntlm server global configuration command.

The following example describes how to use the Content Engine CLI to configure a standalone Content Engine to use the maximum number of servers (eight NTLM servers) to load balance HTTP authentication requests:

Step 1 Specify the hostname or IP address of each NTLM server that you want the Content Engine to use for HTTP request authentication by using the ntlm server host global configuration command. This list of configured NTLM servers is referred to as the host list.

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
Step 2 Specify whether the Content Engine is to use NTLMv2 for request authentication when communicating with any of the configured NTLM servers.

By default, the Content Engine will use LM or NTLMv1. In the ACNS 5.4.1 software release, NTMLv2 support for request authentication of HTTP requests was added. By default, the NTLMv2 feature for request authentication is disabled on the Content Engine, and the Content Engine will use NTLMv1. In the following example, the Content Engine is configured to use NTLMv2 for request authentication with any of the configured NTLM servers:
ContentEngine(config)# ntlm version 2
For more information on this topic, see the "About NTLM v2 Support for Request Authentication" section.

Step 3 Specify the maximum number of times that the Content Engine is to attempt to connect to one of the configured NTLM servers.

In the following example, this value is set to 3:
ContentEngine(config)# ntlm server connection-retry 3
The default is two attempts. Valid values are from one to three attempts. After the specified number of attempts is exceeded, the Content Engine stops attempting to connect to the NTLM server and attempts to connect to the next configured server on the host list.
Step 4 Specify how long the Content Engine should wait for a response from the NTLM server that it is attempting to connect.

In the following example, this timeout is set to 10 seconds:
ContentEngine(config)# ntlm server connection-timeout 10
This is the timeout for one connection attempt. If the specified amount of time is exceeded, the Content Engine gives up the connection and attempts to connect to the same server up to the specified number of times (the number of retries specified with the ntlm server connection-retry global configuration command) before the Content Engine attempts to connect to the next server. The default is 5 seconds. Valid values are from 1 to 20 seconds.
Step 5 Specify whether the configured NTLM servers are to be used for failover or load balancing.
ContentEngine(config)# ntlm server scheme ?
  fail-over      Fail-over between hosts
  load-balanced  Round-robin load balancing between hosts
By default, the configured servers are used for failover. In the following example, this default is changed, and the Content Engine is configured to use the configured servers for load balancing:
ContentEngine(config)# ntlm server scheme load-balanced
When load balancing is enabled, only the first request is sent to the first configured server, after which round-robin is used among the remaining configured servers. (In contrast, when failover is enabled, the Content Engine all the requests to the first configured server.)

Step 6 (Optional). Use the ntlm server ad-group-search mem-cache global configuration command to configure the LDAP cache on the Content Engine that is running the ACNS 5.4.1 software and later releases.

By default, the LDAP cache is enabled on the Content Engine, the cache size is set to 128 KB, and the maximum time to live (max-ttl) is set to 480 minutes. The Content Engine uses its LDAP cache to store the results of a nested group search.

In the following example, the maximum size of the LDAP cache is set to 140 KB:
ContentEngine(config)# ntlm server ad-group-search mem-cache size 140
Warning: This config destroys and recreates the memcache with new size
For more information, see the "Configuring the LDAP Cache on Standalone Content Engines" section.

Step 7 Enable NTLM authentication on the Content Engine.
ContentEngine(config)# ntlm server enable 
Step 8 View the NTLM configuration on the Content Engine.
ContentEngine# show ntlm
Check the command output to verify that the displayed NTLM configuration reflects the configuration that you just specified (for example, the specified NTLM servers are listed, and load balancing is specified). For an example of the show ntlm EXEC command output, see the "Displaying the Current NTLM Configuration for Standalone Content Engines" section.
Configuring a List of Allowed Domains List NTLM HTTP Request Authentication

In the ACNS 5.1.x software, you were required to specify the name of the Windows NT domain that the end user was to be authenticated against. This was referred to as the default NTLM domain name. For example, the following command specified that the user needed to be authenticated against the domain named "cisco.com" in order to be authenticated.
ContentEngine(config)# ntlm server domain-name cisco.com
In the ACNS 5.2.1 software and later releases, you are not required to specify a name for the default domain. If the client does not supply a domain name in the request authentication credential and there is no default domain configured on the Content Engine (that is, the ntlm server domain global configuration command was not used), then an authentication error message is returned to the client. A predetermined error page that contains text indicating the reason for the error is sent to the client.

In the ACNS 5.2.1 software and later releases, you can specify a list of domains that are allowed to perform NTLM HTTP request authentication with the Content Engine. This capability allows you to limit the domains that can perform NTLM HTTP request authentication with the Content Engine, which provides additional security. This feature is called the allowed domain feature. If this feature is enabled on the Content Engine and the supplied domain credential does not match any the of domains in the allowed domain list, then HTTP request authentication fails and the client is sent an error message.

To support the allowed domain feature, the following Content Engine CLI commands were added in the ACNS 5.2 software release:

•ntlm allow-domain enable—Enables the allowed domain list feature on the Content Engine. By default, the allow domain feature is disabled.

•no ntlm allow-domain enable—Disables the allowed domain list feature on the Content Engine.

•ntlm allow-domain domain domain-name—Define the names of the domains that are allowed to perform NTLM HTTP request authentication with the Content Engine. A domain list can contain up to 32 domain names.

If the allowed domain list feature is enabled, then this feature works as follows:

•If the client's domain credential matches any domain in the configured domain list, the Content Engine performs NTLM HTTP request authentication for this content request. A case-insensitive comparison is used to check whether the specified domain is listed in the allowed domain list.

•If the client's domain credential does not match any domain in the configured domain list or there are no domains configured on the allowed domain list, the Content Engine denies this content request and sends the client a 407 or 401 authentication error message. The 407 or 401 authentication message has a specific predetermined error page that contains text indicating the reason for the error.

Configuring the Authentication Method Control for NTLM HTTP Request Authentication

By default, the Content Engine (the HTTP proxy server) always sends a basic authentication response header along with an NTLM authentication header to the client browser. This default behavior enables the client to be authenticated with the Content Engine even if the client browser does not support the NTLM protocol, as is the case with the Netscape browser. (Internet Explorer supports the NTLM protocol.)

Because basic authentication transmits user credential information in clear text format, it is less secure than NTLM authentication. Consequently, for security purposes you may want to configure the Content Engine to not send a basic authentication response header along with an NTLM authentication header.

In the ACNS 5.2.1 software and later releases, you can configure the authentication method control for NTLM HTTP request authentication. The authentication method control feature allows you to enable or disable the Content Engine from sending a basic authentication response header along with an NTLM authentication header. To support this feature, the following Content Engine CLI commands were added in the ACNS 5.2.1 software release:

•ntlm basic-auth enable—Configures the Content Engine to send a basic authentication response header along with an NTLM authentication header to the client browser.

•no ntlm basic-auth enable—Configures the Content Engine to not send the basic authentication response header along with an NTLM authentication header, or to not honor it in a request.

If you do not want the client browser to be able to use the basic authentication method between the client and the Content Engine for NTLM HTTP request authentication because it is a less secure method than NTLM, then disable the NTLM basic authentication feature on a standalone Content Engine.

To disable the NTLM basic authentication feature on a standalone Content Engine, enter the no ntlm basic-auth enable global configuration command.

If the Content Engine is configured to not send the basic authentication header to the client and the client does not support NTLM authentication (for example, Netscape browsers only support basic authentication), then the client cannot continue with this HTTP request. The client browser behavior is browser-dependent; for example, some browsers may retry the request over a certain period of time.

Displaying the Current NTLM Configuration for Standalone Content Engines

To display information about each NTLM server and each Global Catalog server that the Content Engine is configured to use, enter the show ntlm EXEC command.

To display NTLM statistics such as the number of requests that were authenticated or denied, and a breakdown of statistics for each configured NTLM server and Global Catalog server, use the show statistics ntlm EXEC command.

Configuring Group-Based Authorization for HTTP Requests

For HTTP requests, the ACNS 5.x software supports group-based access lists for LDAP and NTLM users. In ACNS software releases prior to 5.1, group name-based access control lists were supported but not static groups. This group name-based access lists feature is called group-based authorization. By default, the access lists feature is disabled on a Content Engine. Group information will be checked and applied only if the access lists feature is enabled on the Content Engine.

Note In the ACNS 5.2.1 software release, group-based rules were also added and can be used for group-based authorization. For more information about groupname-based rules, see Chapter 13, "Configuring the Rules Template on Standalone Content Engines."

In Windows NT and Windows 2000 domains, administrators can use the Windows group feature to create groups in order to organize security principles, including user and other resources. An Active Directory (AD) database is a user database of a Windows 2000 server. This database can be queried for authentication purposes when LDAP or NTLM is used.

Configuring Group-Based Access Lists on Standalone Content Engines

To configure a standalone Content Engine to use access lists for group-based authorization, follow these steps:

Step 1 Permit or deny a group from accessing the Internet using a standalone Content Engine by using the access-lists 300 global configuration command.

The following example shows how to use access lists to permit access to groups within the base string named cisco based on organizational units such as Marketing or Engineering using the access-lists 300 permit groupname global configuration command. Group access is allowed for any user in the Marketing and Engineering groups. A user who does not belong to any of these groups is denied access with the access-lists 300 deny groupname any global configuration command.
ContentEngine(config)# access-lists 300 permit groupname Marketing
ContentEngine(config)# access-lists 300 permit groupname Engineering
ContentEngine(config)# access-lists 300 deny groupname any
For Windows-based user groups, you must append the domain name in front of the group name in the form domain\group:

•For Windows NT-based user groups, use the domain NetBIOS name.

•For Windows 2000-based user groups, use the domain DNS name.
Note From the Content Engine GUI, choose System > Access Lists, and use the displayed Access Lists window to define the entries for the access list. For more information about how to use the Access Lists window, click the HELP button in the window.
Step 2 Enable the group name-based access list feature on the Content Engine.
ContentEngine(config)# access-lists enable
Note From the Content Engine GUI, choose System > Access Lists, and click the Enable access lists On radio button.
Example of Configuring LDAP Group Authorization with Group-Based Access Lists

In ACNS releases prior to 5.1, group name-based access lists were supported but not static groups. To ensure interoperability of the Content Engine group authentication support with the Microsoft Active Directory database, the ACNS 5.1 software and later releases support LDAP group-based authorization for static groups.

In this scenario, group access to the Internet is allowed to the following users:

•Any user who belongs to the Marketing organizational unit of the company named cisco.

•Any user who belongs to the organizational unit named Engineering except for those users who belong to the group named Hardware Engineers. Members of the nested group named Hardware Engineers will be denied access because they belong to a group that has been explicitly denied access.

Note This scenario assumes the LDAP directory has the structure depicted in Figure 10-3.

This scenario assumes that the LDAP administrator has defined the group named Engineering as the parent of the Hardware Engineers and Software Developers groups in the LDAP directory, as follows:
dn: cn=Engineering,dc=cisco,dc=com
cn: Engineering
objectclass: groupOfNames
member: cn:Hardware Engineers,dc=cisco,dc=com
member: cn:Software Developers,dc=cisco,dc=com
dn: cd=Hardware Engineers,dc=cisco,dc=com
cn: Hardware Engineers
object: groupOfNames
member: cn=Jay Doe,ou=Engineering,dc=cisco,dc=com
member: cn=Don Smith,ou=Engineering,dc=cisco,dc=com
dn: cn=Software Developers,cd=cisco,cd=com
cn: Software Developers
objectclass: groupOfNames
member: cn=John Gold,ou=Engineering,dc=cisco,dc=com
member: cn=John Smith,ou=Engineering,dc=cisco,dc=com
To configure a standalone Content Engine for LDAP group-based authorization, follow these steps:

Step 1 Enable access to the LDAP server. Enter a hostname or an IP address for the LDAP server.

In the following example, the IP address of the LDAP server is used.
ContentEngine(config)# ldap server host 10.1.1.1
Step 2 Specify the base distinguished name (dn) as the starting point for the directory search. In this example, the strings cisco and com are used for the directory search.
ContentEngine(config)# ldap server base "dc=cisco,dc=com"
Step 3 Enable LDAP authentication on this Content Engine.
ContentEngine(config)# ldap server enable
Step 4 Define which groups are granted or denied access to content that is served by this Content Engine by using the access-lists 300 groupname global configuration command.

In the following example, group access is granted to any user who is not a member of the nested static group named Hardware Engineering:
ContentEngine(config)# access-lists 300 deny groupname Hardware Engineering
ContentEngine(config)# access-lists 300 permit groupname any
Step 5 Enable group name-based access lists on the Content Engine.
ContentEngine(config)# access-lists enable
Example of Configuring NTLM Group Authorization with Group-Based Access Lists

The following example shows how to use the Content Engine CLI to configure NTLM group authorization with group-based access lists, In this example, NTLM group access is granted to the Engineering and Marketing groups in the company named cisco.

To configure a standalone NTLM group authorization with access lists on a standalone Content Engine, follow these steps:

Step 1 Enable access to the NTLM server. Enter either a hostname or an IP address of the NTLM server by using the ntlm server host global configuration command.

Note In the ACNS 5.2.1 software and later releases, you can configure up to eight NTLM servers for HTTP request authentication.

In the following example, three NTLM servers are configured:
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
The order of server configuration determines the order of load balancing or failover. If failover is enabled, the Content Engine sends all of its requests to the first configured server (Server 1, which has in IP address of 172.16.101.0). In contrast, if load balancing is enabled, only the first request is sent to Server 1, after which round-robin is used (for example, the second request is sent to Server 2 [the server with the IP address 172.16.10.12], and the third request is sent to Server 3 [the server with IP address 172.16.10.14]).

Step 2 Configure the Content Engine to use the list of configured NTLM servers for load balancing. The default scheme is failover.
ContentEngine(config)# ntlm server scheme load-balanced
Step 3 (Optional) Specify a default domain.
ContentEngine(config)# ntlm server domain cisco.com
In the ACNS 5.1.x software, you were required to specify a default domain. In the ACNS 5.2.1 software and later releases, you are not required to specify a default domain. If the client does not supply a domain name in the request authentication credential and there is no default domain configured on the Content Engine (the ntlm server domain global configuration command was not used), then an authentication error message is returned to the client. A predetermined error page that contains text indicating the reason for the error is sent to the client.

In the ACNS 5.2.1 software and later releases, you can also specify a list of domains that are allowed to perform NTLM HTTP request authentication with the Content Engine. For more information, see the "Configuring a List of Allowed Domains List NTLM HTTP Request Authentication" section.

Step 4 Enable NTLM authentication on this Content Engine.
ContentEngine(config)# ntlm server enable
Step 5 Permit access for groups within the base string cisco, based on organizational units such as Marketing and Engineering, using the access-lists 300 permit groupname global configuration command.

In the following example, group access is granted to any user in the Marketing and Engineering groups. A user who does not belong to either of these groups is denied access with the access-lists 300 deny groupname any global configuration command:
ContentEngine(config)# access-lists 300 permit groupname MY_DOMAIN\Marketing
ContentEngine(config)# access-lists 300 permit groupname MY_DOMAIN\Engineering
ContentEngine(config)# access-lists 300 deny groupname any
Step 6 Enable group name-based access lists on this Content Engine.
ContentEngine(config)# access-lists enable
Configuring Content Engines for Active Directory Group Searches

In the ACNS software releases prior to 5.1, the Content Engine only supported local groups within a global group for NTLM group-based authorization. To ensure interoperability of the Content Engine NTLM group authentication support with the Microsoft Active Directory database, the ACNS 5.1 software and later releases support static groups.

The ACNS 5.1 software and later releases can retrieve nested group names using an LDAP recursive search and apply all the group-based 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.

Note There are three kinds of groups in an Active Directory: universal, global, and domain local.

To perform a recursive query, an enumeration user's credentials must be provided to query the primary domain controller for a complete list of group names. An enumeration user is an account defined on the Content Engine to allow the Content Engine to perform a search on an Active Directory server. This enumeration user needs to have read privileges throughout the whole directory.

In the ACNS 5.1.x software, group name-based access lists were the only feature that would trigger an Active Directory group search. In the ACNS 5.2.1 software and later releases, the following additional features can trigger an Active Directory group search for HTTP requests:

•If group-based rules are configured in the Rules Template (see Chapter 13, "Configuring the Rules Template on Standalone Content Engines")

•If ICAP is configured to append the authenticated-group header (see Chapter 12, "Configuring ICAP on Standalone Content Engines")

•If the SmartFilter product is enabled on the Content Engine (see the "Configuring URL Filtering with SmartFilter Software" section on page 11-39)

In the ACNS 5.1.x software, you explicitly designated a primary and a secondary Global Catalog server for Active Directory group searches. When the primary Global Catalog server was not reachable, the Content Engine attempted to contact the secondary Global Catalog server.

In the ACNS 5.1.x software, you explicitly designated a primary and secondary server for an Active Directory group search and to obtain group information. You used the ntlm server ad-group-search ldap-search-server host global configuration command with the primary and secondary keywords to explicitly designate a primary and a secondary server, as shown here:
ContentEngine(config)# ntlm server host 172.16.10.10 primary
ContentEngine(config)# ntlm server host 172.16.10.12 secondary
However, in the case of Active Directory, because the domain controller supports both NTLM and LDAP, it is not necessary to configure the primary and secondary server for an Active Directory group search. In the ACNS 5.1.x software, the following two Content Engine CLI commands performed the same task (that is, they were configuring the same Active Directory domain controller):

ntlm server host

ntlm server ad-group-search ldap-search-server host

Consequently, the ntlm server ad-group-search ldap-search-server host global configuration command was removed in the ACNS 5.2.1 software release. Backward compatibility is supported. Configurations performed with the ACNS 5.1.x software that have this removed Content Engine CLI command are silently accepted but ignored in the back end.

In the ACNS 5.2.1 software and later releases, the Active Directory domain controllers (hosts) that are configured using the ntlm server host global configuration command are used for both authentication and authorization if the Active Directory nested group search feature is enabled.

In the ACNS 5.2.1 software and later releases, you can configure up to eight Global Catalog servers for Active Directory searches. (In the ACNS 5.2.1 software release, the ntlm server ad-group-search gc-server host primary option and the ntlm server ad-group-search gc-server host secondary options were removed.) The order of server configuration determines the order of load balancing or failover. If failover is enabled, then the Content Engine sends all of its Active Directory search requests to the first configured Global Catalog server (Server 1). In contrast, if load balancing is enabled, only the first request is sent to Server 1, after which round-robin is used (for example, the second request is sent to Server 2, and the third request is sent to Server 3).

To configure the settings for the Global Catalog servers that you want the Content Engine to use for Active Directory group searches, use the ntlm server ad-group-search gc-server global configuration command. For example, to specify the IP address or hostname of the Global Catalog server that the Content Engine is to use for Active Directory group searches, use the ntlm server ad-group-search gc-server host host-IP-address or hostname command.

To specify the host domain name (for example, "abc1.local") for the configured Global Catalog server, Use the ntlm server ad-group-search gc-server host domain domain-name global configuration command. In the following example, the Content Engine is configured to use the Global Catalog server that has the host domain name of abc1.local.
ContentEngine(config)# ntlm server ad-group-search gc-server host 10.77.157.213 domain 
abc1.local
In the ACNS 5.2.1 software and later releases, you can use the ldap-search-port option of the ntlm server ad-group-search global configuration command to specify the LDAP port for group information retrieval. The default is port 389. This option configures the LDAP search server port for all of the configured Active Directory domain controllers.
Note The ldap-search-port option replaces the ACNS 5.1.x software ldap-search-server port option.

In the ACNS 5.2.1 software and later releases, you can use the scheme option of the ntlm server ad-group-search gc-server global configuration command to specify whether the configured Global Catalog servers are to be used for load balancing or failover.
ContentEngine(config)# ntlm server ad-group-search gc-server ?
  host    Specify global catalog server address
  port    Specify global catalog server port, default 3268
  scheme  Scheme to use for the host list
In the ACNS 5.2.1 software and later releases, the NTLM load balancing feature is supported, which makes cross-domain authorization a more common deployment scenario. In the ACNS 5.3.1 software and later releases, support for the LDAP referral feature is available.

Support of LDAP referral enables the ACNS software to retrieve authorization information for a user who does not belong to the same domain as the configured Active Directory domain controller, but does belong to a trusted domain. When the Active Directory domain controller receives an LDAP query for a user who is not in its own domain, but is in a trusted domain, it will send back an LDAP referral URL to the Content Engine. If the LDAP referral feature is enabled on a Content Engine, the Content Engine will retrieve the information about the referred server in the referral URL, and contact the server to request the user's authorization information.

Support for the LDAP referral feature provides the following capabilities:

•Support of Active Directory trusted domain user authorization

•Support of LDAP referral for NTLM nested group searches

•The ability to configure the LDAP nesting referral level

•The ability to configure Active Directory domain controllers from multiple domains for NTLM load balancing purposes

Note The ability to configure Active Directory domain controllers from multiple domains requires that the multiple domains are in a trusted relationship. Authentication and authorization will not be performed correctly if the multiple domain controllers from different nontrusted domains are configured.

In the ACNS 5.3.1 software and later releases, you can configure the LDAP referral feature through the ntlm server ad-group-search ldap-referral global configuration command:
ContentEngine(config)# ntlm server ad-group-search ldap-referral ?
  enable  Enable ldap referral. (Default is Disabled)
  limit   Maximum depth of nested referral to follow
By default, the LDAP referral feature is disabled on the Content Engine. To enable this feature, enter the ntlm server ad-group-search ldap-referral enable global configuration command. After enabling the LDAP referral feature on the Content Engine, you can disable it at a later time by entering the no ntlm server ad-group-search ldap-referral enable command.

To specify the referral limit for NTLM nested group searches, use the ldap-referral limit option of the ntlm server ad-group-search ldap-referral command. By default, five nested referrals are allowed for an NTLM nested group search. Valid values are from 1 to 10.

Even though the results of a first-level search can contain the desired results (the results that the Content Engine is searching for), Active Directory servers tend to return multiple nested referral URLs, which causes additional, unnecessary round trips to the Active Directory server. Consequently, you can reduce the referral limit to a smaller number if you are sure that the first few level search responses will contain the desired search result because of your directory structure.

For example, if the search result is contained in the first-level search response, you can configure the referral limit to 1 for performance purposes. By setting the referral limit to 1, the Content Engine will only follow one referral URL to contact the correct domain controller (Domain Controller A), and will not follow the additional, unnecessary referral URLs that are generated from Domain Controller A along with the search result.

The following example shows how to specify that 1 instead of 5 nested referrals are allowed for NTLM nested group searches:
ContentEngine(config)# ntlm server ad-group-search ldap-referral limit 1
In the ACNS 5.4.1 software release, support for caching the results of a nested group search locally in the LDAP cache on the Content Engine was added. To support this new feature, the mem-cache option was added to the ntlm server ad-group-search global configuration command:

ContentEngine(config)# ntlm server ad-group-search mem-cache ?

enable Enable ldap in-memory cache. (Default is Enabled)

max-ttl Maximum amount of time from creation an entry is valid in the ldap

in-memory cache

size Maximum size of ldap in-memory cache to allocate in KBytes.

Note By default, the LDAP memory cache is enabled on the Content Engine, the cache size is set to 128 KB, and the maximum time to live (TTL) is set to 480 minutes.

To display the currently configured NTLM parameters on the Content Engine, enter the show ntlm EXEC command. The command output includes such information as whether the LDAP referral feature is enabled (for example, the command output shows "AD LDAP referral chasing: Enabled"), as well as the current referral limit (for example, the command output shows "AD LDAP referral chasing limit: 8"). In the ACNS 5.4.1 software and later releases, the command output also includes configuration information about the local LDAP cache on the Content Engine (for example, if the LDAP cache is enabled as well as the maximum cache size and maximum time for an object to be stored in the cache [the maximum time to live [max-ttl] value).

Examples of Configuring Content Engines to Support Active Directory Group Searches and LDAP Caching

The following example shows how to use the ntlm server ad-group-search global configuration command to configure the Content Engine to support Active Directory group searches. In this example, the Content Engine is configured to use the Global Catalog server that has the IP address 10.77.157.213 for the Active Directory group search. The host domain name for this Global Catalog server is abc1.local. Load balancing is specified as the scheme (the default scheme is failover). Port 111 is specified as the LDAP port for group information retrieval.

By default, the NTLM LDAP memory cache feature is enabled on the Content Engine. Use the ntlm server ad-group-search mem-cache max-ttl global configuration command to change the maximum time for an object to live in the LDAP cache to 400 minutes (the default is 480 minutes). Next, use the ntlm server ad-group-search mem-cache size global configuration command to change the maximum size of the LDAP cache to 140 KB (the default is 128 KB) on the Content Engine.

After you have configured the Active Directory group search parameters and the LDAP cache, you must enter the ntlm server ad-group-search enable global configuration command to enable the Active Directory group search feature on the Content Engine:
ContentEngine(config)# ntlm server ad-group-search enum-user username administrator
ContentEngine(config)# ntlm server ad-group-search enum-user password ***
ContentEngine(config)# ntlm server ad-group-search enum-user domain abc1.local
ContentEngine(config)# ntlm server ad-group-search gc-server host 10.77.157.213 domain 
abc1.local
ContentEngine(config)# ntlm server ad-group-search gc-server host 10.77.157.214 domain 
abc1.local
ContentEngine(config)# ntlm server ad-group-search gc-server scheme load-balanced
ContentEngine(config)# ntlm server ad-group-search ldap-search-port 111
ContentEngine(config)# ntlm server ad-group-search mem-cache max-ttl 400
Warning: This config destroys and recreates the memcache with new ttl
ContentEngine(config)# ntlm server ad-group-search mem-cache size 140
Warning: This config destroys and recreates the memcache with new size
ContentEngine(config)# ntlm server ad-group-search mem-cache enable
ContentEngine(config)# ntlm server ad-group-search enable
ContentEngine(config)# ntlm server ad-group-search ldap-referral limit 1
When you enable Active Directory search groups, the access list must be configured with the correct domain name. The group name should look like this:

DNS domain name\group name

The following example uses access lists to enable Active Directory search groups:
ContentEngine(config)# access-lists 300 permit groupname mydomain.local\univ11_sec
ContentEngine(config)# access-lists 300 deny groupname any
ContentEngine(config)# access-lists enable 
The LDAP queries are sent to the same Active Directory server that is assigned to perform authentication unless the LDAP query fails. If the LDAP query fails, the authorization request fails over to the next configured server. If the NTLM service or the LDAP service on the Active Directory server is not accessible, the Content Engine considers the Active Directory server nonfunctional.

Disabling Group Name-Based Access Lists

You can disable the group name-based access list feature on a Content Engine without losing any of the configured access lists, as follows:

•From the Content Engine GUI, choose System > Access Lists. Click the Enable access lists Off radio button in the Access Lists window, and then click Update.

•From the Content Engine CLI, use the no access-lists global configuration command.

Configuring the LDAP Acceptable Use Policy Feature

The ACNS 5.1.1 software and later releases support the LDAP acceptable use policy feature. When a user opens a browser session, the Content Engine queries a specific LDAP attribute to determine whether the user has viewed and accepted the acceptable use policy (AUP). If a user has not accepted this policy, then the Content Engine redirects the user to an internal web page with the AUP, which the user must read and accept before being allowed to browse content through the Content Engine. Once the user accepts the policy, the Content Engine sets an LDAP attribute that allows the user full access to browse through the proxy server (the Content Engine).

This LDAP attribute is configurable and is an integer stored in the user's database that represents the version of the policy that the user has accepted. This value is compared against the current version set in the Content Engine. If these values are equal, the user is given access to browse; otherwise, the user is redirected to the configured URL that sends the user to the internal web page that allows the user to read and accept the AUP.

To enable the AUP, enter the ldap server policy-redirect enable global configuration command. To specify the URL to which the user is redirected to view and accept the policy, use the ldap server policy-redirect redirect-url url global configuration command. To define the LDAP attribute that is to be queried for the version that the user has accepted, use the ldap server policy-redirect attribute attribute command.

To configure the AUP on a standalone Content Engine, follow these steps:

Step 1 Enable the AUP on the Content Engine.
ContentEngine(config)# ldap server policy-redirect enable
Step 2 Specify the URL that the user is redirected to in order to view and accept the policy.
ContentEngine(config)# ldap server policy-redirect redirect-url url
Step 3 Specify the LDAP attribute that the Content Engine should query to determine the version of the AUP that the user has accepted.
ContentEngine(config)# ldap server policy-redirect attribute aup-attribute
Step 4 Specify the current version of the AUP on the Content Engine. This value is a global value that is used for all users to view so that they can determine whether they have accepted this version of the AUP.
ContentEngine(config)# ldap server policy-redirect value latest-policy-version
Configuring the LDAP Password Expiration Feature

The LDAP password feature allows you to configure the Content Engine to redirect users to a web page, which will prompt them for a username and password. To configure the LDAP authorization password expiration feature, use the ldap server password-expiry global configuration command.

Configuring Request Authentication for Nontransparent FTP Native Requests

In the ACNS 5.4.1 software release, proxy authentication (that is, request authentication at the Content Engine), was added for nontransparent FTP native requests. With request authentication and authorization, the Content Engine is verifying the end user (for example, FTP clients such as a Reflection X client, WS-FTP clients, and UNIX or DOS command line FTP programs) that sent the request to the Content Engine. In contrast, end-to-end authentication and caching of authenticated objects deals with authentication for a particular object, and it is the origin server and not the Content Engine that verifies the end user.

In the ACNS 5.4.1 software release, the authentication option was added to the ftp-native proxy configuration command to support proxy authentication for nontransparent FTP native requests:
ContentEngine(config)# ftp-native proxy ?
  active-mode     Configuration of active mode for native ftp proxy
  authentication  Configuration for proxy authentication of proxy-mode requests
  incoming        Configuration for incoming proxy-mode requests
ContentEngine(config)# ftp-native proxy authentication ?
  enable  If an authentication service is configured then use it for
          authenticating proxy-mode ftp-native requests.
By default, the ftp-native proxy authentication feature is disabled. You can enable the ftp-native proxy authentication feature, as follows:
ContentEngine(config)# ftp-native proxy authentication enable
Note Because the FTP protocol is inherently insecure, the authentication credentials can be sniffed off the network, which expose user credentials that otherwise would have been provided over a secure channel (for example, in the case of HTTP).

In the ACNS 5.4.1 software release, proxy authentication (that is, request authentication at the Content Engine) was added for nontransparent FTP native requests. With request authentication and authorization, the Content Engine is verifying the end user (for example, FTP clients such as a Reflection X client, WS-FTP clients, and UNIX or DOS command line FTP programs) that sent the request to the Content Engine. In contrast, end-to-end authentication and caching of authenticated objects deals with authentication for a particular object, and it is the origin server and not the Content Engine that verifies the end user.

In the ACNS 5.4.1 software release, the authentication option was added to the ftp-native proxy configuration command to support proxy authentication for nontransparent FTP native requests:
ContentEngine(config)# ftp-native proxy ?
  active-mode     Configuration of active mode for native ftp proxy
  authentication  Configuration for proxy authentication of proxy-mode requests
  incoming        Configuration for incoming proxy-mode requests
ContentEngine(config)# ftp-native proxy authentication ?
  enable  If an authentication service is configured then use it for
          authenticating proxy-mode ftp-native requests.
By default, the ftp-native proxy authentication feature is disabled. You can enable the ftp-native proxy authentication feature, as follows:
ContentEngine(config)# ftp-native proxy authentication enable
Note Because the FTP protocol is inherently insecure, the authentication credentials can be sniffed off the network, which expose user credentials that otherwise would have been provided over a secure channel (for example, in the case of HTTP).

Nontransparent proxy mode with proxy-authentication support requires that the FTP client provide the FTP proxy (that is, the Content Engine that is acting as the FTP proxy for the FTP client) the proxy username, (optionally) the proxy password, and the hostname of the origin FTP server.

When FTP clients and proxies are configured for nontransparent proxying with proxy authentication, the FTP client (TCP) connects to the FTP proxy (that is, the Content Engine) and issues FTP commands to authenticate with the proxy using one of the following methods:

•FTP Proxy Authentication Method # 1

The client uses the FTP USER command to specify the server username and the hostname of the origin FTP server:
USER proxy-username
PASS proxy-password
USER server-username@server-hostname.company.com
PASS server-password
•FTP Proxy Authentication Method # 2:

The client uses the FTP SITE command to specify the hostname of the origin FTP server:
USER proxy-username
PASS proxy-password
SITE server-hostname.company.com
USER server-username
PASS server-password
The following is an example of an FTP client session when TACACS+ proxy authentication is enabled on the Content Engine. In this example, the FTP client uses the FTP proxy authentication method # 2 (for example, the FTP client enters the FTP SITE command to specify the hostname of the origin FTP server):
shell# ftp -d 2.9.192.11 8021 
Connected to 2.9.192.11
220 Welcome to FTP-proxy.  Login to the proxy using username and password.
Name (2.9.192.11:tuser): tuser
---> USER tuser
331 Password required for tuser.
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> site host.abccorp.com
---> SITE host.abccorp.com
220 via2.abccorp.com FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready.
ftp> user anonymous
---> USER anonymous
331 Guest login ok, send your complete e-mail address as password.
Password: 
---> PASS XXXX
230 Guest login ok, access restrictions apply.
ftp> quit
If the proxy authentication succeeds for a particular client, the username that is provided by that client during the FTP proxy authentication process is logged in the transaction log if one of the following transaction logging formats have been configured on the Content Engine:

•Extended-squid logging

•Custom logging

Note For the Custom transaction logging format, you must include the %u format-specifier when you configure the transaction-logs format custom command.

If the proxy authentication fails for an FTP client, the authentication failures are logged in the system log. Content Engine administrators can check the system log to monitor such authentication failures. For more information about enabling and configuring transaction logging on a standalone Content Engine, see the "Enabling Transaction Logging" section on page 21-33.

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

•By default, the ftp-native proxy authentication feature is disabled on the Content Engine. Because the FTP protocol is inherently insecure, the authentication credentials can be sniffed off the network, which expose user credentials that otherwise would have been provided over a secure channel (for example, in the case of HTTP). In the ACNS 5.4.1 software and later releases, you can enable the ftp-native proxy authentication feature, as follows:
ContentEngine(config)# ftp-native proxy authentication enable
•If you enter the ftp-native proxy authentication enable command and you have not already configured an authentication service (that is, RADIUS, TACACS+, NTLM, or LDAP) on the Content Engine, a warning message will be 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 FTP native requests, ACNS supports TACACS+, RADIUS, NTLM, and LDAP as an authentication service. Whether or not the FTP client, who has sent the FTP native request, is queried for proxy authentication by the Content Engine is based on whether one of the supported authentication services (RADIUS, TACACS+, NTLM, or LDAP) is enabled on the Content Engine that receives the incoming FTP native request.

In the ACNS 5.4.1 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 FTP native requests). However, the following restrictions apply to FTP native caching support:

–No support for FTP request proxy rules

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

For more information about configuring an authentication service to control request authentication on a standalone Content Engine, see the following sections:

–Configuring the RADIUS Authentication Service

–Configuring the TACACS+ Authentication Service

–Configuring the LDAP Authentication Service

–Configuring the NTLM Authentication Service

•In ACNS 5.4.1 software and later releases, you can use IP ACLs to control access to the native FTP proxy service that is running on the Content Engine. For more information, see the "About IP ACL Support for FTP Native Requests" section on page 7-42.

•In the ACNS 5.4.1 software and later releases, you can use the ftp-native custom-message global configuration command to configure customized response messages, which the Content Engine sends to an FTP client in response to an incoming proxy mode connection:
ContentEngine# ftp-native custom-message ?
  download  Download the custom message file specified by the URL to the CE
  reset     Revert to default message and delete the local file on the CE
  upload    Upload the custom message file to the specified host, directory and
            filename using the FTP protocol
You can use the ftp-native custom-message EXEC command to create, upload, and download files that contain the following custom messages:

–A custom welcome message for welcoming proxy mode connections from FTP clients

–A custom error message when an FTP client is denied access based on an IP ACL that has been configured on the Content Engine for incoming FTP native requests.

For more information about this topic, see the "Creating Custom Messages for FTP Proxy Responses for FTP Native Requests" section on page 5-19.