-
Cisco ACNS Software Caching and Streaming Configuration Guide, Release 5.1
-
Index
-
Title Page
-
Preface
-
Chapter 1: Introduction
-
Chapter 2: Understanding the Basics
-
Chapter 3: Content Engine Configuration Overview
-
Chapter 4: Transparent Caching
-
Chapter 5: Proxy-Style Caching
-
Chapter 6: Reverse Proxy Caching
-
Chapter 7: Configuring Login Authentication and Authorization
-
Chapter 8: Configuring Content Authentication and Authorization
-
Chapter 9: Configuring a Primary Proxy Server
-
Chapter 10: Configuring Caching Protocols
-
Chapter 11: Configuring Content Service Protocols
-
Chapter 12: Configuring Streaming Media Services
-
Chapter 13: Configuring URL Filtering
-
Chapter 14: Configuring the Rules Template
-
Chapter 15: Creating and Managing IP Access Control Lists
-
Chapter 16: Configuring TCP Stack Parameters
-
Chapter 17: Monitoring and Troubleshooting
-
Appendix A: Content Engine GUI Menu Options
-
Appendix B: Web Cache Communication Protocol Version 1
-
Appendix C: Web Cache Communication Protocol Version 2
-
Table Of Contents
Configuring Content Authentication and Authorization
Understanding Content Authentication and Authorization
Understanding HTTP Request Authentication
Understanding Proxy Server Mode HTTP Request Authentication
Understanding Transparent Mode HTTP Request Authentication
Configuring HTTP Request Authentication
Configuring the Authentication Cache Size
Configuring Authentication Cache Size Using the Content Engine GUI
Configuring Authentication Cache Size Using CLI Commands
Configuring RADIUS Authentication for HTTP Requests
Enabling RADIUS Authentication of HTTP Requests Using the Content Engine GUI
Configuring RADIUS Authentication of HTTP Requests Using CLI Commands
Configuring TACACS+ Authentication of HTTP Requests
Configuring LDAP Authentication of HTTP Requests
Default Settings for LDAP Authentication of HTTP Requests
Understanding the Structure of the LDAP Database
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 LDAP Authentication of HTTP Requests Using the Content Engine GUI
Configuring LDAP Authentication of HTTP Requests Using CLI Commands
Configuring NTLM Authentication for HTTP Requests
Configuring Group-Based Authorization
Configuring the LDAP Acceptable Use Policy Feature
Configuring the LDAP Password Expiration Feature
About Group Name-Based Access Lists
Configuring Group-Based Authorization Using the Content Engine GUI
Configuring Group-Based Authorization Using CLI Commands
LDAP Group-Based Authorization
Configuring LDAP Group Authorization with Access Lists
NTLM Group-Based Authorization
Active Directory Group Searches
Configuring NTLM Group Authorization with Access Lists
Configuring End-to-End Authentication
Basic End-to-End Authentication
NTLM End-to-End Authentication
Example of End-to-End NTLM Authentication
Configuring Content Authentication and Authorization
This chapter describes how to configure content authentication and authorization for a locally deployed Content Engine. This chapter contains the following sections:
•
Understanding Content Authentication and Authorization
•
•
•
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.1.
Understanding Content Authentication and Authorization
As organizations extend the use of web applications and Internet access to their employees, they are confronted with the following challenges:
•
•
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 locally deployed Content Engine, the Content Engine checks a remote database (for example, a RADIUS, TACACS+, or LDAP database) for user password authentication to determine if the user should be granted or denied access to the requested content.
For more granular control, organizations can use group-based authorization (for NTLM and LDAP users) in addition to HTTP authentication. If the Content Engine is configured for group-based authorization, then the Content Engine checks its access control lists (ACLs) to determine if the group that the user belongs to should be granted or denied access to the requested content. Figure 8-1 shows how HTTP request authentication and group-based authorization can be used as mechanisms to control access to content.
Figure 8-1 HTTP Request Authentication and Group-Based Authorization
Note
Content authentication and authorization can be implemented through various protocols, as summarized in Table 8-1.
Note
Understanding HTTP Request Authentication
ACNS 5.x software supports TACACS+, Microsoft NT LAN Manager (NTLM), Lightweight Directory Access Protocol (LDAP), and RADIUS server for HTTP request authentication. In the case of NTLM, HTTP request authentication authenticates a user's domain, username, and password with a preconfigured primary domain controller (PDC) before allowing requests from the user to be served by the Content Engine.
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.
•
•
If you are using HTTP request authentication in transparent mode, we recommend that the AuthTimeout interval configured with the http authentication cache timeout command be short. IP addresses can be reallocated, or different users can access the Internet through an already authenticated device (PC, workstation, and the like). Shorter AuthTimeout values help reduce the possibility that individuals can gain access using previously authenticated devices. When the Content Engine operates in proxy mode, it can authenticate the end user with the user ID and password.
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
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 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
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 from a client, or (2) the Content Engine receives a transparent (WCCP-style) request from a client and the Content Engine http authentication header command option is set to 407 (Proxy Authorization Required) because there is an upstream proxy.
1.
2.
3.
4.
5.
6.
7.
8.
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 command to configure the append x-forwarded-for header on the Content Engine named CE1 so that Content Engine named CE2 will be able to see the client's IP address instead of just the IP address of CE1.
Note
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 command parameter is set to 401 (Unauthorized) because there is no upstream proxy.
1.
2.
3.
4.
5.
6.
7.
8.
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 locally deployed Content Engine:
•
•
•
•
Note
Usage Guidelines
When configuring HTTP request authentication on a locally deployed Content Engine, note the following guidelines:
•
•
•
•
Note
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.
•
ContentEngine(config)#tacacs key "tackey"The TACACS+ server uses this common client key to encrypt or decrypt. The TACACS+ authentication server does not require the TACACS+ client to be registered.
•
•
–
–
–
–
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.
•
–
–
•
In this example, the host for the LDAP server daemon is configured:
ContentEngine(config)# ldap server host www.someDomain.com port 390In this example, the host for the RADIUS authentication server is configured:
ContentEngine(config)# radius-server 172.16.90.121In this example, the length of time that entries are valid in the authentication cache is set:
ContentEngine(config)# http authentication cache timeout 1000The following example specifies that the Content Engine should use the header 407 when asking the end user for authentication credentials (user ID and password).
ContentEngine(config)# http authentication header 407ContentEngine(config)# ldap server host www.someDomain.com port 390
Note
For information on the various types of HTTP request authentication methods supported by a locally deployed Content Engine, see the following sections:
•
•
•
•
Configuring the Authentication Cache Size
If the authentication cache is not large enough to accommodate all authenticated users at the same time, the Content Engine purges older entries that have not yet timed out. The Content Engine has a timeout value range from 1 to 1440 minutes (24 hours). Its default timeout value is 480 minutes.
The default time interval between the user's last Internet access and the removal of that user's entry from the authorization cache is 480 minutes. The minimum time interval is 1 minute, and the maximum is 1440 minutes (24 hours). The Content Engine forces reauthentication with the access control server once this time interval expires.
When LDAP, RADIUS, and TACACS+ are used in proxy redirection mode, the authentication record kept in the authentication cache is indexed by the username and the password entered. When LDAP, RADIUS, or TACACS+ is used in WCCP-enabled router redirection mode, the authentication record indexed is the IP address of the Content Engine that is sending the request in transparent mode.
When an NTLM server is used in either proxy redirection mode or WCCP-enabled router redirection mode, all authentication records are indexed by using the IP address of the requesting Content Engine.
The http authentication command has a header option that can be set to display a message to the client when authorization has failed. You can choose http authentication header 401 (Unauthorized) or http authentication header 407 (Proxy Authorization Required). By default, the Content Engine authenticates cache loads based on the URL syntax of the incoming request.
You can configure the size of the authentication cache on a locally deployed Content Engine using the Content Engine GUI or CLI.
Configuring Authentication Cache Size Using the Content Engine GUI
To configure the size of the Content Engine authentication cache, follow these steps:
Step 1
Figure 8-2 Authenticated Cache Window
Step 2
Step 3
Step 4
•
•
•
Step 5
Configuring Authentication Cache Size Using CLI Commands
Use the http authentication cache command to configure the authentication cache size parameters if necessary. The maximum number of entries that is maintained in the authentication cache is 32,000. The minimum number is 500. The default value is 16,000. Use the http authentication max-entries command to configure this parameter if necessary.
Use the show http authentication command in EXEC mode to display the authentication cache parameters.
Configuring RADIUS Authentication for 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, which contains user authentication and network service access information.
To configure RADIUS authentication for HTTP requests on a locally deployed Content Engine, follow these steps:
1.
2.
–
–
Enabling RADIUS Authentication of HTTP Requests Using the Content Engine GUI
To enable RADIUS authentication of HTTP requests on a locally deployed Content Engine, follow these steps:
Step 1
Step 2
Note
Step 3
Configuring RADIUS Authentication of HTTP Requests Using CLI Commands
To use the CLI to configure RADIUS for HTTP request authentication on a locally deployed Content Engine, use the radius-server command in global configuration mode. To disable RADIUS authentication settings, use the no form of this command. For more information on the radius-server command, refer to the Cisco ACNS Software Command Reference, Release 5.1.
Note
RADIUS Authentication Redirection
The redirect option of the radius-server command redirects an authentication response to a different authentication server if an authentication request using the RADIUS server fails.
The following example enables the RADIUS client, specifies a RADIUS server, specifies the RADIUS key, accepts retransmit defaults, and excludes the domain name mydomain.net from RADIUS authentication. The configuration is displayed and verified with the show radius-server and show rule all commands.
Note
ContentEngine(config)# radius-server enableContentEngine(config)# radius-server host 172.16.90.121ContentEngine(config)# radius-server key myradiuskeyContentEngine(config)# rule enableContentEngine(config)# rule no-auth domain mydomain.netContentEngine# show radius-serverRadius Configuration:---------------------Radius Authentication is onTimeout = 5Retransmit = 3Key = ****Servers-------IP 172.16.90.121 Port = 1645 State: ENABLEDContentEngine# show rule allRules Template Configuration----------------------------Rule Processing Enabledrule no-auth domain mydomain.netThe following example disables RADIUS authentication on the Content Engine.
ContentEngine(config)# no radius-server enableConfiguring TACACS+ Authentication of HTTP Requests
The TACACS+ database validates users before they gain access to a Content Engine. TACACS+ is derived from the United States Department of Defense (RFC 1492) and is used by Cisco Systems as an additional control of nonprivileged and privileged mode access. ACNS 4.1 or later software supports TACACS+ only and not TACACS or Extended TACACS.
To enable TACACS+ for HTTP request authentication, use the tacacs enable global configuration configuration command.
Note
The User page of the Content Engine GUI (from the Content Engine GUI, choose System > Users) or the user global configuration commands provide a way to add, delete, or modify usernames, passwords, and access privileges in the local database. The TACACS+ remote database can also be used to maintain login and configuration privileges for administrative users. The tacacs global configuration command or the TACACS+ GUI page allows you to configure the network parameters required to access the remote database.
For more information about specifying the TACACS+ authentication settings on a locally deployed Content Engine, see the "Understanding TACACS+ Authentication and Authorization" section.
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 locally deployed 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
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 5.1 software, 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 8-3 shows how the Content Engine (an LDAP client) works with any of the following types of servers to perform LDAP authentication of HTTP requests:
•
•
•
Note
Figure 8-3 LDAP Authentication of HTTP Requests in Proxy Mode
Note
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 8-2 lists the features that are supported on the different types of LDAP servers (shown in Figure 8-3). An "x" indicates support of a particular feature.
To configure LDAP authentication of HTTP requests, you must configure the following settings for the LDAP client on the Content Engine:
1.
ContentEngine(config)# ldap server host 10.1.1.12.
Figure 8-3 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 33.
ContentEngine(config)# ldap server enable4.
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 the authenticated users. For more information on group-based authorization, see the "Configuring Group-Based Authorization" 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
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 enableThe 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 ldapLDAP Configuration:-------------------LDAP Authentication is enabledAllow mode: disabledBase DN: "DC=cisco,DC=com"Filter: <none>Retransmits: 2Timeout: 5 secondsUID Attribute: uidGroup Attribute:organizationUnit: disabled (ou)Custom Attribute: disabledActive Directory: enabled (memberOf)
Note
For more information about the default configuration settings for LDAP authentication of HTTP requests, see the "Default Settings for LDAP Authentication of HTTP Requests" 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 8-1).
In order for LDAP group-based authorization to occur, you must have completed the following prerequisite tasks on the Content Engine:
•
•
Default Settings for LDAP Authentication of HTTP Requests
Table 8-3 lists the Content Engine's default configuration for LDAP authentication of HTTP requests.
You can change these defaults on a locally deployed Content Engine, as described in the "Configuring LDAP Authentication of HTTP Requests" section.
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 8-4.).
•
•
•
•
Figure 8-4 LDAP Database Structure
Note
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.
•
•
•
The following example shows the complete database entry for Jane Smith in an OpenLDAP or third-party LDAP server database.
# Jane Smith, cisco, comdn: cn=Jane Smith,dc=cisco,dc=comtelephoneNumber: (408) 123-9100mail: jsmith50@cisco.comuid: jsmith50givenName: Janesn: Smithcn: Jane SmithThe following example shows the complete entry for Jane Smith in a Microsoft Active Directory server database.
# Jane Smith, cisco, comdn: CN=Jane Smith,DC=cisco,DC=commemberOf: CN=Users,DC=cisco,DC=comtelephoneNumber: (408) 123-9100mail: jsmith50@cisco.comuid: jsmith50givenName: Janesn: Smithcn: Jane SmithAn 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:
•
•
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
There are multiple ways to support LDAP grouping in a user database:
•
•
•
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 either static, dynamic, or organizationUnit (organizational units). The groups can be nested. ACNS 5.1 software 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=comcn: Marketingobjectclass: groupOfNamesIn 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, comdn: cn=Penny Gold,ou=Marketing,dc=cisco,dc=comtelephoneNumber: (408) 123-4444mail: pgold@cisco.comuid: pgoldgivenName: Pennysn: Goldcn: Penny GoldBecause 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), then the Content Engine authenticates 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 OpenLDAP server or the third-party LDAP server (server with an IP address of 172.16.1.1) 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.1ContentEngine(config)# ldap server userid-attribute uidContentEngine(config)# ldap server organizationUnit enableContentEngine(config)# ldap server base "dc=cisco,dc=com"ContentEngine(config)# ldap server enableBecause 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.
•
ContentEngine(config)# ldap server group static member-attribute memberContentEngine(config)# ldap server group static enable•
ContentEngine(config)# ldap server group static member-attribute uniquememberContentEngine(config)# ldap server group static enable
Note
The following example describes how an LDAP server administrator can configure static groups in an LDAP database.
1.
–
–
–
–
–
–
–
The following example shows how the LDAP server administrator defines a node for the user "Jay Doe."
# Jay Doe, Engineers, cisco, comdn: cn=Jay Doe,ou=Engineering,dc=cisco,dc=comtelephoneNumber: (408) 123-8910mail: jdoe8@cisco.comuid: jdoe8givenName: Jaysn: Doecn: Jay DoeThe following example shows how the LDAP server administrator defines a node for the user "Don Smith."
# Don Smith, Engineers, cisco, comdn: cn=Don Smith,ou=Engineering,dc=cisco,dc=comtelephoneNumber: (408) 123-4567mail: dsmith7@cisco.comuid: dsmith7givenName: Donsn: Smithcn: Don Smith2.
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=comcn: Engineeringobjectclass: groupOfNamesmember: cn:Hardware Engineers,dc=cisco,dc=commember: cn:Software Developers,dc=cisco,dc=comThe 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. When nodes are connected with a two-way link, it reduces the number of TCP requests that are required to search through the database for user membership information.
dn: cn=Engineers,dc=cisco,dc=comcn: Hardware Engineersobject: groupOfNamesmember: cn:Jay Doe,ou=Engineering,dc=cisco,dc=commember: cn:Don Smith,ou=Engineering,dc=cisco,dc=comBy default, static group queries and nested group queries are disabled on the Content Engine (as shown in the following excerpt of a sample output of a show ldap EXEC command).
ContentEngine# show ldapLDAP Configuration:-------------------Static Groups: disabledGroup Attribute:Group Member:Nested Groups: disabledNested Level: 1However, you can use the CLI to enable and configure such queries on a locally deployed Content Engine, as described in these sections:
•
•
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 5.1 software, the LDAP client on a Content Engine now 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 3To request that the LDAP server query the Active Directory group membership, enter this command:
Content Engine(config)# ldap server group active-directory enable
Note
The following is an entry sample from a user account in an Active Directory database.
dn: CN=Penny Gold,CN=Users,DC=cisco,DC=localmemberOf: CN=Marketing,DC=cisco,DC=localThe 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 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 uidContentEngine(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.
a.
–
–
b.
–
–
Note
c.
–
–
d.
–
–
3.
–
–
Note
You use the ldap server global configuration command to configure the Content Engine to perform an LDAP database search.
Querying LDAP Servers for User Membership Information
This section provides some examples of how to configure the Content Engine to perform LDAP directory queries.
•
•
•
Note
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.
ContentEngine(config)# ldap server 172.16.1.1By 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.
ContentEngine(config)# ldap server base "dc=cisco,dc=com"3.
ContentEngine(config)# ldap server enable4.
a.
ContentEngine(config)# ldap server userid-attribute uidb.
ContentEngine(config)# ldap server organizationUnit enableSearching 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 (non-nested) 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.
ContentEngine(config)# ldap server 172.16.1.12.
ContentEngine(config)# ldap server group static group-attribute cn3.
ContentEngine(config)# ldap server group static member-attribute member4.
ContentEngine(config)# ldap server base "dc=cisco,dc=com"5.
ContentEngine(config)# ldap server enable6.
ContentEngine(config)# ldap server group static enableSearching 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.
ContentEngine(config)# ldap server 172.16.1.12.
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 23.
ContentEngine(config)# ldap server group static group-attribute cn4.
ContentEngine(config)# ldap server group static member-attribute member5.
ContentEngine(config)# ldap server base "dc=cisco,dc=com"6.
ContentEngine(config)# ldap server enable7.
ContentEngine(config)# ldap server group static nested enableConfiguring LDAP Authentication of HTTP Requests Using the Content Engine GUI
To configure LDAP authentication of HTTP requests on a locally deployed Content Engine, follow these steps:
Step 1
Figure 8-5 LDAP Window
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
a.
b.
c.
Note
Step 12
Table 8-4 describes the parameters in the LDAP window and the corresponding CLI command.
For more information about using the CLI to configure LDAP authentication of HTTP requests on a locally deployed Content Engine, see the next section, "Configuring LDAP Authentication of HTTP Requests Using CLI Commands." To retrieve group names from the LDAP database for group-based authorization (as shown in Figure 8-1), you must use the CLI (the ldap server group option).
Configuring LDAP Authentication of HTTP Requests Using CLI Commands
Use the ldap server global configuration command to configure LDAP authentication of HTTP requests on a locally deployed Content Engine.
Use the ldap server group option to instruct the LDAP server, which is performing the database query, to retrieve the names of the groups that the authenticated user belongs to (for example, "Marketing" or "Engineering"). The Content Engine uses these retrieved group names to perform LDAP group-based authorization by checking its access lists to determine whether the groups should be granted or denied access to the requested content.
Note
The syntax of the ldap command is as follows:
ldap server {administrative-dn name | administrative-passwd passwd | allow-mode | base baseword | enable | filter filterword | group {active-directory enable | custom uid enable | organizationUnit enable | static {enable | group-attribute gid | member-attribute {custom-member memid | member | uniquemember} | nested {enable | level 1-100}}} | host {hostname | hostipaddress} [primary | secondary] | password-expiry {enable | redirect-url url} | policy-redirect {attribute name | enable | redirect-url url | version-number num} | port port-num | retransmit retries | timeout seconds | userid-attribute useridword | version ver_num}
Table 8-5 describes the parameters of the ldap server global configuration command for LDAP HTTP request authentication and group-based authorization.
Configuration Examples of LDAP Authentication of HTTP Requests
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 primaryContentEngine(configure)# ldap server 172.16.1.2 secondaryThis example shows how to specify the LDAP timeout interval:
ContentEngine(config)# ldap server timeout 10This example shows how to specify the LDAP retransmit count:
ContentEngine(config)# ldap server retransmit 3This 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=comThis example shows how to enable LDAP authentication on the Content Engine, as follows:
ContentEngine(config)# ldap server enableConfiguring NTLM Authentication for HTTP Requests
The NTLM protocol can be used to authenticate and block user access to the Internet. When a user logs in to a Windows NT or a Windows 2000 domain and starts a browser, the authentication information is stored by the browser and later used as NTLM credentials to access the Internet. The browser sends the NTLM credentials with the domain name to the Content Engine, which in turns sends a request to the Windows NT domain controller to check the validity of the user in the domain. If the user is not a valid user in the domain, then the request to access the Internet is denied. If authentication succeeds, the source IP address is entered in the Content Engine authentication cache. Future requests from this IP address are not challenged until the authentication cache entry expires or is cleared.
You can use the Content Engine GUI or CLI to configure a locally deployed Content Engine to use an NTLM server for HTTP request authentication.
•
The following is an example of how to use the CLI to configure a locally deployed Content Engine for NTLM authentication of HTTP requests.
ContentEngine(config)# ntlm server domain cisco_abcContentEngine(config)# ntlm server host 172.16.10.10 primaryContentEngine(config)# ntlm server host 172.16.10.12 secondaryContentEngine(config)# ntlm server enableContentEngine# show ntlmNTLM parameters:Primary: 172.16.10.10Secondary: 172.16.10.12State: EnabledDomain name: cisco_abc•
Figure 8-6 NTLM Authentication Window
Before invoking an NTLM authentication request, make sure that the following conditions exist.
•
•
•
In the following example, server1 must be in the cisco.com domain and must have an entry in DNS that matches its NetBIOS-named computer account.
ip domain-name cisco.comntlm server host server1For 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 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 lease expires.
Configuring Group-Based Authorization
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 the LDAP Acceptable Use Policy Feature
In ACNS 5.1 software, an LDAP acceptable use policy feature has been implemented. 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 will redirect 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 (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 use 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 command to enable the AUP. Use the ldap server policy-redirect redirect-url url 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 locally deployed Content Engine, follow these steps:
Step 1
ContentEngine(config)# ldap server policy-redirect enableStep 2
ContentEngine(config)# ldap server policy-redirect redirect-url urlStep 3
ContentEngine(config)# ldap server policy-redirect attribute aup-attributeStep 4
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. For more information about the ldap server command, see Table 8-4.
About Group Name-Based Access Lists
In ACNS 5.x software, you can use group-based access lists to control whether members of a particular group should be denied or granted access to the content that is served by the Content Engine. Figure 8-7 shows an example of an access list that will grant any user access to the requested content other than those users who belong to the group named "Marketing." The members of the Marketing group are denied access because the access list explicitly denies access to this particular group.
Figure 8-7 Group Name-Based Access Lists
Note
When working with group name-based access lists, note the following guidelines:
•
–
–
•
–
–
•
•
•
–
–
•
–
–
Configuring Group-Based Authorization Using the Content Engine GUI
To configure a locally deployed Content Engine to support group-based authorization for LDAP and NLTM users, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
For example, to deny access to any user who does not belong to the Engineering group, click the Any check box, and then click the Group permission deny radio button.
Note
Step 8
Configuring Group-Based Authorization Using CLI Commands
When using the CLI to configure group-based authorization for LDAP and NTLM users on a locally deployed Content Engine, note the following guidelines:
•
•
To use the CLI to configure group name-based access lists on a locally deployed Content Engine, follow these steps:
Step 1
For example, 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 command.
In this example, 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 command.
ContentEngine(config)# access-lists 300 permit groupname MarketingContentEngine(config)# access-lists 300 permit groupname EngineeringContentEngine(config)# access-lists 300 deny groupname anyStep 2
ContentEngine(config)# access-lists enable
LDAP Group-Based Authorization
In ACNS releases prior to 5.1, group name-based access lists were supported but did not support static groups. To ensure interoperability of the Content Engine group authentication support with the Microsoft Active Directory database, the ACNS 5.1 software now supports LDAP group-based authorization for static groups.
Configuring LDAP Group Authorization with Access Lists
In this scenario, group access to the Internet is allowed to the following users:
•
•
Note
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=comcn: Engineeringobjectclass: groupOfNamesmember: cn:Hardware Engineers,dc=cisco,dc=commember: cn:Software Developers,dc=cisco,dc=comdn: cd=Hardware Engineers,dc=cisco,dc=comcn: Hardware Engineersobject: groupOfNamesmember: cn=Jay Doe,ou=Engineering,dc=cisco,dc=commember: cn=Don Smith,ou=Engineering,dc=cisco,dc=comdn: cn=Software Developers,cd=cisco,cd=comcn: Software Developersobjectclass: groupOfNamesmember: cn=John Gold,ou=Engineering,dc=cisco,dc=commember: cn=John Smith,ou=Engineering,dc=cisco,dc=comTo configure a locally deployed Content Engine for LDAP group-based authorization, follow these steps:
Step 1
In the following example, the IP address of the LDAP server is used.
ContentEngine(config)# ldap server host 10.1.1.1Step 2
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
ContentEngine(config)# ldap server enableStep 4
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 EngineeringContentEngine(config)# access-lists 300 permit groupname anyStep 5
ContentEngine(config)# access-lists enable
NTLM Group-Based Authorization
In ACNS software releases prior to 5.1, the Content Engine only supported local groups with a global group for NTLM group-based authorization. To ensure interoperability of the Content Engine NTLM group authentication support with the Microsoft Active Directory database, the ACNS 5.1 software now supports static groups.
Active Directory Group Searches
ACNS 5.1 software can retrieve nested group names using an LDAP recursive search and apply all the access control lists (ACLs) 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
The following are the different operations that occur during an Active Directory group search:
1.
2.
3.
A global catalog server is a server that stores a partial copy of all the objects in the entire Active Directory.
4.
Direct groups are those groups to which a user directly belongs.
5.
6.
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.
You can configure a primary and a secondary global catalog server. When the primary global catalog server is not reachable, the Content Engine will try to contact the secondary global catalog server.
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 is an example of the access list that must be configured to enable Active Directory search groups:
ContentEngine(config)# access-lists 300 permit groupname mydomain.local\univ11_secContentEngine(config)# access-lists 300 deny groupname anyContentEngine(config)# access-lists enableTo configure the Active Directory groups searches on a Content Engine, use the ntlm server ad-group-search global configuration command.
ntlm server ad-group-search {enable | enum-user {domain domain-name | password pass | username user-name} | gc-server {host {host-name | ip-address} domain domain-name {primary | secondary}} | port port-num} | groupname-attribute group-name| ldap-search-server {host {host-name | ip-address} {primary | secondary} | port port-num} | membership-attribute member | user-objectclass object | username-attribute user}
The following example shows how to enable and implement Active Directory search groups on a locally deployed Content Engine:
ContentEngine(config)# ntlm server host 10.77.157.163 primaryContentEngine(config)# ntlm server domain cacheContentEngine(config)# ntlm server enableContentEngine(config)# ntlm server domain cacheContentEngine ntlm server ad-group-search enum-user username administratorContentEngine(config)# ntlm server domain cacheContentEngine ntlm server ad-group-search enum-user password ***ContentEngine(config)# ntlm server ad-group-search enum-user domain cache.acnsContentEngine(config)# ntlm server ad-group-search gc-server host 10.77.157.213 domain acns primaryContentEngine(config)# ntlm server ad-group-search ldap-search-server host 10.77.157.163 primaryContentEngine(config)# ntlm server ad-group-search enableThe following example shows the output of the show ntlm command when the Active Directory search groups option has been enabled:
ContentEngine# show ntlmNTLM parameters:Primary : 10.77.157.163Secondary : <none>State: EnabledDefault domain: cacheConnection Timeout: 5Connection Retries: 2Configuring NTLM Group Authorization with Access Lists
To configure NTLM-based group authorization on a Content Engine, follow these steps. In this scenario, NTLM group access is allowed to the Engineering and Marketing groups in the company named "cisco."
Step 1
In the following example, the IP address of the NTLM server is used.
ContentEngine(config)# ntlm server host 10.1.1.1 primaryStep 2
ContentEngine(config)# ntlm server domain domainStep 3
ContentEngine(config)# ntlm server enableStep 4
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 command.
ContentEngine(config)# access-lists 300 permit groupname MarketingContentEngine(config)# access-lists 300 permit groupname EngineeringContentEngine(config)# access-lists 300 deny groupname anyStep 5
ContentEngine(config)# access-lists enable
Configuring End-to-End Authentication
The ACNS 5.x software supports both basic and NTLM end-to-end authentication. End-to-end NTLM authentication includes pass-through servicing and the caching of web objects that require NTLM authentication.
HTTP request authentication authenticates a user's domain, username, and password with a preconfigured NTLM domain controller before allowing requests from the user to be served by the Content Engine. NTLM authentication works only in a Microsoft environment (for instance, Microsoft Internet Explorer clients accessing Microsoft Internet Information Services [IIS] servers).
Note
For HTTP request authentication, if NTLM authentication is used but the browser does not support NTLM authentication, the username and password information is passed to the Content Engine in clear text with a basic authentication header. The Content Engine then uses this information to authenticate the user against the preconfigured Windows NT domain controller.
Basic End-to-End Authentication
The ACNS software can strip NTLM authentication headers to allow fallback to a basic-style authentication challenge against 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 on the basic authentication method. If IIS is configured to still accept basic authentication, IIS authentication credentials can proceed through a Content Engine, but with reduced security.
Use the http authenticate-strip-ntlm global configuration command to enable stripping of NTLM headers.
NTLM End-to-End Authentication
The two levels of NTLM end-to-end support can be summarized as follows:
•
If NTLM pass-through service is set on the server, the Content Engine sets up a secure persistent connection between the client and the server through the Content Engine. NTLM authentication messages pass through this virtual persistent connection. The Content Engine does not cache any object transferred on the virtual connection. All the client requests are served by the origin server.
•
The ACNS 5.x software can be configured to cache objects that require NTLM authentication. The server puts a "no-store" flag on a reply object to prevent the reply from being cached. If no such flag is present, the object is cacheable. When the Content Engine receives a request from a client already connected with the intended NTLM server, the Content Engine searches the cache.
–
–
Example of End-to-End NTLM Authentication
This example configures a Content Engine for end-to-end NTLM authentication. By default, basic and NTLM authenticated objects are not cached.
ContentEngine(config)# no http authenticate-strip-ntlmContentEngine(config)# http cache-authenticated ntlmContentEngine# show http cache-authenticated ntlmBasic authenticated objects are not cached.NTLM authenticated objects are cached.
