|
|
Authentication, also referred to as "login," is the act of verifying usernames and passwords. Authorization refers to the setting of privileges to authenticated users in to a network.
The authentication command configures the authentication and authorization methods that govern login and configuration access to the Content Engine. ACNS 4.1 software supports local database and Terminal Access Controller Access Control System Plus (TACACS+) database authentication and authorization methods.
Login and configuration privileges can be obtained from both the local database or the TACACS+ remote database. If both databases are enabled, then both databases are queried; if the user data cannot be found in the first database queried, then the second database is tried.
The authentication login command specifies the method that determines whether the user has any level of permission to access the Content Engine. The authentication configuration command specifies the method that authorizes the user with privileged access (configuration access) to the Content Engine.
The authentication login local and the authentication configuration local commands use a local database for authentication and authorization.
The authentication login tacacs and authentication configuration tacacs commands use a remote TACACS+ server to determine the level of user access. The Content Engine tacacs global configuration command and a TACACS+ server must be configured to use the TACACS+ authentication and authorization method.
When the primary keyword is entered for TACACS+ login or configuration authentication, the TACACS+ database is queried first, and the local database is queried second. If the TACACS+ database is not designated as primary, and both the local and the TACACS+ database are enabled, the local database is queried first. If both the local and the TACACS+ databases are disabled (no authentication), the Content Engine verifies that both are disabled and if so, sets the Content Engine to the default state.
By default, the local method is enabled and TACACS+ is disabled for both login and configuration. Whenever TACACS+ is disabled, local is automatically enabled. Both TACACS+ and local methods can be enabled at the same time. The primary option specifies the first method to attempt; the secondary option specifies the method to use if the primary method fails. If both methods of an authentication login or authentication configuration command are configured as primary, or both as secondary, local is attempted first, then TACACS+.
The following example enables local and TACACS+ authentication and authorization, setting TACACS+ as the first method used and local as the secondary method to use if TACACS+ fails.
Console(config)# authentication login tacacs enable primary
Console(config)# authentication login local enable secondary
Console(config)# authentication configuration local enable secondary
Console(config)# authentication configuration tacacs enable primary
This is an example of the show authentication user command:
Console# show authentication user
Login Authentication: Console/Telnet Session
----------------------------- -----------------------
local enabled
tacacs enabled (primary)
Configuration Authentication: Console/Telnet Session
----------------------------- -----------------------
local enabled
tacacs enabled
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. This release supports TACACS+ only and not TACACS or Extended TACACS.
TACACS+ provides both authentication and authorization options. Authentication or login is the action of identifying and validating a user. It verifies a username with the password. Authorization or configuration is the action of determining what a user is allowed to do. To configure TACACS+, use the authentication and tacacs commands.
The Users GUI page or the user global configuration commands provide a way to add, delete, or modify usernames, passwords, and access privileges in the local database. The TACACS+ remote database can also be used to maintain login and configuration privileges for administrative users. The tacacs command or the TACACS+ GUI page allows you to configure the network parameters required to access the remote database.
Use the tacacs key command to specify the TACACS+ key, used to encrypt the packets transmitted to the server. This key must be the same as the one specified on the server daemon. The maximum number of characters in the key should not exceed 99 printable ASCII characters (except tabs). An empty key string is the default. All leading spaces are ignored; spaces within and at the end of the key string are not ignored. Double quotes are not required even if there are spaces in the key, unless the quotes themselves are part of the key.
One primary and two backup TACACS+ servers can be configured; authentication is attempted on the primary server first, then on the others in the order in which they were configured. The primary server is the first server configured unless another is explicitly specified as primary with the tacacs server hostname primary command.
The tacacs timeout is the number of seconds the Content Engine waits before declaring a timeout on a request to a particular TACACS+ server. The range is from 1 to 20 seconds with 5 seconds as the default. The number of times the Content Engine repeats a retry-timeout cycle before trying the next TACACS+ server is specified by the tacacs retransmit command. The default is two retry attempts.
Three unsuccessful login attempts are permitted. TACACS+ logins may appear to take more time than local logins depending on the number of TACACS+ servers and the configured timeout and retry values.
This example configures the key used in encrypting packets:
Console(config)# tacacs key human789
This example configures the host named spearhead as the primary TACACS+ server:
Console(config)# tacacs server spearhead primary
This example sets the timeout interval for the TACACS+ server:
Console(config)# tacacs timeout 10
This example sets the number of times authentication requests are retried (retransmitted) after a timeout:
Console(config)# tacacs retransmit 5
The ACNS 4.1 software Cache application supports Microsoft NT LAN Manager (NTLM), Lightweight Directory Access Protocol (LDAP), and RADIUS server HTTP request authentication. 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.
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, the information is stored by the browser and later used as NTLM credentials to access the Internet. The browser sends the NTLM credentials with the domain name to the ACNS cache, which in turns sends a request to the Windows NT domain controller to check the validity of the user in the domain. If the user is not a valid user in the domain, then the request to access the Internet is denied. If authentication succeeds, the source IP address is entered in the authentication cache. Future requests from this IP address are not challenged until the authentication cache entry expires, or is cleared.
Use the ntlm server command to enable NTLM authentication and configure the NTLM server domain name, NT primary domain controller (PDC) name or IP address, and optionally set the host name or address as primary or secondary.
Before invoking an NTLM authentication request, make sure that the following conditions exist.
In the following example, server1 must be in the cisco.com domain and must have an entry in DNS that matches its NetBIOS-named computer account.
ip domain-name cisco.com
ntlm server host server1
For clients within the domain using the Internet Explorer browser in proxy mode, authentication is "popless"; this is, the user is not prompted with a dialog box to enter a username and password. In transparent mode, authentication is transparent only if the Internet options security settings are customized and set to User Authentication > Logon > Automatic logon with current username and password.
This example configures a Content Engine for NTLM request authentication and blocking.
Console(config)# ntlm server enable
Console(config)# ntlm server domain cisco_abc
Console(config)# ntlm server host 172.16.10.10 primary
Console(config)# ntlm server host 172.16.10.12 secondary
Console# show ntlm
Primary: 172.16.10.10
Secondary: 172.16.10.12
State: Enabled
Domain name: cisco_abc
RADIUS authentication clients reside on the Content Engine running ACNS 4.1 software. When enabled, these clients send authentication requests to a central RADIUS server, which contains user authentication and network service access information.
To configure RADIUS parameters, use the radius-server command in global configuration mode. To disable RADIUS authentication parameters, use the no form of this command. For more information on the radius-server command, refer to the Cisco Application and Content Networking Software Command Reference.
The redirect option of the radius-server command redirects an authentication response to a different authentication server if an authentication request using the RADIUS server fails.
 |
