Cisco ACNS Software Configuration Guide for Locally Managed Deployments, Release 5.2 - Chapter 9: 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

Supported Content Authentication and Authorization Methods

Authenticating Web Clients Through Pass-Through Authentication

Authenticating Web Clients Through HTTP Request Authentication

Understanding Proxy Server Mode HTTP Request Authentication

Understanding Transparent Mode HTTP Request Authentication

Configuring HTTP Request Authentication

Usage Guidelines

Configuring RADIUS Authentication of HTTP Requests

Configuring TACACS+ Authentication of HTTP Requests

Configuring LDAP Authentication of HTTP Requests

Example of Configuring LDAP Authentication of HTTP Requests

Understanding the Structure of the LDAP Database

About LDAP Directory Searches

Querying LDAP Servers for User Membership Information

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

Configuring NTLM Authentication of HTTP Requests

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

Displaying the NTLM Statistics for Standalone Content Engines

Configuring Group-Based Authorization for Standalone Content Engines

Configuring Access Lists on Standalone Content Engines

Example of Configuring LDAP Group Authorization with Access Lists

Example of Configuring NTLM Group Authorization with Access Lists

Configuring Content Engines for Active Directory Group Searches

Examples of Configuring Content Engines to Support Active Directory Group Searches

Disabling Group Name-Based Access Lists

Configuring the LDAP Acceptable Use Policy Feature

Configuring the LDAP Password Expiration Feature

Configuring End-to-End Authentication for HTTP Requests

Basic End-to-End Authentication

NTLM End-to-End Authentication

Configuring Pass-Through Authentication for WMT 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 ACNS software, Release 5.2 or later. Content authentication and authorization controls whether an end user (a client browser) can access the requested content that is served through the Content Engine.

Another type of authentication and authorization mechanism, 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 "Configuring Administrative Login Authentication and Authorization on Standalone Content Engines."

Note 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.

This chapter contains the following sections:

•About Authentication and Authorization of Content Requests

•Configuring HTTP Request Authentication

•Configuring Group-Based Authorization for Standalone Content Engines

•Configuring the LDAP Acceptable Use Policy Feature

•Configuring End-to-End Authentication for HTTP Requests

•Configuring Pass-Through Authentication for WMT Requests

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

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. For example, organizations can use HTTP request authentication (content authentication) as a mechanism 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 9-1.

Figure 9-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 deal with any end user request that is 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.

For request authentication, ACNS supports LDAP, NTLM, TACACS+, and RADIUS. For request authorization, ACNS 5.x supports group-based access control lists (ACLs). In ACNS 5.2 software, 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 ACLs 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, MMS, 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 ACNS 5.2 software, 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 mechanisms 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 Note that authorization through rules based on group names or usernames occurs only after HTTP request authentication and group-based ACL authorization have occurred. If the configuration in the Rules Template and the ACL match, the ACL takes precedence. For more information about configuring the Rules Template for standalone Content Engines, see "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."

Supported Content Authentication and Authorization Methods

Content authentication and authorization can be implemented through various protocols, as summarized in Table 9-1.

Table 9-1 Content Authentication and Authorization Methods Supported by ACNS Software, Release 5.2 or Later)

Method

More Information

HTTP request authentication

Configuring HTTP Request Authentication

RADIUS

Configuring RADIUS Authentication of HTTP Requests

TACACS+

Configuring TACACS+ Authentication of HTTP Requests

LDAP

Configuring LDAP Authentication of HTTP Requests

NTLM

Configuring NTLM Authentication of HTTP Requests

Group-based authorization

Configuring Group-Based Authorization for Standalone Content Engines

End-to-end authentication

Configuring End-to-End Authentication for HTTP Requests

Basic

Basic End-to-End Authentication

Microsoft NTLM

NTLM End-to-End Authentication

Pass-through authentication
for WMT requests

Configuring Pass-Through Authentication for WMT Requests

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.

The following two types of content access controls are supported by standalone Content Engines:

•Authenticating Web Clients Through Pass-Through Authentication

•Authenticating Web Clients Through HTTP Request Authentication

Note Other ways to restrict end users' access to online content include defining URL filters (for example, through local filters or through an external Websense server) or using a combination of password access and URL filters. The Content Engine can be configured as a proxy caching engine that will store and serve authorized and filtered content to authorized users only.

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 Similarly, the WMT MMS protocol also supports basic mode and NTLM mode for client authentication. 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), ought not to 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.

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 at all. For example, BigCorp 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 BigCorp 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.

Note that in 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. ACNS 5.x software supports the LDAP, NTLM, RADIUS, and TACACS+ protocols, which are used by common AAA servers. (See Table 9-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 ACNS 5.2 software, 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 (PC, workstation, and the like). Shorter AuthTimeout values help reduce the possibility that individuals can gain access using previously authenticated devices. In ACNS 5.2 software, 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.

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 wish 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 scenarios 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. Consequently, use the http append x-forwarded-for-header global configuration command to configure the append x-forwarded-for header on the Content Engine named CE1 so that the Content Engine named CE2 will be able to see the client's IP address instead of just the IP address of CE1.

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.

Configuring HTTP Request Authentication

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

•Configuring RADIUS Authentication of HTTP Requests

•Configuring TACACS+ Authentication of HTTP Requests

•Configuring LDAP Authentication of HTTP Requests

•Configuring NTLM Authentication of HTTP Requests

Note NTLM support on the Content Engine includes the following three 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. For HTTP request authentication, the ACNS 5.x software supports NTLM Version 1. For end-to-end NTLM authentication, both NTLM Version 1 and Version 2 are supported.

Usage Guidelines

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

•Only one HTTP request authentication scheme can be enabled on the Content Engine at a time. For information about configuring HTTP request authentication on a Content Engine, see the "Configuring HTTP Request Authentication" section.

•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.

•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 ACNS 5.2 software. For more information, see the "Specifying a Reauthentication Interval" section.

•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 "Monitoring and Troubleshooting."

•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
Note For more information about configuring HTTP request authentication on a standalone Content Engine, see the "Configuring HTTP Request Authentication" section.

For information on the various types of HTTP request authentication methods supported by a standalone Content Engine, see the following sections:

•Configuring RADIUS Authentication of HTTP Requests

•Configuring TACACS+ Authentication of HTTP Requests

•Configuring LDAP Authentication of HTTP Requests

•Configuring NTLM Authentication of HTTP Requests

Configuring RADIUS Authentication of HTTP Requests

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.

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.

To configure RADIUS authentication for HTTP requests on a standalone Content Engine, follow these steps:

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

Step 2 Enable RADIUS authentication for HTTP requests on the Content Engine, using the Content Engine GUI or CLI:

•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 TACACS+ Authentication of HTTP Requests

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

To configure TACACS+ authentication for HTTP requests on a standalone Content Engine, follow these steps:

Step 1 Use the tacacs server global configuration command to 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 Use the tacacs key global configuration command to specify the TACACS+ key.

ContentEngine(config)# tacacs key key

Step 3 Use the tacacs timeout global configuration command to 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 Use the tacacs retransmit global configuration command to 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 Use the tacacs password global configuration command to 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 Use the tacacs enable global configuration command to 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 16-3. For more detailed information about the tacacs server global configuration command, refer to the Cisco ACNS Software Command Reference Guide, Release 5.2 publication.

Configuring LDAP Authentication of HTTP Requests

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 ACNS software, Release 5.1 or later, 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 9-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 9-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 9-2 LDAP Authentication of HTTP Requests in Proxy Mode

Note 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 9-2 lists the features that are supported on the different types of LDAP servers (shown in Figure 9-2). An "x" indicates support of a particular feature.

Table 9-2 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

When you configure LDAP authentication of HTTP requests, keep these important points in mind:

•You can configure LDAP authentication of HTTP 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.

–Use the ldap server enable command to enable LDAP authentication.

–Use the ldap server version ver_num global configuration command to specify the LDAP protocol version to be used. The options are Version 2 or Version 3. The following example show how to specify LDAP Version 3:
ContentEngine(config)# ldap server enableldap server version 3
–Use the ldap server timeout seconds global configuration command 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. The default value is 5 seconds.

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

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

–Use the ldap server base baseword global configuration command to specify the base distinguished name string for the database search. 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
–Use the ldap server administrative-dn name global configuration command to specify the administrative distinguished name for the database search. There is no default value for this field.

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

–Use the ldap server port port-num global configuration command to specify the port number on which the LDAP server is listening. 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.)

