06-10-2009 11:25 PM - edited 03-08-2019 05:59 PM
VPN gateways operate in dynamic environments. Multiple variables can affect each VPN connection, for example, intranet configurations that frequently change, the various roles each user may inhabit within an organization, and logins from remote access sites with different configurations and levels of security. The task of authorizing users is much more complicated in a dynamic VPN environment than it is in a network with a static configuration.
Dynamic access policies (DAP), a new feature introduced in software release v8.0 code of the Adaptive Security Appliance (ASA), enable you to configure authorization that addresses the dynamics of VPN environments. You create a dynamic access policy by setting a collection of access control attributes that you associate with a specific user tunnel or session. These attributes address issues of multiple group membership and endpoint security.
For example, the security appliance grants access (and permissions) to a particular VPN remote access user/session based on the policies you define. It generates a DAP during user authentication by selecting and/or aggregating attributes from one or more DAP records. It selects these DAP records based on the endpoint security information of the remote device and/or AAA authorization information for the authenticated user. It then applies the DAP record to the user tunnel or session.
DAP complements AAA services and provides a limited set of authorization attributes that can override attributes that AAA provides. The security appliance can select DAP records based on the AAA authorization information for the user. The security appliance can select multiple DAP records depending on this information, which it then aggregates to assign DAP authorization attributes.
You can specify AAA attributes from the Cisco AAA attribute hierarchy, or from the full set of response attributes that the security appliance receives from a RADIUS or LDAP server as shown in Figure 1.
Note: All configured DAP records are evaluated after successful Authentication,Authorization, Accounting(optional) exchanges take place. DAP priority doesn't determine which DAP policy will be applied. Priority is used for aggregation of ACLs and their ordering, when multiple DAP records are matched.
All DAPs are processed, and only those that match will be enforced. This is explained later in the document.
Figure 1. DAP AAA Attribute GUI
In addition to AAA attributes, the security appliance can also obtain endpoint security attributes by using posture assessment methods that you configure. These include Basic Host Scan, Secure Desktop, Standard/Advanced Endpoint Assessment and NAC as shown in Figure 2. Endpoint Assessment Attributes are obtained and sent to the security appliance prior to user authentication via Cisco Security Desktop (a.k.a CSD). However, AAA Attributes, including the overall DAP record, are validated during user authentication.
Figure 2. Endpoint Attribute GUI
Prior to the introduction and implementation of DAP, access policy attribute/value pairs that were associated with a specific user tunnel or session were defined either locally on the ASA, (Tunnel Groups and Group Policies) or mapped via external AAA servers. However, in the v8.0 release, DAP can be configured to complement or override both local and external access policies.
DAP is always enforced by default. However, for administrators who prefer the legacy policy enforcement method, for example, enforcing access control via Tunnel Groups/Group Policies and AAA without the explicit enforcement of DAP , can still obtain this behavior. For legacy behavior, no configuration changes to the DAP feature, including the default DAP record, DfltAccessPolicy, are required as shown in Figure 3.
Figure 3. Default Dynamic Access Policy
Nevertheless, if any of the default values in a DAP record are changed, for example, the Action parameter in the DfltAccessPolicy is changed from its default value (Continue) to Terminate and additional DAP records are not configured , authenticated users will, by default, match the DfltAccessPolicy DAP record and will as a result be denied VPN access.
Consequently, one or more DAP records will need to be created and configured to authorize VPN connectivity and define which network resources an authenticated user is authorized to access. Thus, DAP, if configured, its access/authorization attributes will take precedence over legacy policy enforcement (tunnel-group and group-policy and AAA enforced authorization via LDAP/Radius).
Refer to Understanding Policy Enforcement of Permissions and Attributes section of the ASA configuration guide for more information on VPN policy hierarchy , http://www.cisco.com/en/US/partner/docs/security/asa/asa83/configuration/guide/ref_extserver.html#wp1773735.
The security appliance supports several methods of applying user authorization attributes (also called user entitlements or permissions) to VPN connections. You can configure the security appliance to enforce VPN remote access user/session attributes from a Dynamic Access Policy (DAP) on the security appliance, from an external authentication and/or authorization AAA server (RADIUS or LDAP), from a group policy on the security appliance, or from all three.
If the security appliance receives attributes from all sources, the attributes are evaluated, merged, and applied to the user policy. If there are conflicts between attributes coming from the DAP, the AAA server, or the group policy, those attributes obtained from the DAP always take precedence.
The security appliance applies attributes in the following order (also illustrated in Figure 3.1 below):
1. DAP attributes on the security appliance—Introduced in Version 8.0, take precedence over all others. For example, if you set a bookmark/URL list in a matching DAP(s), it overrides a bookmark/URL list set in the group policy.
2. User attributes on the AAA server—The server returns these after successful user authentication and/or authorization. Do not confuse these with attributes that are set for individual users in the local AAA database on the security appliance (User Accounts in ASDM).
3. Group policy configured on the security appliance—If a RADIUS server returns the value of the RADIUS CLASS attribute IETF-Class-25 (OU=<group-policy>) for the user, the security appliance places the user in the group policy of the same name and enforces any attributes in the group policy that are not returned by the server. For LDAP servers, any attribute name can be used to set the group policy for the session. The LDAP attribute map you configure on the security appliance maps the LDAP attribute to the Cisco attribute IETF-Radius-Class.
Examples of LDAP authorization use cases using Active Directory are detailed at http://www.cisco.com/en/US/partner/docs/security/asa/asa83/configuration/guide/ref_extserver.html#wp1572118 .
Note: In ASA version 8.2 the IETF-Radius-Class LDAP attribute changed to Group-Policy. LDAP attribute maps with the older attribute name IETF-Radius-Class will still be functional when upgrading from ASA version 8.0.x to 8.2.x.
For a complete list of Cisco Radius and LDAP authorization vendor Specific Attributes (VSAs) please reference tables C-7 and C-2 respectively in http://www.cisco.com/en/US/partner/docs/security/asa/asa83/configuration/guide/ref_extserver.html#wp1773708 .
4. Group policy assigned by the Connection Profile (called tunnel-group in CLI)—The Connection Profile has the preliminary settings for the connection, and includes a default group policy applied to the user before authentication. All users connecting to the security appliance initially belong to this group which provides any attributes that are missing from the DAP, user attributes returned by the server, or the group policy assigned to the user.
5. Default group policy assigned by the security appliance (DfltGrpPolicy)—System default attributes provide any values that are missing from the DAP, user attributes, group policy, or connection profile.
Figure 3.1 . VPN Policy Enforcement Hierarchy
When using DAP to define which network resources a user has access to, there are many parameters to consider. For example, identifying whether the connecting endpoint is coming from a managed/trusted, unmanaged/untrusted environment, determining selection criteria necessary to identify the connecting endpoint, and based on endpoint assessment and/or AAA credentials, which network resources the connecting user will be authorized to access. To accomplish this, you will first need to become familiar with DAP features and functions as shown in Figure 4.
Figure 4. Dynamic Access Policy
When configuring a DAP record, there are two major components to consider:
The Selection Criteria section is where an administrator would configure AAA and Endpoint attributes used to select a specific DAP policy record. A DAP record is used when a user’s authorization attributes match the configured AAA attribute criteria and every endpoint attribute has been satisfied.
For example, if the AAA Attribute Type: LDAP (Active Directory) is selected, the Attribute Name string is memberOf and the Value string is Contractors, as shown in Figure 5a, the authenticating user must be a member of the Active Directory group Contractors to match the AAA attribute criteria.
In addition to satisfying the AAA attribute criteria, the authenticating user will also be required to satisfy the endpoint attribute criteria. For example, if the administrator configured Cisco Secure Desktop (CSD) to determine the posture of the connecting endpoint and based on that posture assessment, the endpoint was placed in the CSD Location Unmanaged, the administrator could then use this assessment information as selection criteria for the endpoint attribute shown in Figure 5b.
Figure 5a. AAA Attribute Criteria
Figure 5b. Endpoint Attribute Criteria
Thus, to match the DAP record shown in Figure 6, the authenticating user must be a member of the Contractors Active Directory group and its connecting endpoint must satisfy the CSD policy value “Unmanaged,” to be assigned the DAP record.
Figure 6. AAA and Endpoint Attribute Criteria Match
AAA and Endpoint attributes can be created using the tables as described in Figure 6 and/or by expanding the Advanced option to specify a logical expression as shown in Figure 7. Currently, the logical expression is constructed with EVAL functions, for example, EVAL (endpoint.av.McAfeeAV.exists,"EQ","true","string") and EVAL (endpoint.av.McAfeeAV.description,"EQ","McAfee VirusScan Enterprise","string"), that represent AAA and/or endpoint selection logical operations.
Logical Expressions are useful for adding selection criteria other than what is possible in the AAA and endpoint attribute areas above. For example, while you can configure the security appliances to use AAA attributes that satisfy any, all or none of the specified criteria, endpoint attributes are cumulative, and must all be satisfied. To let the security appliance employ one endpoint attribute or another, you need to create appropriate logical expressions under the Advanced section of the DAP record.
Figure 7. Logical Expression GUI for Advanced Attribute creation
The Access Policy Attributes section as shown in Figure 8 is where an administrator would configure VPN access attributes for a specific DAP record. When a user’s authorization attributes match the AAA, Endpoint and/or Logical Expression criteria; the configured access policy attribute values in this section will be enforced. Attribute values specified here will override those values obtained from the AAA system, including those in existing user, group, tunnel group, and default group records.
A DAP record has a limited set of access/authorization attribute values that can be configured. These are a subset of attributes found in the group-policy. These values fall under the following tabs as shown in the Figures 8 through 14:
Figure 8. Action —Specifies special processing to apply to a specific connection or session.
Figure 9. Network ACL Filters Tab—Lets you select and configure network ACLs to apply to this DAP record. An ACL for DAP can contain permit or deny rules, but not both. If an ACL contains both permit and deny rules, the security appliance rejects the ACL configuration.
Note: Network/Layer 3 ACLs control traffic over full tunnel clients (IPSec and AnyConnect SSL VPN). Doesn't apply to Clientless SSLVPN sessions.
Figure 10. Web-Type ACL Filters Tab—Lets you select and configure web-type ACLs to apply to this DAP record. An ACL for DAP can contain only permit or deny rules. If an ACL contains both permit and deny rules, the security appliance rejects the ACL configuration.
Note: Web-Type ACLs control Layer 7 traffic over Clientless SSL VPN sessions. Doesn't apply to IPsec and AnyConnect SSL VPN full-tunnel clients.
Figure 11. Functions Tab—Lets you configure file server entry and browsing, HTTP proxy, and URL entry for the DAP record.
This is a component of the legacy portforwarder. An advanced portforwarder was implemented with Smart Tunnels and it is the recommended method, whenever possible for Windows and Mac clients. Smart tunnels are currently enforced in Group Policies.
Figure 12. Port Forwarding Lists Tab —Lets you select and configure port forwarding lists for user sessions.
Figure 13. Bookmarks tab—Lets you select and configure bookmarks/URL lists for user sessions.
Figure 14. Method Tab—Lets you configure the type of remote access permitted.
As mentioned previously, a DAP record has a limited set of default attribute values, only if they are modified will they take precedence over existing AAA, user, group, tunnel group, and default group records. If additional attribute values outside the scope of DAP is required, for example, Split Tunneling Lists, Banners, Smart Tunnels, Portal Customizations, …etc, will then need to be enforced via Radius/LDAP or the group-policy hierarchy. In this case, those specific attribute values will complement DAP and will not be overriding. Thus, the VPN user will get a cumulative set of attribute values across all records.
An administrator can configure multiple DAP records to address many variables. As a result, it is possible for an authenticating user to satisfy the AAA and Endpoint attribute criteria of multiple DAP records. In consequence, Access Policy Attributes will either be consistent or conflict throughout these policies. In this case, the authorized user will get the cumulative result across all matched DAP records.
This also includes unique attribute values enforced via authentication, authorization, user, group, tunnel group, and default group records. The cumulative result of Access Policy Attributes creates the Dynamic Access Policy. Examples of combined Access Policy Attributes are listed in the Tables below. These examples depict the results of 3 combined DAP records.
The Action attribute shown in Table 1 has a value that is either Terminate or Continue. The aggregated attribute value will be Terminate if the Terminate value is configured in any of the selected DAP records and Continue if the Continue value is configured in all of the selected DAP records.
Attribute Name
DAP#1
DAP#2
DAP#3
DAP
Table 1. Action Attribute | ||||
Action (Example 1) | continue | continue | continue | continue |
Action (Example 2) | Terminate | continue | continue | terminate |
The User-Message attribute shown in Table 2 contains a string value. The aggregated attribute value will be a line-feed (hex value 0x0A) separated string created by linking together the attribute values from the selected DAP records. The ordering of the attribute values in the combined string is insignificant.
Attribute Name
DAP#1
DAP#2
DAP#3
DAP
Table 2. User-Message Attribute | ||||
user-message | the quick | brown fox | Jumps over | the quick<LF>brown fox<LF>jumps over |
The Clientless feature enabling attributes (Functions) shown in Table 3 contain values that are Auto-start, Enable or Disable. The aggregated attribute value will be Auto-start if the Auto-Start value is configured in any of the selected DAP records.
The aggregated attribute value will be Enable if there is no Auto-start value configured in any of the selected DAP records, and the Enable value is configured in at least one of the selected DAP records.
The aggregated attribute value will be Disable if there is no Auto-start or Enable value configured in any of the selected DAP records, and the “disable” value is configured in at least one of the selected DAP records.
Attribute Name
DAP#1
DAP#2
DAP#3
DAP
Table 3. Clientless Feature Enabling Attributes (Functions) | ||||
port-forward | enable | disable | enable | |
file-browsing | disable | enable | disable | enable |
file-entry | disable | disable | ||
http-proxy | disable | auto-start | disable | auto-start |
url-entry | disable | enable | enable |
The Bookmarks and Port-Forward Lists attributes shown in Table 4 contain a value that is either a string or a comma separated string. The aggregated attribute value will be a comma separated string created by linking together the attribute values from the selected DAP records. Any duplicate attribute value in the combined string will be removed. The ordering of the attributes values in the combined string is insignificant.
Attribute Name
DAP#1
DAP#3
DAP#3
DAP
Table 4. URL List and Port Forward List Attribute | ||||
url-list | a | b,c | a | a,b,c |
port-forward | d,e | e,f | d,e,f |
The Access Method attributes specifies the client access method allowed for SSL VPN connections. The possible options are:
This option takes up one SSL VPN session license on the ASA.
This option takes up two SSL VPN session licenses on the ASA.
The aggregated attribute value is summarized in Table 5.
Attribute Values Selected
Aggregation result
AnyConnect Client
Web- Portal
Both-default-Web- Portal
Both-default-AnyConnect Client
Table 5. Access Method Attributes | ||||
X | Both-default-AnyConnect Client | |||
X | Both-default-Web-Portal | |||
X | X | Both-default-Web-Portal | ||
X | Web-Portal | |||
X | X | Both-default-AnyConnect Client | ||
X | X | Both-default-Web-Portal | ||
X | X | X | Both-default-Web-Portal | |
X | AnyConnect Client | |||
X | X | Both-default-AnyConnect Client | ||
X | X | Both-default-Web-Portal | ||
X | X | X | Both-default-Web-Portal | |
X | X | Both-default-Web-Portal | ||
X | X | X | Both-default-AnyConnect Client | |
X | X | X | Both-default-Web-Portal | |
X | X | X | X | Both-default-Web-Portal |
When aggregating Network and Web-Type (Clientless) ACL Filter attributes, the DAP Priority and DAP ACL are two major components to consider.
The Priority attribute as shown in Figure 15 is not aggregated. The security appliance uses this value to logically sequence the access lists when aggregating the Network and Web-Type ACLs from multiple DAP records. The security appliance orders the records from highest to lowest priority number, with lowest at the bottom of the table.
For instance, a DAP record with a value of 4 has a higher priority than a record with a value of 2. You cannot manually sort them.
Figure 15. Priority —Displays the priority of the DAP record.
The DAP ACL attribute only supports access-lists that conform to either a strict “White-List”/permit or strict “Black-List”/deny ACL model. In a “White-List” ACL model, the access-list entries specify rules that “Permit” access to specified networks or hosts. In a “Black-List” ACL mode, the access-list entries specify rules that “Deny” access to specified networks or hosts. A non-conforming access-list , which contains access-list entries with a mixture of “Permit” and “Deny” rules, will be rejected as a configuration error when the administrator tries to add the record. If a conforming access-list is assigned to a DAP record, then any modification to the access-list that changes the conformance characteristic will be rejected as a configuration error.
Figure 16. DAP ACL— Lets you select and configure network ACLs to apply to this DAP record.
When multiple DAP records are selected, the access-lists attributes specified in the Network (Clients) ACL are aggregated to create a Dynamic Access-List for the DAP Firewall ACL. In the same way, the access-lists attributes specified in the Web-Type (Clientless) ACL are aggregated to create a Dynamic Access-List for the DAP Clientless ACL. The example below will focus on how a dynamic DAP Firewall Access-List is created specifically. However, a dynamic DAP Clientless Access-List will follow the same process.
First, the ASA will dynamically create a unique name for the DAP Network-ACL as shown in Table 6.
DAP Network-ACL Name
Table 6. Dynamic DAP Network-ACL Name |
DAP-Network-ACL-X (where X is an integer that will increment to ensure uniqueness) |
Second, the ASA will retrieve the Network-ACL attribute from the selected DAP records as shown in Table 7.
Selected DAP Records
Priority
Network-ACLs
Network-ACL Entries
Table 7. Network ACLs | |||
DAP 1 | 1 | 101 and 102 | ACL 101 has 4 Deny Rules and ACL 102 has 4 Permit Rules |
DAP 2 | 2 | 201 and 202 | ACL 201 has 3 Permit Rules and ACL 202 has 3 Deny Rules |
DAP 3 | 2 | 101 and 102 | ACL 101 has 4 Deny Rules and ACL 102 has 4 Permit Rules |
Third, the ASA will reorder the Network-ACLs first by the DAP record Priority number, and then by Black-List first if the Priority value for 2 or more selected DAP records are the same. Following this, the ASA will then retrieve the Network-ACL entries from each Network-ACL as shown in Table 8.
Network-ACLs
Priority
White/Black Access-List Model
Network-ACL Entries
Table 8. DAP Record Priority | |||
101 | 2 | Black-List | 4 Deny Rules (DDDD) |
202 | 2 | Black-List | 3 Deny Rules (DDD) |
102 | 2 | White-List | 4 Permit Rules (PPPP) |
202 | 2 | White-List | 3 Permit Rules (PPP) |
101 | 1 | Black-List | 4 Deny Rules (DDDD) |
102 | 1 | White-List | 4 Permit Rules (PPPP) |
Lastly, the ASA will merge the Network-ACL entries into the dynamically generated Network-ACL and then return the name of the dynamic Network-ACL as the new Network-ACL to be enforced as shown in Table 9.
DAP Network-ACL Name
Network-ACL Entry
Table 9. Dynamic DAP Network-ACL | |
DAP-Network-ACL-1 | DDDD DDD PPPP PPP DDDD PPPP |
See another use case DAP ACL Aggregation for Clientless SSL VPN for full details.
DAP Implementation
There are a host of reasons why an administrator should consider implementing DAP. Some underlying reasons are when posture assessment on an endpoint is to be enforced, and/or when more granular AAA or policy attributes are to be considered when authorizing user access to network resources. In the example below, we will configure DAP and its components to identify a connecting endpoint and authorize user access to various network resources.
Test Case – A customer has requested a Proof-of-Concept with the following VPN Access requirements:
In this example, we will execute a series of configuration steps in an effort to meet the customer’s VPN access requirements. There will be configuration steps that are necessary but not directly related to DAP while other configurations will be directly related to DAP. The ASA is very dynamic and can adapt in many network environments. As a result, VPN solutions can be defined in various ways and in some cases provide the same end solution. The approach taken however is driven by customers’ needs and their environments.
Based on the nature of this paper and the customer’s requirements defined, we will use Adaptive Security Device Manager (ASDM) 6.0(x) and focus most of our configurations around DAP. However, we will also configure local Group Policies to show how DAP can complement and/or override local policy attributes. For the basis of this test case, we will assume an LDAP Server Group, Split Tunneling Network List and basic IP connectivity, including IP Pools and the DefaultDNS Server Group, are preconfigured.
Defining a Group Policy— this configuration is necessary for defining Local Policy Attributes. Some attributes defined here are not configurable in DAP for (example, Local LAN Access). (This Policy will also be used to define Clientless and Client based attributes).
Navigate to Configuration > Remote Access VPN > Network (Client) Access > Group Policies, and Add an Internal Group Policy by doing the following:
Figure 17. Group Policy —Defines Local VPN Specific Attributes.
Defining a Connection Profile—this configuration is necessary for defining our AAA authentication method, for example LDAP and applying the previously configured Group Policy (SSLVPN_GP) to this Connection Profile. Users connecting via this Connection Profile will be subjected to the attributes defined here as well as attributes defined in the SSLVPN_GP Group Policy. (This Profile will also be used to define both Clientless and Client based attributes).
Navigate to Configuration > Remote Access VPN > Network (Client) Access >SSL VPN Connection Profiles and configure the following:
Figure 20. Connection Profile —Defines Local VPN Specific Attributes.
Defining an IP interface for SSL VPN connectivity—This configuration is necessary for terminating Client and Clientless SSL connections on a specified interface.
Prior to enabling Client/Network access on an interface, you must first define an SSL VPN Client image.
Defining Bookmark Lists (URL Lists) for Clientless Access—This configuration is necessary for defining a web based application to be published on the Portal. We will define 2 URL Lists, one for Employees and the other for Contractors.
Cisco Secure Desktop —this configuration is necessary for defining Endpoint Assessment attributes. Based on the criteria to be satisfied, connecting endpoints will be classified as Managed or Unmanaged. Cisco Secure Desktop assessments are executed prior to the authentication process.
Configuring Cisco Secure Desktop and a Pre Login Decision Tree for Windows Locations:
Advanced Endpoint Assessment—This configuration is necessary for enforcing AntiVirus, AntiSpyware and Personal Firewall on an Endpoint. For example, this assessment will verify if McAfee is running on the connecting endpoint. (Advanced endpoint Assessment is a licensed feature and is not configurable if the Cisco Secure Desktop feature is disabled).
Navigate to Configuration > Remote Access VPN > Secure Desktop Manager > Host Scan, and configure the following under the Host Scan Extensions section:
Figure 29. AntiVirus Enforcement—Customized for Client/Network based access.
Under the Host Scan Extensions section, configure the following:
Dynamic Access Policies—This configuration is necessary for validating connecting users and their endpoints against defined AAA and/or endpoint assessment criteria. If the defined criteria of a DAP record are satisfied, connecting users will then be granted access to network resources that are associated with that DAP record or records. DAP authorization is executed during the authentication process.
To ensure that an SSL VPN connection will terminate in the default case, e.g. when the endpoint does not match any configured Dynamic Access policies), we will configure the following:
Note: When configuring Dynamic Access Policies for the first time, a DAP.xml error message is displayed indicating that a DAP configuration file (DAP.XML) does not exist. Once your initial DAP configuration is modified and then saved, this message will no longer appear.
Figure 37. DAP Endpoint Attribute—Cisco Secure Desktop Location will be used as a DAP criteria for Clientless access.
DAP Selection Criteria—Based on that DAP configuration procedures above, your Selection Criteria for the 4 DAP policies defined, should be consistent with Figures 43, 44, 45 and 46.
Figure 43. Managed Endpoints—If the Criteria of this DAP record are satisfied, Employees will have access to corporate resources via a client/network (AnyConnect Client) connection.
Figure 44. Unmanaged Endpoints—If the Criteria of this DAP record is satisfied, employees will have access to corporate resources via a clientless (portal) connection. A URL list for employees is also applied to this policy.
Figure 45. Guest Access—If the criteria of this DAP record are satisfied, contractors will have access to corporate resources via a clientless (portal) connection. A URL list for contractors is also applied to this policy.
Figure 46. Default DAP Policy—If the criteria for all DAP records above are not satisfied, employees and contractors will, by default, be denied access.
Conclusion
Based on the customer’s Remote Access SSL VPN requirements noted in this example, this solution will satisfy their Remote Access VPN requirements.
With evolving and dynamic VPN environments on the merge, Dynamic Access Policies can adapt and scale to frequent internet configuration changes, various roles each user may inhabit within an organization, and logins from managed and unmanaged remote access sites with different configurations and levels of security.
Dynamic Access Policies are complemented by new and proven legacy technologies including, Advanced Endpoint Assessment, Host Scan, Secure Desktop, AAA and Local Access Policies. As a result, organizations can confidently deliver secure VPN access to any network resource from any location.
Why are most of .gifs not displaying anymore? Can we fix this please.
Thx,
nelson
What´s the differenz
between = and !=
= -> must be in?
!= the one and only attribute?
I have a question about network acl filtering:
if I filter traffic in a dap, which permits, and I have an acl applied to the outside interface, which denies,
the final action is deny, is it right?
Much appreciated if someone can tell me which attribute should be used to exempt users from Always-On VPN Cisco Anyconnect with Cisco ISE as Radius in ASA
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: