Cisco Cisco Web Security Appliance S380 Guía Del Usuario
A-10
AsyncOS 9.2 for Cisco Web Security Appliances User Guide
Appendix A Troubleshooting
Policy Problems
Blocking DOS Executable Object Types Blocks Updates for Windows OneCare
When you configure the Web Security appliance to block DOS executable object types, the appliance
also blocks updates for Windows OneCare.
also blocks updates for Windows OneCare.
Identification Profile Disappeared from Policy
Disabling an Identification Profile removes it from associated policies. Verify that the Identification
Profile is enabled and then add it to the policy again.
Profile is enabled and then add it to the policy again.
Policy Match Failures
•
•
•
•
Policy is Never Applied
If multiple Identification Profiles have identical criteria, AsyncOS assigns the transactions to the first
Identification Profile that matches. Therefore, transactions never match the additional, identical
Identification Profiles, and any policies that apply to those subsequent, identical Identification Profiles
are never matched or applied.
Identification Profile that matches. Therefore, transactions never match the additional, identical
Identification Profiles, and any policies that apply to those subsequent, identical Identification Profiles
are never matched or applied.
HTTPS and FTP over HTTP Requests Match only Access Policies that Do Not Require Authentication
Configure the appliance to use IP addresses as the surrogate when credential encryption is enabled.
When credential encryption is enabled and configured to use cookies as the surrogate type,
authentication does not work with HTTPS or FTP over HTTP requests. This is because the Web Proxy
redirects clients to the Web Proxy itself for authentication using an HTTPS connection if credential
encryption is enabled. After successful authentication, the Web Proxy redirects clients back to the
original website. In order to continue to identify the user, the Web Proxy must use a surrogate (either the
IP address or a cookie). However, using a cookie to track users results in the following behavior if
requests use HTTPS or FTP over HTTP:
authentication does not work with HTTPS or FTP over HTTP requests. This is because the Web Proxy
redirects clients to the Web Proxy itself for authentication using an HTTPS connection if credential
encryption is enabled. After successful authentication, the Web Proxy redirects clients back to the
original website. In order to continue to identify the user, the Web Proxy must use a surrogate (either the
IP address or a cookie). However, using a cookie to track users results in the following behavior if
requests use HTTPS or FTP over HTTP:
•
HTTPS. The Web Proxy must resolve the user identity before assigning a Decryption Policy (and
therefore, decrypt the transaction), but it cannot obtain the cookie to identify the user unless it
decrypts the transaction.
therefore, decrypt the transaction), but it cannot obtain the cookie to identify the user unless it
decrypts the transaction.
•
FTP over HTTP. The dilemma with accessing FTP servers using FTP over HTTP is similar to
accessing HTTPS sites. The Web Proxy must resolve the user identity before assigning an Access
Policy, but it cannot set the cookie from the FTP transaction.
accessing HTTPS sites. The Web Proxy must resolve the user identity before assigning an Access
Policy, but it cannot set the cookie from the FTP transaction.
Therefore, HTTPS and FTP over HTTP requests will match only Access Policies that do not require
authentication. Typically, they match the global Access Policy because it never requires authentication.
authentication. Typically, they match the global Access Policy because it never requires authentication.