Use the ldap server host {hostname | hostipaddress} primary global configuration command to designate an LDAP server as the primary server. Specify the IP address or host name of the primary LDAP server.

Use the ldap server host {hostname | hostipaddress} secondary global configuration command to designate an LDAP server as the secondary server. Specify the IP address or host name 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.

–Use the ldap server group global configuration command to retrieve group names from the LDAP database for group-based authorization. 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 ACNS software, Release 5.1 or later supports LDAP Version 2 and Version 3 and supports all LDAP features except for Secure Authentication and Security Layer (SASL).

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

Table 9-3 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 of HTTP Requests

The following example describes how to use the Content Engine CLI to configure LDAP authentication of HTTP requests on a standalone Content Engine.

Step 1 Specify the IP address or host name of the LDAP authentication server that the Content Engine should use to authenticate HTTP 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 9-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 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 Standalone Content Engines" section.

In order 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:  uid
        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. For more information about the default configuration settings for LDAP authentication of HTTP requests, see the "Understanding the Structure of the LDAP Database" section.

You can also configure the Content Engine to perform group-based authorization 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 9-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 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 9-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 9-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:

•"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, 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, refer to 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. ACNS software, Release 5.1 or later supports static and organizationUnit groups; it does 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 (user name 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 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 ACNS software, Release 5.1 or later, 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, enter this command:
ContentEngine(config)# ldap server group active-directory enable
Note The Active Directory group attribute is an LDAP Version 3 extension, and therefore 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 Access Lists" section.

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 9-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:

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.

2. Specify the base distinguished name that is the starting point for this database search.
ContentEngine(config)# ldap server base "dc=cisco,dc=com"
3. Enable LDAP authentication on the Content Engine.
ContentEngine(config)# ldap server enable
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.
ContentEngine(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 scenario, the LDAP database is queried for user account information for the direct static group named "Engineering."

1. Specify the LDAP server that the Content Engine should use for this database search.
ContentEngine(config)# ldap server 172.16.1.1
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
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
4. Specify the base distinguished name that is the starting point for this database search.
ContentEngine(config)# ldap server base "dc=cisco,dc=com"
5. Enable LDAP authentication on the Content Engine.
ContentEngine(config)# ldap server enable
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."

1. Specify the LDAP server that the Content Engine should use for this database search.
ContentEngine(config)# ldap server 172.16.1.1
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"). Therefore, in this example the LDAP server is instructed to search two levels down.
ContentEngine(config)# ldap server group static nested level 2
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
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
5. Specify the base distinguished name that is the starting point for this database search.
ContentEngine(config)# ldap server base "dc=cisco,dc=com"
6. Enable LDAP authentication on the Content Engine.
ContentEngine(config)# ldap server enable
7. Enable nested static group queries of the LDAP database.
ContentEngine(config)# ldap server group static nested enable
Configuring NTLM Authentication of HTTP Requests

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, which is a challenge-response-based protocol can be used to authenticate and block user access to the Internet. The main advantage of using NTLM for HTTP request authentication is that NTLM sends the password in an encrypted format 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.

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.

In ACNS 5.2 software, the following enhancements for NTLM HTTP request authentication were added:

•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. ACNS software, Release 5.1.x and earlier 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. Use the ntlm server scheme global configuration command to specify the scheme for the NTLM servers for HTTP request authentication. Use the ntlm server ad-group-search gc-server scheme global configuration command to change the scheme for the Global Catalog servers for Active Directory group searches, 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. Note that 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.

You can use the transaction-logs log-window-domain global configuration command to configure the Content Engine to send the username and domain name to the transaction log. 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.

About NTLM Load Balancing for HTTP Request Authentication

In ACNS software, Release 4.x to Release 5.1, 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 ACNS 5.2 software. With ACNS 5.2 software, the ability to configure up to eight servers (domain controllers) for load-balancing and failover purposes was added. 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 ACNS software, Release 5.1.x or earlier, 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 ACNS software, Release 5.2 and later, 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 ACNS 5.2 software, the ntlm server host primary option and the ntlm server host secondary options were removed because up to eight servers are now supported. In ACNS 5.2 software, 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 Use the ntlm server host global configuration command to specify the host name or IP address of each NTLM server that you want the Content Engine to use for HTTP request authentication. This list of configured NTLM servers is referred to as the "host list."

In 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 Use the ntlm server connection-retry global configuration command to specify the maximum number of times that the Content Engine is to attempt to connect to one of the configured NTLM servers.

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. In the following example, this value is set to 3.
ContentEngine(config)# ntlm server connection-retry 3
Step 3 Use the ntlm server connection-timeout global configuration command to specify how long the Content Engine should wait for a response from the NTLM server that it is attempting to connect to.

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.

In the following example, this timeout is set to 10 seconds.
ContentEngine(config)# ntlm server connection-timeout 10
Step 4 Use the ntlm server scheme global configuration command to 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. 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 sends all the requests to the first configured server.)
ContentEngine(config)# ntlm server scheme load-balanced
Step 5 Use the ntml server enable global configuration command to enable NTLM authentication on the Content Engine.
ContentEngine(config)# ntlm server enable 
Step 6 Use the show ntlm EXEC command to display the NTLM configuration on the Content Engine.