Note The rule command is relevant to RADIUS only if redirect has been configured. |
The following example enables the RADIUS client, specifies a RADIUS server, specifies the RADIUS key, accepts retransmit defaults, and excludes the domain name, mydomain.net, from RADIUS authentication. The configuration is verified with the show radius-server and show rule all commands.
Console(config)# radius-server enable
Console(config)# radius-server host 172.16.90.121
Console(config)# radius-server key myradiuskey
Console(config)# rule enable
Console(config)# rule no-auth domain mydomain.net
Console(config)# show radius-server
Radius Configuration:
---------------------
Radius Authentication is on
Timeout = 5
Retransmit = 3
Key = ****
Servers
-------
IP 172.16.90.121 Port = 1645 State: ENABLED
Console# show rule all
Rules Template Configuration
----------------------------
Rule Processing Enabled
rule no-auth domain mydomain.net
The following example disables RADIUS authentication on the Content Engine.
Console(config)# no radius-server enable
System administrators can now use the Content Engine to restrict user Internet access using a Lightweight Directory Access Protocol (LDAP) server for autentication purposes, which provides most of the services of the X.500 protocol with less complexity and overhead.
Use the ldap global configuration command to enable LDAP authentication. Use the no form of the command to disable LDAP functions. An LDAP-enabled Content Engine authenticates users with an LDAP server. With an HTTP query, the Content Engine obtains a set of credentials from the user (user ID and password) and compares them against those in an LDAP server.
ACNS 4.1 software supports LDAP version 2 and version 3 and supports all LDAP features except for Secure Authentication and Security Layer (SASL).
|
Note The HTTP authentication featuring RADIUS and LDAP existed in Cache software 2.x releases and were configured through the radius-server and ldap commands, respectively. For ACNS 4.1 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 options 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. |
When the Content Engine authenticates a user through an NTLM, RADIUS, or LDAP server, a record of that authentication is stored locally in the Content Engine RAM (authentication cache). As long as the authentication entry is kept, subsequent attempts to access restricted Internet content by that user do not require server lookups.
The http authentication cache timeout command specifies how long an inactive entry can remain in the authentication cache before it is purged. Once a record has been purged, any subsequent access attempt to restricted Internet content requires reauthentication.
LDAP authentication can be used with Websense URL filtering, but not with RADIUS authentication. Both LDAP and RADIUS rely on different servers, which may require different user IDs and passwords, making LDAP and RADIUS authentication schemes mutually exclusive. Should both RADIUS and LDAP be configured on the Content Engine at the same time, LDAP authentication is executed, not RADIUS authentication.
To exclude domains from HTTP authentication servers, use the rule no-auth domain command. LDAP, NTLM, or RADIUS authentication takes place only if the site requested does not match the specified pattern.
The events listed below occur when the Content Engine is configured for HTTP request authentication and one of the following two scenarios is true:
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 (Proxy Authorization Required) message to the client.
3. The client resends the request, including the user information.
4. The Content Engine searches its authentication cache (based on user ID and password) to see whether the client has been previously authenticated.
5. If a match is found, the request is serviced normally.
6. If no match is found, the Content Engine sends a request to the authentication server to find an entry for this client.
7. If the server finds a match, the Content Engine allows the request to be serviced normally and stores the client user ID and password in the authentication cache.
8. If no match is found, the Content Engine again returns a 407 (Proxy Authorization Required) message to the client.
The events listed below occur when the Content Engine is configured for authentication and both of the following are true:
1. The Content Engine searches its authentication cache to see whether the user's IP address has been previously authenticated.
2. If a match is found, the Content Engine allows the request to be serviced normally.
3. If no match is found in the first step, the Content Engine examines the HTTP headers to find user information (contained in the Authorization header).
4. If no user information is provided, the Content Engine returns a 401 (Unauthorized) message to the client.
5. The client resends the request, including the user information.
6. The Content Engine sends a request to the authentication server to find an entry for this user.
7. If the server finds a match, the Content Engine allows the request to be serviced normally and stores the client IP address in the authentication cache.
8. If no match is found, the Content Engine again returns a 401 (Unauthorized) message to the client.
In transparent mode, the Content Engine uses the client IP address as a key for the authentication database.
If you are using user authentication in transparent mode, we recommend that the AuthTimeout interval configured with the http authentication cache timeout command be short. IP addresses can be reallocated, or different users can access the Internet through an already authenticated device (PC, workstation, and the like). Shorter AuthTimeout values help reduce the possibility that individuals can gain access using previously authenticated devices. When the Content Engine operates in proxy mode, it can authenticate the user with the user ID and password.
Two authentication servers can be specified with the server host command option to provide redundancy and improved throughput. Content Engine load-balancing schemes distribute the requests to the servers. If the Content Engine cannot connect to either server, no authentication can take place, and users who have not been previously authenticated are denied access.
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.
In some cases, users are located at branch offices. A Content Engine (CE1) can reside with them in the branch office. Another Content Engine (CE2) or another HTTP-compatible proxy device can reside upstream, with an NTLM, RADIUS, or LDAP server available to both Content Engines or devices for user authentication.
|
Note The http append proxy-auth-header global configuration command must be configured on the downstream Content Engines to ensure that proxy authorization information, required by upstream Content Engines, is not stripped from the HTTP request by the downstream Content Engines. Up to 8 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 success, CE2 either serves the request out of its cache or forwards the request to the origin server.
User 2 authentication information is now stored in the authentication cache in both CE1 and CE2. Neither CE1 nor CE2 needs to contact the authentication server for user 2's subsequent requests (unless user 2's entry expires and is removed from the authentication cache).
This scenario assumes that CE1 and CE2 use the same method for authenticating users. Specifically, both Content Engines must expect the user credentials (user ID and password) to be encoded in the same way.
|
Note If you wish to avoid authentication on an upstream Content Engine after authentication is performed downstream, you can use the rule no-auth command to exclude the downstream Content Engine IP address. |
When the Content Engine operates in transparent mode, the user IP address is used as a key to the authentication cache. When user 2 sends a request transparently to CE1, after authentication, CE1 inserts its own IP address as the source for the request. Therefore, CE2 cannot use the source IP address as a key for the authentication cache.
When CE1 inserts its own IP address as the source, it must also insert an X-Forwarded-For header in the request (http append x-forwarded-for-header command). CE2 must first look for an X-Forwarded-For header. If one exists, that IP address must be used to search the authentication cache. Assuming the user is authenticated at CE2, then CE2 must not change the X-Forwarded-For header, just in case there is a transparent CE3 upstream.
In this scenario, if CE1 does not create an X-Forwarded-For header (for example, if it is not a Cisco Content Engine and does not support this header), then authentication on CE2 will not work.
In a topology with two Content Engines, assume that CE1 is operating in transparent mode and CE2 is operating in proxy mode, with the browsers of all users pointing to CE2 as a proxy.
Because the browsers are set up to send requests to a proxy, an HTTP 407 message is sent from CE1 back to each user to prompt for credentials. By using the 407 message, the problem of authenticating based on source IP address is avoided. The username and password can be used instead.
This mode provides better security than using the HTTP 401 message. The Content Engine examines the style of the address to determine whether there is an upstream proxy. If there is, the Content Engine uses an HTTP 407 message to prompt the user for credentials even when operating in transparent mode.
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 30 to 1440 seconds. Its default timeout value is 480 seconds.Use the http autentication cache timeout command to configure this parameter if necessary.
The maximum number of entries that are maintained in authentication cache is 32000. The minimum number is 500. The default value is 16000. Use the http authentication max-entries command to configure this parameter if necessary.
The http authentication command has a header option that can be set to display a message to the client when authorization has failed. In this scenario you can choose http authentication header 401 or http authentication header 407. By default, the Content Engine authenticates cache loads based on the URL syntax of the incoming request.
Use the show http authentication command in EXEC mode to display the authentication cache parameters.
Once a user has been authenticated through LDAP, NTLM, or a RADIUS server, all transaction logs generated by the Content Engine for that user contain user information. If the Content Engine is acting in proxy mode, the user ID is included in the transaction logs. If the Content Engine is acting in transparent mode, the user IP address is included instead.
If the transaction-logs sanitize command is invoked, the user information is suppressed.
In this example, the host for the LDAP server daemon is configured:
Console(config)# ldap server host www.someDomain.com port 390
To delete an LDAP server, use the no ldap server command.
Console(config)# no ldap server host 1.1.1.1
In this example, the host for the RADIUS server is configured:
Console(config)# radius-server 172.16.90.121
In this example, the length of time that entries are valid in the authentication cache is set:
Console(config)# http authentication cache timeout 1000
The following example specifies that the Content Engine should use header 407 when asking the end user for authentication credentials (user ID and password).
Console(config)# http authentication header 407
The ACNS 4.1 software caching application supports both basic and NTLM end-to-end authentication. End-to-end NTLM authentication includes pass-through servicing and the caching of web objects that require NTLM authentication. HTTP request authentication authenticates a user's domain, username, and password with a preconfigured NTLM domain controller before allowing requests from the user to be served by the Content Engine. NTLM authentication works only in a Microsoft environment (for instance, Microsoft Internet Explorer clients accessing Microsoft Internet Information Servers).
|
Note End-to-end NTLM authentication is supported with WCCP Version 2 transparent caching only. For HTTP request authentication, if NTLM authentication is used but the browser does not support NTLM authentication, the username and password information is passed to the Content Engine in clear text with a Basic authentication header. The Content Engine then uses this information to authenticate the user against the preconfigured Windows NT domain controller. |
The ACNS software Cache application can strip NTLM authentication headers to allow fallback to a basic-style authentication challenge against Microsoft Internet Information System (IIS) servers.
This feature is designed to allow browsers to authenticate against a Microsoft IIS web server that issues an NTLM-based challenge. NTLM is proprietary and undocumented. Removing the NTLM headers allows the browser to fall back on the basic authentication method. If IIS is configured to still accept basic authentication, IIS authentication credentials can proceed through a Content Engine, but with reduced security. Use the http authenticate-strip-ntlm global configuration command to enable this feature.
The two levels of NTLM end-to-end support can be summarized as follows:
This example configures a Content Engine for end-to-end NTLM authentication. By default, basic and NTLM authenticated objects are not cached.
Console(config)# no http authenticate-strip-ntlm
Console(config)# http cache-authenticated ntlm
Console# show http cache-authenticated ntlm
Basic authenticated objects are not cached.
NTLM authenticated objects are cached.
Posted: Mon Nov 18 11:27:53 PST 2002
Copyright 1989-2000©Cisco Systems Inc.