- Information About Cisco Cloud Web Security
- Licensing Requirements for Cisco Cloud Web Security
- Prerequisites for Cloud Web Security
- Guidelines and Limitations
- Default Settings
- Configuring Cisco Cloud Web Security
- Configuring Communication with the Cloud Web Security Proxy Server
- (Multiple Context Mode) Allowing Cloud Web Security Per Security Context
- Configuring a Service Policy to Send Traffic to Cloud Web Security
- (Optional) Configuring Whitelisted Traffic
- (Optional) Configuring the User Identity Monitor
- Configuring the Cloud Web Security Policy
- Monitoring Cloud Web Security
- Configuration Examples for Cisco Cloud Web Security
- Single Mode Example
- Multiple Mode Example
- Whitelist Example
- Directory Integration Examples
- Configuring the Active Directory Server Using LDAP
- Configuring the Active Directory Agent Using RADIUS
- Creating the ASA as a Client on the AD Agent Server
- Creating a Link Between the AD Agent and DCs
- Testing the AD Agent
- Configuring the Identity Options on the ASA
- Configuring the User Identity Options and Enabling Granular Reporting
- Monitoring the Active Directory Groups
- Downloading the Entire Active-User Database from the Active Directory Server
- Downloading the Database from the AD Agent
- Showing a List of Active Users
- Cloud Web Security with Identity Firewall Example
- Related Documents
- Feature History for Cisco Cloud Web Security
ASA and Cisco Cloud Web Security
Cisco Cloud Web Security provides web security and web filtering services through the Software-as-a-Service (SaaS) model. Enterprises with the ASA in their network can use Cloud Web Security services without having to install additional hardware.
When Cloud Web Security is enabled on the ASA, the ASA transparently redirects selected HTTP and HTTPS traffic to the Cloud Web Security proxy servers. The Cloud Web Security proxy servers then scan the content and allow, block, or send a warning about the traffic based on the policy configured in Cisco ScanCenter to enforce acceptable use and to protect users from malware.
The ASA can optionally authenticate and identify users with Identity Firewall (IDFW) and AAA rules. The ASA encrypts and includes the user credentials (including usernames and/or user groups) in the traffic it redirects to Cloud Web Security. The Cloud Web Security service then uses the user credentials to match the traffic to the policy. It also uses these credentials for user-based reporting. Without user authentication, the ASA can supply an (optional) default username and/or group, although usernames and groups are not required for the Cloud Web Security service to apply policy.
You can customize the traffic you want to send to Cloud Web Security when you create your service policy rules. You can also configure a “whitelist” so that a subset of web traffic that matches the service policy rule instead goes directly to the originally requested web server and is not scanned by Cloud Web Security.
You can configure a primary and a backup Cloud Web Security proxy server, each of which the ASA polls regularly to check for availability.
Note This feature is also called “ScanSafe,” so the ScanSafe name appears in some commands.
This chapter includes the following sections:
- Information About Cisco Cloud Web Security
- Licensing Requirements for Cisco Cloud Web Security
- Prerequisites for Cloud Web Security
- Guidelines and Limitations
- Default Settings
- Configuring Cisco Cloud Web Security
- Monitoring Cloud Web Security
- Configuration Examples for Cisco Cloud Web Security
- Related Documents
- Feature History for Cisco Cloud Web Security
Information About Cisco Cloud Web Security
This section includes the following topics:
- Redirection of Web Traffic to Cloud Web Security
- User Authentication and Cloud Web Security
- Authentication Keys
- ScanCenter Policy
- Cloud Web Security Actions
- Bypassing Scanning with Whitelists
- IPv4 and IPv6 Support
- Failover from Primary to Backup Proxy Server
Redirection of Web Traffic to Cloud Web Security
When an end user sends an HTTP or HTTPS request, the ASA receives it and optionally retrieves the user and/or group information. If the traffic matches an ASA service policy rule for Cloud Web Security, then the ASA redirects the request to the Cloud Web Security proxy servers. The ASA acts as an intermediary between the end user and the Cloud Web Security proxy server by redirecting the connection to the proxy server. The ASA changes the destination IP address and port in the client requests and adds Cloud Web Security-specific HTTP headers and then sends the modified request to the Cloud Web Security proxy server. The Cloud Web Security HTTP headers include various kinds of information, including the username and user group (if available).
User Authentication and Cloud Web Security
User identity can be used to apply policy in Cloud Web Security. User identity is also useful for Cloud Web Security reporting. User identity is not required to use Cloud Web Security. There are other methods to identify traffic for Cloud Web Security policy.
The ASA supports the following methods of determining the identity of a user, or of providing a default identity:
- AAA rules—When the ASA performs user authentication using a AAA rule, the username is retrieved from the AAA server or local database. Identity from AAA rules does not include group information. If configured, the default group is used. For information about configuring AAA rules, see the legacy feature guide.
- IDFW—When the ASA uses IDFW with the Active Directory (AD), the username and group is retrieved from the AD agent when you activate a user and/or group by using an ACL in a feature such as an access rule or in your service policy, or by configuring the user identity monitor to download user identity information directly.
For information about configuring IDFW, see the general operations configuration guide.
Authentication Keys
Each ASA must use an authentication key that you obtain from Cloud Web Security. The authentication key lets Cloud Web Security identify the company associated with web requests and ensures that the ASA is associated with valid customer.
You can use one of two types of authentication keys for your ASA: the company key or the group key.
Company Authentication Key
A Company authentication key can be used on multiple ASAs within the same company. This key simply enables the Cloud Web Security service for your ASAs. The administrator generates this key in ScanCenter ( https://scancenter.scansafe.com/portal/admin/login.jsp); you have the opportunity to e-mail the key for later use. You cannot look up this key later in ScanCenter; only the last 4 digits are shown in ScanCenter. For more information, see the Cloud Web Security documentation: http://www.cisco.com/en/US/products/ps11720/products_installation_and_configuration_guides_list.html.
Group Authentication Key
A Group authentication key is a special key unique to each ASA that performs two functions:
- Enables the Cloud Web Security service for one ASA.
- Identifies all traffic from the ASA so you can create ScanCenter policy per ASA.
For information about using the Group authentication key for policy, see ScanCenter Policy).
The administrator generates this key in ScanCenter ( https://scancenter.scansafe.com/portal/admin/login.jsp); you have the opportunity to e-mail the key for later use. You cannot look up this key later in ScanCenter; only the last 4 digits are shown in ScanCenter. For more information, see the Cloud Web Security documentation: http://www.cisco.com/en/US/products/ps11720/products_installation_and_configuration_guides_list.html.
ScanCenter Policy
In ScanCenter, traffic is matched against policy rules in order until a rule is matched. Cloud Web Security then applies the configured action for the rule. User traffic can match a policy rule in ScanCenter based on group association: a directory group or a custom group.
Directory Groups
Directory groups define the group to which traffic belongs. The group, if present, is included in the HTTP header of the client request. The ASA includes the group in the HTTP header when you configure IDFW. If you do not use IDFW, you can configure a default group for traffic matching an ASA rule for Cloud Web Security inspection.
When you configure a directory group, you must enter the group name exactly.
When the ASA learns the IDFW group name, the format on the ASA is domain-name \\ group-name. However, the ASA modifies the name to use only one backslash (\) to conform to typical ScanCenter notation.
On the ASA, you need to configure the optional domain name to be followed by 2 backslashes (\\); however, the ASA modifies the name to use only one backslash (\) to conform to typical ScanCenter notation. For example, if you specify “Cisco\\Boulder1,” the ASA modifies the group name to be “Cisco\Boulder1” with only one backslash (\) when sending the group name to Cloud Web Security.
Custom Groups
Custom groups are defined using one or more of the following criteria:
- ScanCenter Group authentication key—You can generate a Group authentication key for a custom group. Then, if you identify this group key when you configure the ASA, all traffic from the ASA is tagged with the Group key.
- Source IP address—You can identify source IP addresses in the custom group. Note that the ASA service policy is based on source IP address, so you might want to configure any IP address-based policy on the ASA instead.
- Username—You can identify usernames in the custom group.
– IDFW usernames are sent in the following format:
– AAA usernames, when using RADIUS or TACACS+, are sent in the following format:
– AAA usernames, when using LDAP, are sent in the following format:
– For the default username, it is sent in the following format:
For example, if you configure the default username to be “Guest,” then the ASA sends “Guest.” If you configure the default username to be “Cisco\Guest,” then the ASA sends “Cisco\Guest.”
How Groups and the Authentication Key Interoperate
Unless you need the per-ASA policy that a custom group+group key provides, you will likely use a company key. Note that not all custom groups are associated with a group key. Non-keyed custom groups can be used to identify IP addresses or usernames, and can be used in your policy along with rules that use directory groups.
Even if you do want per-ASA policy and are using a group key, you can also use the matching capability provided by directory groups and non-keyed custom groups. In this case, you might want an ASA-based policy, with some exceptions based on group membership, IP address, or username. For example, if you want to exempt users in the America\Management group across all ASAs:
1. Add a directory group for America\Management.
2. Add an exempt rule for this group.
3. Add rules for each custom group+group key after the exempt rule to apply policy per-ASA.
4. Traffic from users in America\Management will match the exempt rule, while all other traffic will match the rule for the ASA from which it originated.
Many combinations of keys, groups, and policy rules are possible.
Cloud Web Security Actions
After applying the configured policies, Cloud Web Security either blocks, allows, or sends a warning about the user request:
- Allows—When Cloud Web Security allows the client request, it contacts the originally requested server and retrieves the data. It forwards the server response to the ASA, which then forwards it to the user.
- Blocks—When Cloud Web Security blocks the client request, it notifies the user that access has been blocked. It sends an HTTP 302 “Moved Temporarily” response that redirects the client application to a web page hosted by the Cloud Web Security proxy server showing the blocked error message. The ASA forwards the 302 response to the client.
- Warns—When the Cloud Web Security proxy server determines that a site may be in breach of the acceptable use policy, it displays a warning page about the site. You can choose to heed the warning and drop the request to connect, or you can click through the warning and proceed to the requested site.
You can also choose how the ASA handles web traffic when it cannot reach either the primary or backup Cloud Web Security proxy server. It can block or allow all web traffic. By default, it blocks web traffic.
Bypassing Scanning with Whitelists
If you use AAA rules or IDFW, you can configure the ASA so that web traffic from specific users or groups that otherwise match the service policy rule is not redirected to the Cloud Web Security proxy server for scanning. When you bypass Cloud Web Security scanning, the ASA retrieves the content directly from the originally requested web server without contacting the proxy server. When it receives the response from the web server, it sends the data to the client. This process is called “whitelisting” traffic.
Although you can achieve the same results of exempting traffic based on user or group when you configure the class of traffic using ACLs to send to Cloud Web Security, you might find it more straightforward to use a whitelist instead. Note that the whitelist feature is only based on user and group, not on IP address.
IPv4 and IPv6 Support
Cloud Web Security currently supports only IPv4 addresses. If you use IPv6 internally, NAT 64 must be performed for any IPv6 flows that need to be sent to Cloud Web Security.
The following table shows the class map traffic that is supported by Cloud Web Security redirection:
|
|
---|---|
Failover from Primary to Backup Proxy Server
When you subscribe to the Cisco Cloud Web Security service, you are assigned a primary Cloud Web Security proxy server and backup proxy server.
If any client is unable to reach the primary server, then the ASA starts polling the tower to determine availability. (If there is no client activity, the ASA polls every 15 miniutes.) If the proxy server is unavailable after a configured number of retries (the default is 5; this setting is configurable), the server is declared unreachable, and the backup proxy server becomes active.
If a client or the ASA can reach the server at least twice consecutively before the retry count is reached, the polling stops and the tower is determined to be reachable.
After a failover to the backup server, the ASA continues to poll the primary server. If the primary server becomes reachable, then the ASA returns to using the primary server.
Licensing Requirements for Cisco Cloud Web Security
|
|
---|---|
Strong Encryption (3DES/AES) License to encrypt traffic between the ASA and the Cloud Web Security server. |
On the Cloud Web Security side, you must purchase a Cisco Cloud Web Security license and identify the number of users that the ASA handles. Then log into ScanCenter, and generate your authentication keys.
Prerequisites for Cloud Web Security
(Optional) User Authentication Prerequisites
To send user identity information to Cloud Web Security, configure one of the following on the ASA:
- AAA rules (username only)—See the legacy feature guide.
- IDFW (username and group)—See the general operations configuration guide.
(Optional) Fully Qualified Domain Name Prerequisites
If you use FQDNs in ACLs for your service policy rule, or for the Cloud Web Security server, you must configure a DNS server for the ASA according to the general operations configuration guide.
Guidelines and Limitations
Supported in single and multiple context modes.
In multiple context mode, the server configuration is allowed only in the system, and the service policy rule configuration is allowed only in the security contexts.
Each context can have its own authentication key, if desired.
Supported in routed firewall mode only. Does not support transparent firewall mode.
Does not support IPv6. See IPv4 and IPv6 Support.
- Cloud Web Security is not supported with ASA clustering.
- Clientless SSL VPN is not supported with Cloud Web Security; be sure to exempt any clientless SSL VPN traffic from the ASA service policy for Cloud Web Security.
- When an interface to the Cloud Web Security proxy servers goes down, output from the show scansafe server command shows both servers up for approximately 15-25 minutes. This condition may occur because the polling mechanism is based on the active connection, and because that interface is down, it shows zero connection, and it takes the longest poll time approach.
- Cloud Web Security is not supported with the ASA CX module. If you configure both the ASA CX action and Cloud Web Security inspection for the same traffic, the ASA only performs the ASA CX action.
- Cloud Web Security inspection is compatibile with HTTP inspection for the same traffic. HTTP inspection is enabled by default as part of the default global policy.
- Cloud Web Security is not supported with extended PAT or any application that can potentially use the same source port and IP address for separate connections. For example, if two different connections (targeted to separate servers) use extended PAT, the ASA might reuse the same source IP and source port for both connection translations because they are differentiated by the separate destinations. When the ASA redirects these connections to the Cloud Web Security server, it replaces the destination with the Cloud Web Security server IP address and port (8080 by default). As a result, both connections now appear to belong to the same flow (same source IP/port and destination IP/port), and return traffic cannot be untranslated properly.
- The match default-inspection-traffic command does not include the default ports for the Cloud Web Security inspection (80 and 443).
Default Settings
Configuring Cisco Cloud Web Security
- Configuring Communication with the Cloud Web Security Proxy Server
- (Multiple Context Mode) Allowing Cloud Web Security Per Security Context
- Configuring a Service Policy to Send Traffic to Cloud Web Security
- (Optional) Configuring Whitelisted Traffic
- Configuring the Cloud Web Security Policy
Configuring Communication with the Cloud Web Security Proxy Server
Guidelines
The public key is embedded in the ASA software, so there is no need for you to configure it.
Detailed Steps
|
|
|
---|---|---|
|
||
server primary { ip ip_address | fqdn fqdn} [ port port ] |
Configures the fully qualified domain name or IP address of the primary Cloud Web Security proxy server. By default, the Cloud Web Security proxy server uses port 8080 for both HTTP and HTTPS traffic; do not change this value unless directed to do so. |
|
server backup { ip ip_address | fqdn fqdn} [ port port ] hostname(cfg-scansafe)# server backup fqdn server.example.com |
(Optional) Configures the fully qualified domain name or IP address of the backup Cloud Web Security proxy server. By default, the Cloud Web Security proxy server uses port 8080 for both HTTP and HTTPS traffic; do not change this value unless directed to do so. |
|
|
(Optional) Enters the value for the number of consecutive polling failures to the Cloud Web Security proxy server before determining the server is unreachable. Polls are performed every 30 seconds. Valid values are from 2 to 100, and the default is 5. |
|
|
Configures the authentication key that the ASA sends to the Cloud Web Security proxy servers to indicate from which organization the request comes. The authentication key is a 16-byte hexidecimal number. See Authentication Keys. |
Examples
The following example configures a primary and backup server:
(Multiple Context Mode) Allowing Cloud Web Security Per Security Context
In multiple context mode, you must allow Cloud Web Security per context. For more information, see the general operations configuration guide.
Note You must configure a route pointing to the Scansafe towers in both; the admin context and the specific context. This ensures that the Scansafe tower does not become unreachable in the Active/Active failover scenario.
The following sample configuration enables Cloud Web Security in context one with the default license and in context two with the license key override:
Configuring a Service Policy to Send Traffic to Cloud Web Security
See “Service Policy Using the Modular Policy Framework,” for more information about service policy rules.
Prerequisites
(Optional) If you need to use a whitelist to exempt some traffic from being sent to Cloud Web Security, first create the whitelist according to the (Optional) Configuring Whitelisted Traffic so you can refer to the whitelist in your service policy rule.
Detailed Steps
|
|
|
---|---|---|
policy-map type inspect scansafe name1 hostname(config)# policy-map type inspect scansafe cws_inspect_pmap1 |
Creates an inspection policy map so you can configure essential parameters for the rule and also optionally identify the whitelist. An inspection policy map is required for each class of traffic that you want to send to Cloud Web Security. The policy_map_name argument can be up to 40 characters in length. |
|
|
Parameters lets you configure the protocol and the default user or group. You enter parameters configuration mode. |
|
|
You can only specify one service type for this inspection policy map, either http or https. |
|
default { [user username ] [ group groupname ]} |
Specifies that if the ASA cannot determine the identity of the user coming into the ASA, then the default user and/or group is included in the HTTP header. |
|
|
Identifies the whitelist class map name that you created in the (Optional) Configuring Whitelisted Traffic. |
|
|
||
policy-map type inspect scansafe name2 default { [user user ] [ group group ]} hostname(config)# policy-map type inspect scansafe cws_inspect_pmap2 hostname(config-pmap)# parameters hostname(config-pmap-p)# default group2 default_group2 |
Repeat Step 1 to Step 6 to create a separate class map for HTTPS traffic (for example). You can create an inspection class map for each class of traffic you want to send to Cloud Web Security. You can reuse an inspection class map for multiple classes of traffic if desired. |
|
access-list access_list_name [ line line_number ] extended { deny | permit } tcp [ user_argument ] [ security_group_argument ] source_address_argument [ port_argument ] dest_address_argument [ port_argument ] hostname(config)# object network cisco1 hostname(config-object-network)# fqdn www.cisco.com hostname(config)# object network cisco2 hostname(config-object-network)# fqdn tools.cisco.com hostname(config)# access-list SCANSAFE_HTTP extended deny tcp any4 object cisco1 eq 80 hostname(config)# access-list SCANSAFE_HTTP extended deny tcp any4 object cisco2 eq 80 hostname(config)# access-list SCANSAFE_HTTP extended permit tcp any4 any4 eq 80 |
Identifies the class of traffic you want to send to Cloud Web Security. Create an ACL consisting of one or more access control entries (ACEs). For detailed information about ACLs, see the general operations configuration guide. Cloud Web Security only operates on HTTP and HTTPS traffic. Each type of traffic is treated separately by the ASA. Therefore, you need to create HTTP-only ACLs and HTTPS-only ACLs. Create as many ACLs as needed for your policy. A permit ACE sends matching traffic to Cloud Web Security. A deny ACE exempts traffic from the service policy rule, so it is not sent to Cloud Web Security. When creating your ACLs, consider how you can match appropriate traffic that is destined for the Internet, but not match traffic that is destined for other internal networks. For example, to prevent inside traffic from being sent to Cloud Web Security when the destination is an internal server on the DMZ, be sure to add a deny ACE to the ACL that exempts traffic to the DMZ. FQDN network objects might be useful in exempting traffic to specific servers. The user_argument lets you specify the IDFW username or group, either inline or by referring to an object group. The security_group_argument lets you specify the TrustSec security group, either inline or by referring to an object group. Note that although you can match traffic to send to Cloud Web Security by security group, the ASA does not send security group information to Cloud Web Security in the HTTP header; Cloud Web Security cannot create policy based on the security group. |
|
|
Creates a class map to identify the traffic for which you want to enable Cloud Web Security filtering. |
|
|
Specifies an ACL created in Step 8. Although you can use other match statements for this rule, we recommend using the match access-list command because it is the most versatile for identifying HTTP or HTTPS-only traffic. See Identifying Traffic (Layer 3/4 Class Maps) for more information. |
|
|
(Optional) Creates an additional class map, for example for HTTPS traffic. You can create as many classes as needed for this service policy rule. |
|
|
Adds or edits a policy map that sets the actions to take with the class map traffic. The policy map in the default global policy is called global_policy. You can edit this policy, or create a new one. You can only apply one policy to each interface or globally. |
|
|
Identifies the class map created in Step 9. |
|
inspect scansafe scansafe_policy_name1 [ fail-open | fail-close ] hostname(config-pmap-c)# inspect scansafe cws_inspect_pmap1 fail-open |
Enables Cloud Web Security inspection on the traffic in this class. Specify the inspection class map name that you created in Step 1. Specify fail-open to allow traffic to pass through the ASA if the Cloud Web Security servers are unavailable. Specify fail-close to drop all traffic if the Cloud Web Security servers are unavailable. fail-close is the default. |
|
inspect scansafe scansafe_policy_name2 [ fail-open | fail-close ] hostname(config-pmap)# class cws_class2 hostname(config-pmap-c)# inspect scansafe cws_inspect_pmap2 fail-open |
(Optional) Identifies a second class map that you created in Step 11, and enables Cloud Web Security inspection for it. |
|
service-policy policymap_name {global | interface interface_name } |
Activates the policy map on one or more interfaces. global applies the policy map to all interfaces, and interface applies the policy to one interface. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface. See Applying Actions to an Interface (Service Policy) for more information. |
Examples
The following example configures two classes: one for HTTP and one for HTTPS. Each ACL exempts traffic to www.cisco.com and to tools.cisco.com, and to the DMZ network, for both HTTP and HTTPS. All other traffic is sent to Cloud Web Security, except for traffic from several whitelisted users and groups. The policy is then applied to the inside interface.
(Optional) Configuring Whitelisted Traffic
If you use user authentication, you can exempt some traffic from being filtered by Cloud Web Security based on the username and/or groupname. When you configure your Cloud Web Security service policy rule, you can reference the whitelisting inspection class map. Both IDFW and AAA user credentials can be used with this feature.
Although you can achieve the same results of exempting traffic based on user or group when you configure the service policy rule, you might find it more straightforward to use a whitelist instead. Note that the whitelist feature is only based on user and group, not on IP address.
Detailed Steps
Example
The following example whitelists the same users and groups for the HTTP and HTTPS inspection policy maps:
(Optional) Configuring the User Identity Monitor
When you use IDFW, the ASA only downloads user identity information from the AD server for users and groups included in active ACLs; the ACL must be used in a feature such as an access rule, AAA rule, service policy rule, or other feature to be considered active. Because Cloud Web Security can base its policy on user identity, you may need to download groups that are not part of an active ACL to get full IDFW coverage for all your users. For example, although you can configure your Cloud Web Security service policy rule to use an ACL with users and groups, thus activating any relevant groups, it is not required; you could use an ACL based entirely on IP addresses.The user identity monitor feature lets you download group information directly from the AD agent.
Restrictions
The ASA can only monitor a maximum of 512 groups, including those configured for the user identity monitor and those monitored through active ACLs.
Detailed Steps
Configuring the Cloud Web Security Policy
After you configure the ASA service policy rules, launch the ScanCenter Portal to configure Web content scanning, filtering, malware protection services, and reports.
Detailed Steps
Go to: https://scancenter.scansafe.com/portal/admin/login.jsp.
For more information, see the Cisco ScanSafe Cloud Web Security Configuration Guides:
http://www.cisco.com/en/US/products/ps11720/products_installation_and_configuration_guides_list.html
Monitoring Cloud Web Security
The show scansafe server command shows whether or not the Cloud Web Security proxy servers are reachable:
The show scansafe statistics command shows information about Cloud Web Security activity, such as the number of connections redirected to the proxy server, the number of current connections being redirected, and the number of whitelisted connections:
The show service policy inspect scansafe command shows the number of connections that are redirected or whitelisted by a particular policy:
Configuration Examples for Cisco Cloud Web Security
- Single Mode Example
- Multiple Mode Example
- Whitelist Example
- Directory Integration Examples
- Cloud Web Security with Identity Firewall Example
Single Mode Example
The following example shows a complete configuration for Cisco Cloud Web Security:
We recommend that you split the traffic by creating separate HTTP and HTTPS class maps so that you know how many HTTP and HTTPS packets have gone through.
Then, if you need to troubleshoot you can run debug commands to distinguish how many packets have traversed each class map and find out if you are pushing through more HTTP or HTTPS traffic:
Configure Inspection Policy Maps
Configure Cloud Web Security on the ASA
Multiple Mode Example
The following example enables Cloud Web Security in context one with the default license and in context two with the authentication key override:
Whitelist Example
Configure what access-list traffic should be sent to Cloud Web Security:
To configure the whitelist to ensure user1 is in this access-list range to bypass Cloud Web Security:
To attach class-maps to the Cloud Web Security Policy map:
After creating this inspect policy, attach it to the policy map to be assigned to the service group:
Then attach the policy map to a service-policy to make it in effect globally or by ASA interface:
Directory Integration Examples
This section contains various example configurations for directory integration.
- Configuring the Active Directory Server Using LDAP
- Configuring the Active Directory Agent Using RADIUS
- Creating the ASA as a Client on the AD Agent Server
- Creating a Link Between the AD Agent and DCs
- Testing the AD Agent
- Configuring the Identity Options on the ASA
- Configuring the User Identity Options and Enabling Granular Reporting
- Monitoring the Active Directory Groups
- Downloading the Entire Active-User Database from the Active Directory Server
- Downloading the Database from the AD Agent
- Showing a List of Active Users
Configuring the Active Directory Server Using LDAP
The following example shows how to configure the Active Directory server on your ASA using LDAP:
Configuring the Active Directory Agent Using RADIUS
The following example shows how to configure the Active Directory Agent on your ASA using RADIUS:
Creating the ASA as a Client on the AD Agent Server
The following example shows how to create the ASA as a client on the Active Directory agent server:
Creating a Link Between the AD Agent and DCs
The following example shows how to create a link between the Active Directory Agent and all DCs for which you want to monitor logon/logoff events:
Running the last command should show the status as “UP.”
For the AD_Agent to monitor logon/logoff events, you need to ensure that these are logged on ALL DCs that are actively being monitored. To do this, choose:
Start > Administrative Tools > Domain Controller Security Policy
Local policies > Audit Policy > Audit account logon events (success and failure)
Testing the AD Agent
The following example shows how to configure the test Active Directory Agent so that it can communicate with the ASA:
See also the following command: show user-identity ad-agent.
Configuring the Identity Options on the ASA
The following example shows how to configure the identity options on the ASA:
Configuring the User Identity Options and Enabling Granular Reporting
The following example shows how to configure the user identity options that send user credentials to the ASA and enable granular user reporting from the proxy server:
If you are using more than one domain, then enter the following command:
Monitoring the Active Directory Groups
The following example shows how to configure Active Directory groups to be monitored:
Downloading the Entire Active-User Database from the Active Directory Server
The following command updates the specified import user group database by querying the Active Directory server immediately without waiting for the expiration of poll-import-user-group-timer:
Downloading the Database from the AD Agent
The following example shows how to manually start the download of the database from the Active Directory Agent if you think the user database is out of sync with Active Directory:
Showing a List of Active Users
The following example shows how to show the Active users:
There are two download modes with Identify Firewall: Full download and On-demand.
- Full download—Whenever a user logs into the network, the IDFW tells the ASA the User identity immediately (recommended on the ASA 5512-X and above).
- On-demand—Whenever a user logs into the network, the ASA requests the user identity from AD (ADHOC) (recommended on the ASA 5505 due to memory constraints).
Cloud Web Security with Identity Firewall Example
The following example shows how to configure Cloud Web Security with Identity Firewall on the ASA:
Related Documents
|
|
---|---|
http://www.cisco.com/en/US/products/ps11720/products_installation_and_configuration_guides_list.html |
Feature History for Cisco Cloud Web Security
Table 21-1 lists each feature change and the platform release in which it was implemented.