Step 7 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 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 ACNS software, Release 5.2 or later, 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 ACNS 5.2 software, 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; thereby providing 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 ACNS 5.2 software:

•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 ACNS 5.2 software, the ability to configure the authentication method control for NTLM HTTP request authentication was added. 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:

•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. See the sample output below.
ContentEngine# show ntlm
NTLM parameters:
        NTLM Hosts:
                172.16.10.10
                172.16.10.12
                172.16.10.14
                172.16.10.16
                172.16.10.18
                172.16.10.20
                172.16.10.22
                172.16.10.24
                scheme:                 Load-balanced
        State:          Enabled
        Basic Auth:     Enabled
        Default domain: cnbu1.local
        Connection Timeout:     10
        Connection Retries:     3	
        Allow Domains:          Disabled
        Allow Domains List:
                None
        AD group search is enabled
        Enumeration User:
                Username:       administrator
                Password:       ****
                Domain:         abc1.local
        LDAP Port:389
        Global Catalog Servers:
                172.16.10.32 , Domain: abc1.local
                172.16.10.38 , Domain: abc2.local
                Scheme:                 Load-balanced
                Port:           3268
        User objectclass:       user
        Username attribute:     sAMAccountName
        Groupname attribute:    cn
        Membership attribute:   memberOf
Displaying the NTLM Statistics for Standalone Content Engines

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 Standalone Content Engines

For request authorization, 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 ACNS 5.2 software, group-based rules were also added and can be used for group-based authorization. For more information about groupname-based rules, see "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 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 Use the access-lists 300 global configuration command to permit or deny a group from accessing the Internet using a standalone Content Engine.

The following example shows how to use access lists to permit access to groups within the base string 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 Use the access-lists enable global configuration command to 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 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 software, Release 5.1 or later supports 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 9-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 In global configuration mode, enter the ldap server host command to enable access to the LDAP server. Enter a host name 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 Use the ldap server base command to 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 Use the ldap server enable global configuration command to enable LDAP authentication on this Content Engine.
ContentEngine(config)# ldap server enable
Step 4 Use the access-lists 300 groupname global configuration command to define which groups are granted or denied access to content that is served by this Content Engine.

In this example, the access-lists 300 permit groupname command is used to grant group access 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 Use the access-lists enable global configuration command to enable group name-based access lists on the Content Engine.
ContentEngine(config)# access-lists enable
Example of Configuring NTLM Group Authorization with Access Lists

The following example shows how to use the Content Engine CLI to configure NTLM group authorization with 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 Use the ntlm server host global configuration command to enable access to the NTLM server. Enter either a host name or an IP address of the NTLM server.

In ACNS software, Release 5.2 or later, 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 Use the ntlm server scheme load-balanced global configuration command to specify 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 Optionally, use the nltm server domain global configuration command to specify a default domain.
ContentEngine(config)# ntlm server domain cisco.com
In ACNS 5.1.x software, you were required to specify a default domain. In ACNS software, Release 5.2 or later), 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 ACNS 5.2 software, 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 with the ntlm server enable global configuration command.
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 this 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 with the access-lists enable global configuration command.
ContentEngine(config)# access-lists enable
Configuring Content Engines for Active Directory Group Searches

In 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 software, Release 5.1 or later supports static groups.

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

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 ACNS 5.1 software, group name-based access lists were the only feature that would trigger an Active Directory group search. In ACNS 5.2 software, the following additional features can trigger an Active Directory group search:

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

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

•If the SmartFilter product is enabled on the Content Engine (see the "URL Filtering with SmartFilter Software" section)

In 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 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.) See below.
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 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 ACNS 5.2 software. Backward compatibility is supported. Configurations performed with ACNS 5.1.x software that have this removed Content Engine CLI command are silently accepted but ignored in the back end.

In ACNS 5.2 software, 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 Active Directory nested group search is enabled.

In ACNS 5.2 software, the ability to configure up to eight Global Catalog servers for Active Directory searches was added. Consequently, 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, use the ntlm server ad-group-search gc-server host host-IP-address or hostname command to specify the IP address or host name 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 domain domain-name global configuration command to specify the host domain name (for example, "abc1.local") for the configured Global Catalog server. 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 ACNS 5.2 software, the ldap-search-port option was added to the ntlm server ad-group-search global configuration command. (See the following example.) Use the ldap-search-port option 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.
ContentEngine(config)# ntlm server ad-group-search ?
  enable                Enable Active Directory group search
  enum-user             Configure enumeration user parameters
  gc-server             Configure global catalog server parameters
  groupname-attribute   groupname attribute in Active Directory, default is cn
  ldap-search-port      Specify LDAP search server port, default 389
  membership-attribute  membership attribute in Active Directory, default is
                        memberOf
  user-objectclass      objectclass for user object, default is user
  username-attribute    username attribute in Active Directory, default is
                        sAMAccountName
Note The ldap-search-port option replaces the ACNS 5.1.x software ldap-search-server port option.

In ACNS 5.2 software, the scheme option was also added to ntlm server ad-group-search gc-server global configuration command to let you 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
Examples of Configuring Content Engines to Support Active Directory Group Searches

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. After you configure the Active Directory group search parameters, you use the ntlm server ad-group-search enable global configuration command to enable the Active Directory group search feature on a standalone 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 enable
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

ACNS software, Release 5.1 and later, supports 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.

Use the ldap server policy-redirect enable global configuration command to enable the AUP. Use the ldap server policy-redirect redirect-url url 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 attribute attribute to define the LDAP attribute that is to be queried for the version that the user has accepted.

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 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 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 The WMT MMS protocol supports basic mode and NTLM mode for client authentication. RTP/RTSP supports basic mode for client authentication.

ACNS software, Release 5.2 or later supports all three modes of client authentication (basic, NTLM, and Active Directory/Kerberos) for pass-through authentication. (See the "Authenticating Web Clients Through Pass-Through Authentication" section.)

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

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, issue 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 issuing 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.

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 Pass-Through Authentication for WMT Requests

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

In ACNS 5.2 software, pass-through authentication support for WMT requests was added. Note that 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 broaddcast 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.

Note Proxy server authentication is supported for HTTP requests. With HTTP requests, the Content Engine acts as a proxy authentication server and authenticates the client itself.

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