SegmentationPolicy SetsCisco ISE is a policy-based, network-access-control solution, which offers network access policy sets, allowing you to manage several different network access use cases such as wireless, wired, guest, and client provisioning. Policy sets (both network access and device administration sets) enable you to logically group authentication and authorization policies within the same set. You can have several policy sets based on an area, such as policy sets based on location, access type and similar parameters. When you install ISE, there is always one policy set defined, which is the default policy set, and the default policy set contains within it, predefined and default authentication, authorization and exception policy rules. Show
When creating policy sets, you can configure these rules (configured with conditions and results) in order to choose the network access services on the policy set level, the identity sources on the authentication policy level, and network permissions on the authorization policy levels. You can define one or more conditions using any of the attributes from the Cisco ISE-supported dictionaries for different vendors. Cisco ISE allows you to create conditions as individual policy elements that can be reused. The network access service to be used per policy set to communicate with the network devices is defined at the top level of that policy set. Network access services include:
Policy sets are configured hierarchically, where the rule on the top level of the policy set, which can be viewed from the Policy Set table, applies to the entire set and is matched before the rules for the rest of the policies and exceptions. Thereafter, rules of the set are applied in this order:
Policy Set Configuration SettingsThe following table describes the fields in the Policy Sets window, from which you can configure policy sets, including authentication, exception and authorization policies. In the Cisco ISE GUI, click the Menu icon () and choose for network access policies.In the Cisco ISE GUI, click the Menu icon () and choose for device administration policies. Table 1. Policy Set Configuration Settings
Authentication PoliciesEach policy set can contain multiple authentication rules that together represent the authentication policy for that set. Priority of the authentication policies is determined based on the order to those policies as they appear within the policy set itself (from the Set view page in the Authentication Policy area). Cisco ISE dynamically chooses the network access service (either an allowed protocol a server sequence) based on the settings configured on the policy set level, and thereafter checks the identity sources and results from the authentication and authorization policy levels. You can define one or more conditions using any of the attributes from the Cisco ISE dictionary. Cisco ISE allows you to create conditions as individual policy elements that can be stored in the Library and then can be reused for other rule-based policies. The identity method, which is the result of the authentication policy, can be any one of the following:
The default policy set implemented at initial Cisco ISE installation includes the default ISE authentication and authorization rules. The default policy set also includes additional flexible built-in rules (that are not defaults) for authentication and authorization. You can add additional rules to those policies and you can delete and change the built-in rules but you cannot remove the default rules and you cannot remove the default policy set. Authentication Policy FlowIn authentication policies, you can define multiple rules, which consist of conditions and results. ISE evaluates the conditions that you have specified and based on the result of the evaluation, assigns the corresponding results. The identity database is selected based on the first rule that matches the criteria. You can also define an identity source sequence consisting of different databases. You can define the order in which you want Cisco ISE to look up these databases. Cisco ISE will access these databases in sequence until the authentication succeeds. If there are multiple instances of the same user in an external database, the authentication fails. There can only be one user record in an identity source. We recommend that you use only three, or at most four databases in an identity source sequence. Figure 1. Authentication Policy FlowAuthentication Failures—Policy Result OptionsIf you choose the identity method as deny access, a reject message is sent as a response to the request. If you choose an identity database or an identity source sequence and the authentication succeeds, the processing continues to the authorization policy configured for the same policy set. Some of the authentications fail and these are classified as follows:
Cisco ISE allows you to configure any one of the following courses of action for authentication failures:
Even when you choose the Continue option, there might be instances where Cisco ISE cannot continue processing the request due to restrictions on the protocol that is being used. For authentications using PEAP, LEAP, EAP-FAST, EAP-TLS, or RADIUS MSCHAP, it is not possible to continue processing the request when authentication fails or user is not found. When authentication fails, it is possible to continue to process the authorization policy for PAP/ASCII and MAC authentication bypass (MAB or host lookup). For all other authentication protocols, when authentication fails, the following happens:
Configure Authentication PoliciesDefine an authentication policy per policy set by configuring and maintaining multiple authentication rules, as necessary. Before you beginTo perform the following task, you must be a Super Admin or Policy Admin. Optionally, if you do not want to use the available system default, ensure you have configured any external identity stores if necessary. For more information, see the Internal and External Identity Sources section in Cisco ISE Admin Guide: Asset Visibility . Procedure
What to do next
Authentication Policy Configuration SettingsThe following table describes the fields in the Authentication Policy section of the Policy Sets window, from which you can configure authentication subpolicies as part of your policy sets.In the Cisco ISE GUI, click the Menu icon () and choose for network access policies. In the Cisco ISE GUI, click the Menu icon () and choose for device administration policies. In the Cisco ISE GUI, click the Menu icon () and choose Table 2. Authentication Policy Configuration Settings
Password-Based AuthenticationAuthentication verifies user information to confirm user identity. Traditional authentication uses a name and a fixed password. This is the most popular, simplest, and least-expensive method of authentication. The disadvantage is that this information can be told to someone else, guessed, or captured. An approach that uses simple, unencrypted usernames and passwords is not considered a strong authentication mechanism, but it can be sufficient for low-authorization or low-privilege levels such as Internet access. Secure Authentication Using Encrypted Passwords and Cryptographic TechniquesYou should use encryption to reduce the risk of password capture on the network. Client and server access control protocols, such as RADIUS, encrypt passwords to prevent them from being captured within a network. However, RADIUS operates only between the authentication, authorization, and accounting (AAA) client and Cisco ISE. Before this point in the authentication process, unauthorized persons can obtain cleartext passwords such as in the following examples:
More-secure methods use cryptographic techniques, such as those used inside the Challenge Authentication Handshake Protocol (CHAP), one-time password (OTP), and advanced EAP-based protocols. Cisco ISE supports a variety of these authentication methods. Authentication Methods and Authorization PrivilegesA fundamental implicit relationship exists between authentication and authorization. The more authorization privileges that are granted to a user, the stronger the authentication should be. Cisco ISE supports this relationship by providing various methods of authentication. Authentication DashletThe Cisco ISE dashboard provides a summary of all authentications that take place in your network and for your devices. It provides at-a-glance information about authentications and authentication failures in the Authentications dashlet. The RADIUS Authentications dashlet provides the following statistical information about the authentications that Cisco ISE has handled:
You can also view a summary of TACACS+ authentications. The TACACS+ Authentications dashlet provides statistical information for device authentications. For more information about device administration authentications, see the TACACS Live Logs section in Cisco ISE Admin Guide: Troubleshooting . For additional information about RADIUS Live Logs settings, see the RADIUS Live Logs section in Cisco ISE Admin Guide: Troubleshooting .
View Authentication ResultsCisco ISE provides various ways to view real-time authentication summary. Before you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
Authentication Reports and Troubleshooting ToolsApart from the authentication details, Cisco ISE provides various reports and troubleshooting tools that you can use to efficiently manage your network. There are various reports that you can run to understand the authentication trend and traffic in your network. You can generate reports for historical as well as current data. The following is a list of authentication reports:
Authorization PoliciesAuthorization policies are a component of the Cisco ISE network authorization service. This service allows you to define authorization policies and configure authorization profiles for specific users and groups that access your network resources. Authorization policies can contain conditional requirements that combine one or more identity groups using a compound condition that includes authorization checks that can return one or more authorization profiles. In addition, conditional requirements can exist apart from the use of a specific identity group. Authorization profiles are used when creating authorization policies in Cisco ISE. An authorization policy is composed of authorization rules. Authorization rules have three elements: name, attributes, and permissions. The permission element maps to an authorization profile. Cisco ISE Authorization ProfilesAuthorization policies associate rules with specific user and group identities to create the corresponding profiles. Whenever these rules match the configured attributes, the corresponding authorization profile that grants permission is returned by the policy and network access is authorized accordingly. For example, authorization profiles can include a range of permissions that are contained in the following types:
Profiles consist of attributes chosen from a set of resources, which are stored in any of the available vendor dictionaries, and these are returned when the condition for the specific authorization policy matches. Because authorization policies can include condition mapping to a single network service rule, these can also include a list of authorization checks. authorization verifications must comply with the authorization profiles to be returned. Authorization verifications typically comprise one or more conditions, including a user-defined name that can be added to a library, which can then be reused by other authorization policies. Permissions for Authorization ProfilesBefore you start configuring permissions for authorization profiles, make sure you:
In the Cisco ISE GUI, click the Menu icon () and choose to work with authorization profiles. From the menu on the left, choose . Use the Results navigation pane as your starting point in the process for displaying, creating, modifying, deleting, duplicating, or searching policy element permissions for the different types of authorization profiles on your network. The Results pane initially displays Authentication, Authorization, Profiling, Posture, Client Provisioning, and Trustsec options. Authorization profiles let you choose the attributes to be returned when a RADIUS request is accepted. Cisco ISE provides a mechanism where you can configure Common Tasks Settings to support commonly used attributes. You must enter the value for Common Tasks Attributes, which Cisco ISE translates to the underlying RADIUS values.
Location Based AuthorizationCisco ISE integrates with Cisco Mobility Services Engine (MSE) to introduce physical location-based authorization. Cisco ISE uses information from MSE to provide differentiated network access based on the actual location of the user, as reported by MSE. With this feature, you can use the endpoint location information to provide network access when a user is in an appropriate zone. You can also add the endpoint location as an additional attribute for policies to define more granulated policy authorization sets based on device location. You can configure conditions within authorization rules that use location-based attributes, for example: MSE.Location Equals LND_Campus1:Building1:Floor2:SecureZone You can define the location hierarchy (campus/building/floor structure) and configure the secure and non-secure zones using the Cisco Prime Infrastructure application. After defining the location hierarchy, you must synchronize the location hierarchy data with the MSE servers. For more information on Cisco Prime Infrastructure, see: http://www.cisco.com/c/en/us/support/cloud-systems-management/prime-infrastructure/products-user-guide-list.html. You can add one or multiple MSE instances to integrate MSE-based location data to the authorization process. You can retrieve the location hierarchy data from these MSEs and configure location-based authorization rules using this data. To track the endpoint movement, check the Track Movement check box while creating an authorization profile. Cisco ISE will query the relevant MSE for the endpoint location every 5 minutes to verify if the location was changed.
Add an MSE serverTo perform the following task, you must be a Super Admin or System Admin.
Location TreeThe Location Tree is created by using the location data retrieved from the MSE instances. In the Cisco ISE GUI, click the Menu icon () and choose Administration > Network Resources > Location Services > Location Tree. If one building has multiple MSEs, Cisco ISE will collate the location details from all the MSEs and present them as a single tree. You can select the location entries that are exposed to the authorization policy by using the Location Tree. You can also hide specific locations based on your requirements. It is recommended to update the Location Tree before hiding locations. Hidden locations will remain hidden even when the tree is updated. If the location entries related to an authorization rule are modified or removed, you must disable the affected rules and set these locations as Unknown or select a replacement location for each affected rule. You must verify the new tree structure before applying the change or canceling the update. Click Get Update to get the latest location hierarchy structure from all MSEs. After verifying the new tree structure, click Save to apply your changes. Downloadable ACLsAccess control lists (ACLs) are lists of access control entries (ACEs), which may be applied by a Policy Enforcement Point (for example, a switch) to a resource. Each ACE identifies the permissions allowed per user for that object, such as read, write, execute and more. For example, an ACL may be configured for use the Sales area of the network, with an ACE allowing Write permissions for the Sales group and a separate ACE allowing Read permissions for all other employees of the organization. With RADIUS protocol, ACLs grant authorization by filtering source and destination IP addresses, transport protocols, and additional parameters. Static ACLs reside on and are directly configured from the switch and can be applied in your authorization policies from the ISE GUI; downloadable ACLs (DACLs) can be configured, managed and applied in your authorization policies from the ISE GUI. To implement DACLs in your network authorization policy in ISE:
Configure Permissions for Downloadable ACLsWith ISE, downloadable ACLs (DACLs) can be configured and implemented in your authorization policies for control of how the network is accessed by different users and groups of users. Default authorization DACLs are available with installation of ISE, including the following default profiles:
When working with DACLs, these defaults cannot be changed, but you can duplicate them in order to create additional, similar, DACLs. Once you've configured the DACLs that you need, you can then apply those DACLs to relevant Authorization policies on your network. Once you've applied a DACL to an authorization policy, you can no longer change its type, or delete it from ISE. In order to change the DACL type once it has already been used in a policy, you can create a duplicate DACL and then update the duplicate, or you can alternatively remove the DACL from your policies in order to update it and then reapply when relevant.
Machine Access Restriction for Active Directory User AuthorizationCisco ISE contains a Machine Access Restriction (MAR) component that provides an additional means of controlling authorization for Microsoft Active Directory-authentication users. This form of authorization is based on the machine authentication of the computer used to access the Cisco ISE network. For every successful machine authentication, Cisco ISE caches the value that was received in the RADIUS Calling-Station-ID attribute (attribute 31) as evidence of a successful machine authentication. Cisco ISE retains each Calling-Station-ID attribute value in cache until the number of hours that was configured in the “Time to Live” parameter in the Active Directory Settings page expires. Once the parameter has expired, Cisco ISE deletes it from its cache. When a user authenticates from an end-user client, Cisco ISE searches the cache for a Calling-Station-ID value from successful machine authentications for the Calling-Station-ID value that was received in the user authentication request. If Cisco ISE finds a matching user-authentication Calling-Station-ID value in the cache, this affects how Cisco ISE assigns permissions for the user that requests authentication in the following ways:
Guidelines for Configuring Authorization Policies and ProfilesObserve the following guidelines when managing or administering authorization polices and profiles:
Configure Authorization PoliciesAfter creating attributes and building blocks for authorization policies from the Policy menu, create authorization policies within policy sets from the Policy Sets menu. Before you beginBefore you begin this procedure, you should have a basic understanding of the different building blocks used to create authorization policies such as identify groups and conditions. Procedure
Authorization Policy SettingsThe following table describes the fields in the Authorization Policy section of the Policy Sets window, from which you can configure authorization policies as part of your policy sets. In the Cisco ISE GUI, click the Menu icon () and choose for network access policies. In the Cisco ISE GUI, click the Menu icon () and choose for device administration policies. Table 3. Authorization Policy Configuration Settings
Create Authorization Policies with Endpoint-Analytics AttributesCisco AI Endpoint Analytics is a Cisco DNA Center feature that enables nuanced visibility and profiling of endpoints, based on Hardware Manufacturer, Hardware Model, Operating System, and Endpoint Type attributes. Cisco AI Endpoint Analytics receives endpoint attribute data from multiple sources, such as Cisco Catalyst 9000 Series devices, CMBD connections, telemetry devices, and more. Cisco AI Endpoint Analytics publishes these endpoint attributes to Cisco ISE, and a Cisco ISE administrator can then create specific authorization rules using these values. See Cisco AI Endpoint Analytics. In Cisco ISE Release 3.0 and earlier releases, Cisco ISE received attribute information from Cisco AI Endpoint Analytics through pxGrid, through an IoTAsset topic. You could then create a custom profiler policy using the Cisco AI Endpoint Analytics attribute, and then use the profiler policy in an authorization policy. From Cisco ISE Release 3.1, Cisco AI Endpoint Analytics attributes are easily accessible in the Endpoint-Analytics dictionary and you can directly use these attributes in your authorization policies. The related topic subscriptions are added to the primary PAN, and all the active PSNs in the deployment. Each PSN only receives attribute information for the endpoints that are connected to it to help optimize overall Cisco ISE performance. Figure 2. Endpoint-Analytics Dictionary AttributesThe attributes that are part of the Endpoint-Analytics dictionary:
Before you begin
Procedure
What to do nextTo receive debug logs to troubleshoot pxGrid issues related to Endpoints Analytics:
Authorization Profile SettingsIn the Cisco ISE GUI, click the Menu icon () and choose , the Authorization Profiles window define attributes for network access. Authorization Profile Settings
Common TasksCommon tasks are specific permissions and actions that apply to network access.
Advanced Attributes Settings
Authorization Policy ExceptionsWithin each policy set, you can define regular authorization policies, as well as local exception rules (defined from the Authorization Policy Local Exceptions part in the Set view for each policy set) and global exception rules (defined from the Authorization Policy Global Exceptions part in the Set view for each policy set) . Global authorization exception policies enable you to define rules that override all authorization rules in all of your policy sets. Once you configure a global authorization exception policy, it is added to to all policy sets. Global authorization exception policies can then be updated from within any of the currently configured policy sets. Every time you update a global authorization exception policy, those updates are applied to all policy sets. The local authorization exception rule overwrites the global exception rule. The authorization rules are processed in the following order: first the local exception rule, then the global exception rule, and finally, the regular rule of the authorization policy. Authorization exception policy rules are configured identically to authorization policy rules. For information about authorization policies, see Configure Authorization Policies.
Local and Global Exceptions Configuration SettingsIn the Cisco ISE GUI, click the Menu icon () and choose for network access policies. In the Cisco ISE GUI, click the Menu icon () and choose for device administration policies. In the Cisco ISE GUI, click the Menu icon () and choose or Global Exceptions Policy. Authorization exception settings are identical to the Authorization policy settings and are as described in Authorization Policy Settings. Policy ConditionsCisco ISE uses rule-based policies to provide network access. A policy is a set of rules and results, where the rules are made up of conditions. Cisco ISE allows you to create conditions as individual policy elements that can be stored in the system library and then reused for other rule-based policies from the Conditions Studio. Conditions can be as simple or complex as necessary using an operator (equal to, not equal to, greater than, and so on), and a value, or by including multiple attributes, operators and complex hierarchies. At runtime, Cisco ISE evaluates a policy condition and then applies the result that you have defined based on whether the policy evaluation returns a true or a false value. After you create a condition and assign it a unique name, you can reuse this condition multiple times across various rules and policies by selecting it from the Conditions Studio Library, for example: You cannot delete conditions from the Condition Studio that are used in a policy or are part of another condition. Each condition defines a list of objects that can be included in policy conditions, resulting in a set of definitions that are matched against those presented in the request. You can use the operator, Cisco ISE also offers predefined smart conditions that you can use in your policies separately or as building blocks in your own customized conditions, and which you can update and change based on your needs. You can create the following unique network conditions to restrict access to the network:
For more information about these unique conditions, see Special Network Access Conditions. Dictionaries and Dictionary AttributesDictionaries are domain-specific catalogs of attributes and allowed values that can be used to define access policies for a domain. An individual dictionary is a homogeneous collection of attribute type. Attributes that are defined in a dictionary have the same attribute type and the type indicates the source or context of a given attribute. Attribute types can be one of the following:
In addition to attributes and allowed values, a dictionary contains information about the attributes such as the name and description, data type, and the default values. An attribute can have one of the following data types: BOOLEAN, FLOAT, INTEGER, IPv4, IPv6, OCTET_STRING, STRING, UNIT32, and UNIT64. Cisco ISE creates system dictionaries during installation and allows you to create user dictionaries. Attributes are stored in different system dictionaries. Attributes are used to configure conditions. Attributes can be reused in multiple conditions. To reuse a valid attribute when creating policy conditions, select it from a dictionary that contains the supported attributes. For example, Cisco ISE provides an attribute named AuthenticationIdentityStore, which is located in the NetworkAccess dictionary. This attribute identifies the last identity source that was accessed during the authentication of a user:
You can use the AuthenticationStatus attribute in combination with the AuthenticationIdentityStore attribute to define a condition that identifies the identity source to which a user has successfully been authenticated. For example, to check for a condition where a user authenticated using an LDAP directory (LDAP13) in the authorization policy, you can define the following reusable condition:
To define conditions that are based on an endpoint identity group that has been previously authenticated, Cisco ISE supports authorization that was defined during endpoint identity group 802.1X authentication status. When Cisco ISE performs 802.1X authentication, it extracts the MAC address from the “Calling-Station-ID” field in the RADIUS request and uses this value to look up and populate the session cache for the device's endpoint identity group (defined as an endpointIDgroup attribute). This process makes the endpointIDgroup attribute available for use in creating authorization policy conditions, and allows you to define an authorization policy based on endpoint identity group information using this attribute, in addition to user information. The condition for the endpoint identity group can be defined in the ID Groups column of the authorization policy configuration page. Conditions that are based on user-related information need to be defined in the “Other Conditions” section of the authorization policy. If user information is based on internal user attributes, then use the ID Group attribute in the internal user dictionary. For example, you can enter the full value path in the identity group using a value like “User Identity Group:Employee:US”. Supported Dictionaries for Network Access PoliciesCisco ISE supports the following system-stored dictionaries that contain the different attributes necessary when building conditions and rules for your authentication and authorization policies:
For authorization policy types, the verification configured in the condition must comply with the authorization profiles to be returned. Verifications typically include one or more conditions that include a user-defined name that can then be added to a library and reused by other policies. The following sections describe the supported attributes and dictionaries available for configuring conditions. Attributes Supported by DictionariesThe table lists the fixed attributes that are supported by dictionaries, which can be used in policy conditions. Not all of these attributes are available for creating all types of conditions. For example, while creating a condition to choose the access service in authentication policies, you will only see the following network access attributes: Device IP Address, ISE Host Name, Network Device Name, Protocol, and Use Case. You can use the attributes listed in the following table in policy conditions.
System Defined Dictionaries and Dictionary AttributesCisco ISE creates system dictionaries during installation that you can find in the System Dictionaries page. System-defined dictionary attributes are read-only attributes. Because of their nature, you can only view existing system-defined dictionaries. You cannot create, edit, or delete system-defined values or any attributes in a system dictionary. A system-defined dictionary attribute is displayed with the descriptive name of the attribute, an internal name as understood by the domain, and allowed values. Cisco ISE also creates dictionary defaults for the IETF RADIUS set of attributes that are also a part of the system-defined dictionaries, which are defined by the Internet Engineering Task Force (IETF). You can edit all free IETF RADIUS attribute fields except the ID. Display System Dictionaries and Dictionary AttributesYou cannot create, edit, or delete any system-defined attribute in a system dictionary. You can only view system-defined attributes. You can perform a quick search that is based on a dictionary name and description or an advanced search that is based on a search rule that you define. Procedure
User-Defined Dictionaries and Dictionary AttributesCisco ISE displays the user-defined dictionaries that you create in the User Dictionaries page. You cannot modify the values for Dictionary Name or Dictionary Type for an existing user dictionary once created and saved in the system. You can do the following in the User Dictionaries page:
Create User-Defined DictionariesYou can create, edit, or delete user-defined dictionaries. Procedure
Create User-Defined Dictionary AttributesYou can add, edit, and delete user-defined dictionary attributes in user dictionaries as well as add or remove allowed values for the dictionary attributes. Procedure
RADIUS-Vendor DictionariesCisco ISE allows you to define a set of RADIUS-vendor dictionaries, and define a set of attributes for each one. Each vendor definition in the list contains the vendor name, the vendor ID, and a brief description. Cisco ISE provides you the following RADIUS-vendor dictionaries by default:
The RADIUS protocol supports these vendor dictionaries, and the vendor-specific attributes that can be used in authorization profiles and in policy conditions. Create RADIUS-Vendor DictionariesYou can also create, edit, delete, export, and import RADIUS-vendor dictionaries. Procedure
Create RADIUS-Vendor Dictionary AttributesYou can create, edit, and delete RADIUS vendor attributes that Cisco ISE supports. Each RADIUS-vendor attribute has a name, data type, description, and direction, which specifies whether it is relevant to requests only, responses only, or both. Procedure
HP RADIUS IETF Service Type AttributesCisco ISE introduces two new values for the RADIUS IETF Service Type attribute. The RADIUS IETF service type attribute is available in Policy > Policy Elements > Dictionaries > System > RADIUS > IETFIn the Cisco ISE GUI, click the Menu icon () and choose Policy > Policy Elements > Dictionaries > System > RADIUS > IETF. You can use these two values in policy conditions. These two values are specifically designed for HP devices to understand permissions of the user.
RADIUS Vendor Dictionary Attribute SettingsThis section describes RADIUS vendor dictionaries used in Cisco ISE. The following table describes the fields in the Dictionary window for RADIUS vendors, which allows you to configure dictionary attributes for the RADIUS vendors. In the Cisco ISE GUI, click the Menu icon () and choose. Table 4. RADIUS Vendor Dictionary Attribute Settings
Navigate the Conditions StudioUse the Conditions Studio to create, manage and re-use conditions. Conditions can include more than one rule, and can be built with any complexity including only one level, or multiple hierarchical levels. When using the Conditions Studio to create new conditions, you can use the condition blocks that you have already stored in the Library and you can also update and change those stored condition blocks. While creating and managing conditions later, easily find the blocks and attributes that you need by using quick category filters, and more. In the Cisco ISE GUI, click the Menu icon () and choose for network access policies. In the Cisco ISE GUI, click the Menu icon () and choose for device administration policies. To edit or change conditions that have already been applied to the specific rule in any of your policy sets, hover over the cell in the Conditions column and click , or click the plus sign from the Conditions column in the Policy Set table in order to create a new condition, which you can then immediately apply to the same policy set or alternatively you can also save in the Library for future use.The Condition Studio is divided into two main parts: the Library and the Editor. The Library stores condition blocks for reuse while the Editor enables you to edit those saved blocks and create new ones. The following table describes the different parts of the Conditions Studio:
Configure, Edit and Manage Policy ConditionsWhen creating new conditions, you can use the condition blocks that you have already stored in the Library and you can also update and change those stored condition blocks. While creating and managing conditions, easily find the blocks and attributes that you need by using quick category filters, and more. When creating and managing condition rules, use attributes, operators and values. Cisco ISE also includes predefined condition blocks for some of the most common use cases. You can edit these predefined conditions to suit your requirements. Conditions saved for re-use, including the out-of-the-box blocks, are stored in the Library of the Condition Studio, as described in this task. To perform the following task, you must be a Super Admin or Policy Admin. Procedure
Special Network Access ConditionsThis section describes unique conditions that can be useful when creating your policy sets. These conditions cannot be created from the Conditions Studio and so have their own unique processes. Configure Device Network ConditionsProcedure
Configure Device Port Network ConditionProcedure
Configure Endstation Network ConditionsProcedure
Create Time and Date ConditionsUse the Policy Elements Conditions page to display, create, modify, delete, duplicate, and search time and date policy element conditions. Policy elements are shared objects that define a condition that is based on specific time and date attribute settings that you configure. Time and date conditions let you set or limit permission to access Cisco ISE system resources to specific times and days as directed by the attribute settings you make. Before you beginTo perform the following task, you must be a Super Admin or Policy Admin. Procedure
Use IPv6 Condition Attributes in Authorization PoliciesCisco ISE can detect, manage, and secure IPv6 traffic from endpoints. When an IPv6-enabled endpoint connects to the Cisco ISE network, it communicates with the Network Access Device (NAD) over an IPv6 network. The NAD conveys the accounting and profiling information from the endpoint (including IPv6 values) to Cisco ISE over an IPv4 network. You can configure authorization profiles and policies in Cisco ISE using the IPv6 attributes in your rule conditions to process such requests from IPv6-enabled endpoints and ensure that the endpoint is compliant. You can use wildcard characters in IPv6 prefix and IPv6 interface values. For example: 2001:db8:1234::/48. Supported IPv6 address formats include:
Supported IPv6 attributes include:
The following table lists Supported Cisco Attribute-Value pairs and their equivalent IETF attributes:
The RADIUS Live Logs page, RADIUS Authentication report, RADIUS Accounting report, Current Active Session report, RADIUS Error report, Misconfigured NAS report, Adaptive Network Control Audit, and Misconfigured Supplicant report support IPv6 addresses. You can view the details about these sessions from the RADIUS Live Logs page or from any of these reports. You can filter the records by IPv4, IPv6, or MAC addresses.
The following procedure describes how to configure IPv6 attributes in authorization policies. Before you beginEnsure that the NADs in your deployment support AAA with IPv6. See AAA Support for IPv6 for information on how to enable AAA support for IPv6 on your NADs. Procedure
Policy Set Protocol SettingsYou must define global protocol settings in Cisco ISE before you can use these protocols to create, save and implement a policy set. You can use the Protocol Settings page to define global options for the Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling (EAP-FAST), Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), and Protected Extensible Authentication Protocol (PEAP) protocols, which communicate with the other devices in your network. Supported Network Access Policy Set ProtocolsThe following is a list of protocols that you can choose while defining your Network Access Policy Set policy:
Guidelines for Using EAP-FAST as ProtocolFollow these guidelines when using EAP-FAST as an authentication protocol:
Configure EAP-FAST SettingsBefore you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
Generate the PAC for EAP-FASTYou can use the Generate PAC option in the Cisco ISE to generate a tunnel or machine PAC for the EAP-FAST protocol. Before you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
EAP-FAST SettingsThe following table describes the fields on the Protocol Settings window, which you can use to configure the EAP-FAST, EAP-TLS, and PEAP protocols. To view this window, click the Menu icon () and choose . Table 5. Configuring EAP-FAST Settings
PAC Settings
Using EAP-TTLS as Authentication ProtocolEAP-TTLS is a two-phase protocol that extends the functionality of EAP-TLS protocol. Phase 1 builds the secure tunnel and derives the session keys used in Phase 2 to securely tunnel attributes and inner method data between the server and the client. You can use the attributes tunneled during Phase 2 to perform additional authentications using a number of different mechanisms. Cisco ISE can process authentications from a variety of TTLS supplicants including:
Configure EAP-TTLS SettingsBefore you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
EAP-TTLS SettingsThe following table describes the fields on the EAP-TTLS Settings window. To view this window, click the Menu icon () and choose Administration > System > Settings > Protocols > EAP-TTLS. Table 7. EAP-TTLS Settings
Configure EAP-TLS SettingsBefore you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
EAP-TLS Settings
Configure PEAP SettingsBefore you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
PEAP Settings
Configure RADIUS SettingsYou can configure the RADIUS settings to detect the clients that fail to authenticate and to suppress the repeated reporting of successful authentications. Procedure
RADIUS SettingsThe following table describes the fields on the RADIUS Settings window. To view this window, click the Menu icon () and choose . If you enable the Suppress Repeated Failed Clients option, clients with repeated authentication failures will be suppressed from the audit logs, and the requests from these clients will be automatically rejected for the specified time period. You can also specify the number of authentication failures after which the requests from these clients should be rejected. For example, if this value is configured as 5, when a client authentication fails five times, all the requests received from that client will be rejected for the configured time period.
Configure Security SettingsPerform the following procedure to configure the security settings. Procedure
Supported Cipher SuitesCisco ISE supports TLS versions 1.0, 1.1, and 1.2. Cisco ISE supports RSA and ECDSA server certificates. The following elliptic curves are supported:
The following table lists the supported Cipher Suites:
RADIUS Protocol Support in Cisco ISERADIUS is a client/server protocol through which remote-access servers communicate with a central server to authenticate dial-in users and authorize their access to the requested system or service. You can use RADIUS to maintain user profiles in a central database that all remote servers can share. This protocol provides better security, and you can use it to set up a policy that is applied at a single administered network point. RADIUS also functions as a RADIUS client in Cisco ISE to proxy requests to a remote RADIUS server, and it provides Change of Authorization (CoA) activities during an active session. Cisco ISE supports RADIUS protocol flow according to RFC 2865 and generic support for all general RADIUS attributes as described in RFC 2865 and its extension. Cisco ISE supports parsing of vendor-specific attributes only for vendors that are defined in the Cisco ISE dictionary. RADIUS interface supports the following attribute data types that are defined in RFC 2865:
Allowed ProtocolsThe following table describes the fields in the Allowed Protocols window, which allows you to configure the protocols to be used during authentication. . Table 11. Allowed Protocols
PAC OptionsThe following table describes the fields after you select Use PACs in the Allowed Protocols Services List window. To view this window, click the Menu icon () and choose . Table 12. PAC Options
Cisco ISE Acting as a RADIUS Proxy ServerCisco ISE can function both as a RADIUS server and as a RADIUS proxy server. When it acts as a proxy server, Cisco ISE receives authentication and accounting requests from the network access server (NAS) and forwards them to the external RADIUS server. Cisco ISE accepts the results of the requests and returns them to the NAS. Cisco ISE can simultaneously act as a proxy server to multiple external RADIUS servers. You can use the external RADIUS servers that you configure here in RADIUS server sequences. The External RADIUS Server page lists all the external RADIUS servers that you have defined in Cisco ISE. You can use the filter option to search for specific RADIUS servers based on the name or description, or both. In both simple and rule-based authentication policies, you can use the RADIUS server sequences to proxy the requests to a RADIUS server. The RADIUS server sequence strips the domain name from the RADIUS-Username attribute for RADIUS authentications. This domain stripping is not applicable for EAP authentications, which use the EAP-Identity attribute. The RADIUS proxy server obtains the username from the RADIUS-Username attribute and strips it from the character that you specify when you configure the RADIUS server sequence. For EAP authentications, the RADIUS proxy server obtains the username from the EAP-Identity attribute. EAP authentications that use the RADIUS server sequence will succeed only if the EAP-Identity and RADIUS-Username values are the same. Configure External RADIUS ServersYou must configure the external RADIUS servers in the Cisco ISE to enable it to forward requests to the external RADIUS servers. You can define the timeout period and the number of connection attempts. Before you begin
Procedure
Define RADIUS Server SequencesRADIUS server sequences in Cisco ISE allow you to proxy requests from a NAD to an external RADIUS server that will process the request and return the result to Cisco ISE, which forwards the response to the NAD. RADIUS Server Sequences page lists all the RADIUS server sequences that you have defined in Cisco ISE. You can create, edit, or duplicate RADIUS server sequences from this page. Before you begin
Procedure
Cisco ISE Acting as a TACACS+ Proxy ClientCisco ISE can act as proxy client to external TACACS+ servers. When it acts as a proxy client, Cisco ISE receives authentication, authorization, and accounting requests from the Network Access Server (NAS) and forwards them to the external TACACS+ server. Cisco ISE accepts the results of the requests and returns them to the NAS. The TACACS+ External Servers page lists all the external TACACS+ servers that you have defined in Cisco ISE. You can use the filter option to search for specific TACACS+ servers based on the name or description, or both. Cisco ISE can simultaneously act as a proxy client to multiple external TACACS+ servers. In order to configure multiple external servers, you can use the TACACS+ server sequence page. Refer to the TACACS+ Server Sequence Settings page for more information. Configure External TACACS+ ServersYou must configure the external TACACS servers in the Cisco ISE to enable it to forward requests to the external TACACS servers. You can define the timeout period and the number of connection attempts. Before you begin
Procedure
TACACS+ External Server SettingsThe following table describes the fields in the TACACS External Servers page. In the Cisco ISE GUI, click the Menu icon () and choose page. Table 13. TACACS+ External Server Settings
Define TACACS+ Server SequencesTACACS+ server sequences in Cisco ISE allow you to proxy requests from a NAD to an external TACACS+ server that will process the request and return the result to Cisco ISE, which forwards the response to the NAD. The TACACS+ Server Sequences page lists all the TACACS+ server sequences that you have defined in Cisco ISE. You can create, edit, or duplicate TACACS+ server sequences from this page. Before you begin
Procedure
TACACS+ Server Sequence SettingsThe following table describes the fields in the TACACS Server Sequence page. In the Cisco ISE GUI, click the Menu icon () and choose page. Table 14. TACACS+ Server Sequence Settings
Network Access ServiceA network access service contains the authentication policy conditions for requests. You can create separate network access services for different use cases, for example, Wired 802.1X, Wired MAB, and so on. To create a network access service, configure allowed protocols or server sequences. The network access service for network access policies is then configured from the Policy Sets page. Define Allowed Protocols for Network AccessAllowed protocols define the set of protocols that Cisco ISE can use to communicate with the device that requests access to the network resources. An allowed protocols access service is an independent entity that you should create before you configure authentication policies. Allowed protocols access service is an object that contains your chosen protocols for a particular use case. The Allowed Protocols Services page lists all the allowed protocols services that you create. There is a default network access service that is predefined in the Cisco ISE. Before you beginBefore you begin this procedure, you should have a basic understanding of the protocol services that are used for authentication.
To perform the following task, you must be a Super Admin or System Admin. Procedure
Network Access for UsersFor network access, a host connects to the network device and requests to use network resources. The network device identifies the newly connected host, and, using the RADIUS protocol as a transport mechanism, requests Cisco ISE to authenticate and authorize the user. Cisco ISE supports network access flows depending on the protocol that is transported over the RADIUS protocol. RADIUS-Based Protocols Without EAPRADIUS-based protocols that do not include EAP include the following:
RADIUS-Based Non-EAP Authentication FlowThis section describes RADIUS-based flow without EAP authentication. RADIUS-based flow with PAP authentication occurs in the following process:
The following figure shows a RADIUS-based authentication without EAP. Figure 7. RADIUS-Based Authentication Without EAP The non-EAP protocols supported by Cisco ISE are:PAP provides a simple method for users to establish their identity by using a two-way handshake. The PAP password is encrypted with a shared secret and is the least sophisticated authentication protocol. PAP is not a strong authentication method because it offers little protection from repeated trial-and-error attacks. Cisco ISE checks the username and password pair against the identity stores, until it eventually acknowledges the authentication or terminates the connection. You can use different levels of security concurrently with Cisco ISE for different requirements. PAP applies a two-way handshaking procedure. If authentication succeeds, Cisco ISE returns an acknowledgment; otherwise, Cisco ISE terminates the connection or gives the originator another chance. The originator is in total control of the frequency and timing of the attempts. Therefore, any server that can use a stronger authentication method will offer to negotiate that method prior to PAP. RFC 1334 defines PAP. Cisco ISE supports standard RADIUS PAP authentication that is based on the RADIUS UserPassword attribute. RADIUS PAP authentication is compatible with all identity stores. The RADIUS-with-PAP-authentication flow includes logging of passed and failed attempts. CHAP uses a challenge-response mechanism with one-way encryption on the response. CHAP enables Cisco ISE to negotiate downward from the most-secure to the least-secure encryption mechanism, and it protects passwords that are transmitted in the process. CHAP passwords are reusable. If you are using the Cisco ISE internal database for authentication, you can use PAP or CHAP. CHAP does not work with the Microsoft user database. Compared to RADIUS PAP, CHAP allows a higher level of security for encrypting passwords when communicating from an end-user client to the AAA client. Cisco ISE supports standard RADIUS CHAP authentication that is based on the RADIUS ChapPassword attribute. Cisco ISE supports RADIUS CHAP authentication only with internal identity stores.
RADIUS-Based EAP ProtocolsEAP provides an extensible framework that supports various authentication types. This section describes the EAP methods supported by Cisco ISE and contains the following topics:
Apart from the methods listed above, there are EAP methods that use certificates for both server and client authentication. RADIUS-Based EAP Authentication FlowWhenever EAP is involved in the authentication process, the process is preceded by an EAP negotiation phase to determine which specific EAP method (and inner method, if applicable) should be used. EAP-based authentication occurs in the following process:
In this way, the host and Cisco ISE indirectly exchange EAP messages (transported over RADIUS and passed through the network device). The initial set of EAP messages that are exchanged in this manner negotiate the specific EAP method that will subsequently be used to perform the authentication. The EAP messages that are subsequently exchanged are then used to carry the data that is needed to perform the actual authentication. If it is required by the specific EAP authentication method that is negotiated, Cisco ISE uses an identity store to validate user credentials. After Cisco ISE determines whether the authentication should pass or fail, it sends either an EAP-Success or EAP-Failure message, encapsulated into a RADIUS Access-Accept or Access-Reject message to the network device (and ultimately also to the host). The following figure shows a RADIUS-based authentication with EAP. Figure 8. RADIUS-Based Authentication with EAPExtensible Authentication Protocol-Message Digest 5 (EAP-MD5) provides one-way client authentication. The server sends the client a random challenge. The client proves its identity in a response by encrypting the challenge and its password with MD5. Because a man in the middle could see the challenge and response, EAP-MD5 is vulnerable to dictionary attack when used over an open medium. Because no server authentication occurs, it is also vulnerable to spoofing. Cisco ISE supports EAP-MD5 authentication against the Cisco ISE internal identity store. Host Lookup is also supported when using the EAP-MD5 protocol. Cisco ISE currently uses Lightweight Extensible Authentication Protocol (LEAP) only for Cisco Aironet wireless networking. If you do not enable this option, Cisco Aironet end-user clients who are configured to perform LEAP authentication cannot access the network. If all Cisco Aironet end-user clients use a different authentication protocol, such as Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), we recommend that you disable this option.
Protected Extensible Authentication Protocol (PEAP) provides mutual authentication, ensures confidentiality and integrity to vulnerable user credentials, protects itself against passive (eavesdropping) and active (man-in-the-middle) attacks, and securely generates cryptographic keying material. PEAP is compatible with the IEEE 802.1X standard and RADIUS protocol. Cisco ISE supports PEAP version 0 (PEAPv0) and PEAP version 1 (PEAPv1) with Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol (EAP-MS-CHAP), Extensible Authentication Protocol-Generic Token Card (EAP-GTC), and EAP-TLS inner methods. The Cisco Secure Services Client (SSC) supplicant supports all of the PEAPv1 inner methods that Cisco ISE supports.
Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling (EAP-FAST) is an authentication protocol that provides mutual authentication and uses a shared secret to establish a tunnel. The tunnel is used to protect weak authentication methods that are based on passwords. The shared secret, referred to as a Protected Access Credentials (PAC) key, is used to mutually authenticate the client and server while securing the tunnel.
Enable MAB from Non-Cisco DevicesConfigure the following settings sequentially to configure MAB from non-Cisco devices. Procedure
Enable MAB from Cisco DevicesConfigure the following settings sequentially to configure MAB from Cisco devices. Procedure
TrustSec ArchitectureThe Cisco TrustSec solution establishes clouds of trusted network devices to build secure networks. Each device in the Cisco TrustSec cloud is authenticated by its neighbors (peers). Communication between the devices in the TrustSec cloud is secured with a combination of encryption, message integrity checks, and data-path replay protection mechanisms. The TrustSec solution uses the device and user identity information that it obtains during authentication to classify, or color, the packets as they enter the network. This packet classification is maintained by tagging packets when they enter the TrustSec network so that they can be properly identified for the purpose of applying security and other policy criteria along the data path. The tag, also called the security group tag (SGT), allows Cisco ISE to enforce access control policies by enabling the endpoint device to act upon the SGT to filter traffic. The following figure shows an example of a TrustSec network cloud. Figure 9. TrustSec Architecture
TrustSec ComponentsThe key TrustSec components include:
TrustSec TerminologyThe following table lists some of the common terms that are used in the TrustSec solution and their meaning in an TrustSec environment. Table 15. TrustSec Terminology
Supported Switches and Required Components for TrustSecTo set up a Cisco ISE network that is enabled with the Cisco TrustSec solution, you need switches that support the TrustSec solution and other components. Apart from the switches, you also need other components for identity-based user access control using the IEEE 802.1X protocol. For a complete up-to-date list of the Trustsec-supported Cisco switch platforms and the required components, see Cisco TrustSec-Enabled Infrastructure. Integration with Cisco DNA CenterCisco DNA Center provides a mechanism to create a trusted communications link with Cisco ISE and to share data with Cisco ISE in a secure manner. After Cisco ISE is registered with Cisco DNA Center, any device that Cisco DNA Center discovers, along with relevant configuration and other data, is pushed to Cisco ISE. You can use Cisco DNA Center to discover devices and then apply both Cisco DNA Center and Cisco ISE functions to them because these devices will be displayed in both the applications. Cisco DNA Center and Cisco ISE devices are all uniquely identified by their device names. Connecting Cisco DNA Center to Cisco ISEFor information about configuring Cisco DNA Center for Cisco ISE, see the Cisco DNA Center Installation Guide. This section provides additional information about the Cisco ISE configuration for Cisco DNA Center.
TrustSec DashboardThe TrustSec dashboard is a centralized monitoring tool for the TrustSec network. The TrustSec dashboard contains the following dashlets:
MetricsThis section displays statistics about the behavior of the TrustSec network. You can select the time frame (for example, past 2 hours, past 2 days, and so on) and the chart type (for example, bars, line, spline). The latest bar values are displayed on the graphs. It also displays the percentage change from the previous bar. If there is an increase in the bar value, it will be displayed in green with a plus sign. If there is a decrease in the value, it will be displayed in red with a minus sign. Place your cursor on a bar of a graph to view the time at which the value was calculated and its exact value in the following format: <Value:xxxx Date/Time: xxx> You can view the following metrics:
Current Network StatusThe middle section of the dashboard displays information about the current status of the TrustSec network. The values displayed in the graphs are updated when the page is loaded and can be refreshed by using the Refresh Dashboard option. Active SGT SessionsThis dashlet displays the SGT sessions that are currently active in the network. You can view the top 10 most used or least used SGTs. The X-axis shows the SGT usage and the Y-axis displays the names of the SGTs. To view the TrustSec session details for an SGT, click on the bar corresponding to that SGT. The details of the TrustSec sessions related to that SGT are displayed in the Live Log dashlet. AlarmsThis dashlet displays the alarms related to the TrustSec sessions. You can view the following details:
Quick ViewThe Quick View dashlet displays TrustSec-related information for NADs. You can also view the TrustSec-related information for an SGT. NAD Quick ViewEnter the name of the TrustSec network device for which you want to view the details in the Search box and press Enter. The search box provides an autocomplete feature, which filters and shows the matched device names in a drop-down as the user types into the text box. The following information is displayed in this dashlet:
You can use the Show Latest Logs option to view the NAD activity live logs for the device. SGT Quick ViewEnter the name of the SGT for which you want to view the details in the Search box and press Enter. The following information is displayed in this dashlet:
ACI Quick ViewThe following information is displayed in this dashlet:
To know more about Cisco Software-Defined Access (Cisco SD-Access) and Cisco Application Centric Infrastructure (Cisco ACI), see TrustSec-Cisco ACI Integration and Cisco ACI and Cisco SD-Access Integration with Virtual Network Awareness. Live LogClick the TrustSec Sessions link to view the active TrustSec sessions (sessions that have SGT as part of their response). Click the NAD Activity link to view information regarding TrustSec protocol data requests and responses from NADs to Cisco ISE. Click the ACI endpoint Activity link to view the IP-SGT information learnt by Cisco ISE from Cisco ACI. Configure TrustSec Global SettingsFor Cisco ISE to function as an TrustSec server and provide TrustSec services, you must define some global TrustSec settings. Before you begin
Procedure
What to do next
General TrustSec SettingsVerify Trustsec DeploymentThis option helps you to verify that the latest TrustSec policies are deployed on all network devices. Alarms are displayed in the Alarms dashlet, under Work Centers > TrustSec > Dashboard and Home > Summary, if there are any discrepancies between the policies configured on Cisco ISE and on the network device. The following alarms are displayed in the TrustSec dashboard:
The Verify Deployment option is also available from the below windows. In the Cisco ISE GUI, click the Menu icon () and choose:
Automatic Verification After Every Deploy: Check this check box if you want Cisco ISE to verify the updates on all the network devices after every deployment. When the deployment process is complete, the verification process starts after the time you specify in the Time after Deploy Process field. Time After Deploy Process: Specify the time for which you want Cisco ISE to wait for after the deployment process is complete, before starting the verification process. The valid range is 10–60 minutes. The current verification process is cancelled if a new deployment request is received during the waiting period or if another verification is in progress. Verify Now: Click this option to start the verification process immediately. Protected Access Credential (PAC)
Security Group Tag Numbering
Security Group Tag Numbering for APIC EPGsSecurity Group Tag Numbering for APIC EPGs : Check this check box and specify the range of numbers to be used for the SGTs created based on the EPGs learnt from APIC. Automatic Security Group CreationAuto Create Security Groups When Creating Authorization Rules: Check this check box to create the SGTs automatically while creating the authorization policy rules. If you select this option, the following message displays at the top of the Authorization Policy window: The autocreated SGTs are named based on the rule attributes.
By default, this option is disabled after a fresh install or upgrade.
IP SGT static mapping of hostnamesIP SGT Static Mapping of Hostnames: If you use FQDN and hostnames, Cisco ISE looks for the corresponding IP addresses in the PAN and PSN nodes while deploying the mappings and checking the deployment status. You can use this option to specify the number of mappings that are created for the IP addresses returned by the DNS query. You can select one of the following options:
TrustSec HTTP Service for Network Devices
Configure TrustSec Matrix SettingsBefore you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
TrustSec Matrix SettingsThe following table describes the fields on the TrustSec Matrix Settings window. To view this window, click the Menu icon () and choose Work Centers > TrustSec > Settings > TrustSec Matrix Settings. Table 16. Configuring TrustSec Matrix Settings
Configure TrustSec DevicesFor Cisco ISE to process requests from TrustSec-enabled devices, you must define these TrustSec-enabled devices in Cisco ISE. Procedure
OOB TrustSec PACAll TrustSec network devices possess a TrustSec PAC as part of the EAP-FAST protocol. This is also utilized by the secure RADIUS protocol where the RADIUS shared secret is derived from parameters carried by the PAC. One of these parameters, Initiator-ID, holds the TrustSec network device identity, namely the Device ID. If a device is identified using TrustSec PAC and there is no match between the Device ID, as configured for that device on Cisco ISE, and the Initiator-ID on the PAC, the authentication fails. Some TrustSec devices (for example, Cisco firewall ASA) do not support the EAP-FAST protocol. Therefore, Cisco ISE cannot provision these devices with TrustSec PAC over EAP-FAST. Instead, the TrustSec PAC is generated on Cisco ISE and manually copied to the device; hence this is called as the Out of Band (OOB) TrustSec PAC generation. When you generate a PAC from Cisco ISE, a PAC file encrypted with the Encryption Key is generated. This section describes the following: Generate a TrustSec PAC from the Settings ScreenYou can generate a TrustSec PAC from the Settings screen. Procedure
Generate a TrustSec PAC from the Network Devices ScreenYou can generate a TrustSec PAC from the Network Devices screen. Procedure
Generate a TrustSec PAC from the Network Devices List ScreenYou can generate a TrustSec PAC from the Network Devices list screen. Procedure
Push ButtonThe Push option in the egress policy initiates a CoA notification that calls the Trustsec devices to immediately request for updates from Cisco ISE regarding the configuration changes in the egress policy. Configure Cisco TrustSec AAA ServersYou can configure a list of Cisco TrustSec-enabled Cisco ISE servers in the AAA server list. Cisco TrustSec devices to authenticate against any of these servers. When you click Push, the new servers in this list download to the TrustSec devices. When a Cisco TrustSec device tries to authenticate, it chooses any Cisco ISE server from this list. If the first server is down or busy, the Cisco TrustSec device can authenticate itself against any of the other servers from this list. By default, the primary Cisco ISE server is a Cisco TrustSec AAA server. We recommend that you configure more Cisco ISE servers for a more reliable Cisco TrustSec environment. This page lists the Cisco ISE servers in your deployment that you have configured as your Cisco TrustSec AAA servers. Before you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
What to do nextConfigure Security Groups. TrustSec HTTPS ServersBy default, Cisco ISE exchanges Trustsec environment data between Cisco ISE and Trustsec NADs using RADIUS. You can configure Cisco ISE to use HTTPS, which is faster and more reliable than RADIUS. Cisco ISE uses REST APIs to implement HTTP transfers. HTTPS transfer requires:
To configure HTTPS transfer:
After configuration is complete, Cisco ISE returns a list of configured servers in the TrustSec environment data under Trustsec > Network Devices. DebugEnable ERS in debug. This setting logs all ERS traffic. Don't leave this setting enabled for more than 30 mins to avoid overloading the log file. You can enable additional audit information by checking Include request payload body under Trustsec REST API Service for Network Devices on Trustsec > Settings > General Trustsec Settings.General Trustsec Settings Security Groups ConfigurationA Security Group (SG) or Security Group Tag (SGT) is an element that is used in TrustSec policy configuration. SGTs are attached to packets when they move within a trusted network. These packets are tagged when they enter a trusted network (ingress) and untagged when they leave the trusted network (egress). SGTs are generated in a sequential manner, but you have the option to reserve a range of SGTs for IP to SGT mapping. Cisco ISE skips the reserved numbers while generating SGTs. TrustSec service uses these SGTs to enforce the TrustSec policy at egress. You can configure security groups from the following pages in the Admin portal:
You can click the Push button to initiate an environment CoA notification after updating multiple SGTs. This environment CoA notification goes to all TrustSec network devices forcing them to start a policy/data refresh request.
Managing Security Groups in Cisco ISEPrerequisitesTo create, edit or delete Security Groups, you must be a Super Admin or System Admin. Add a Security Group
Delete a Security GroupYou can't delete security groups that are still in use by a source or destination. That includes the default groups, which are mapped to a function in Cisco ISE:
Import Security Groups into Cisco ISEYou can import security groups in to a Cisco ISE node using a comma-separated value (CSV) file. You must first update the template before you can import security groups into Cisco ISE. You cannot run import of the same resource type at the same time. For example, you cannot concurrently import security groups from two different import files. You can download the CSV template from the Admin portal, enter your security group details in the template, and save the template as a CSV file, which you can then import back into Cisco ISE. While importing security groups, you can stop the import process when Cisco ISE encounters the first error. Procedure
Export Security Groups from Cisco ISEYou can export security groups configured in Cisco ISE in the form of a CSV file that you can use to import these security groups into another Cisco ISE node. Procedure
Add IP SGT Static MappingYou can use the IP-SGT static mappings to deploy the mappings on TrustSec devices and SXP domains in a unified manner. While creating a new IP-SGT static mapping, you can specify the SXP domains and the devices on which you want to deploy this mapping. You can also associate the IP-SGT mapping to a mapping group. Procedure
Deploy IP SGT Static MappingsAfter adding the mappings, deploy the mappings on the target network devices using the Deploy option. You must do this explicitly even if you have saved the mappings earlier. Click Check Status to check the deployment status of the devices. Procedure
Use the Check Status option in the IP SGT Static Mapping page to check if different SGTs are assigned to the same IP address for a specific device. You can use this option to locate the devices that have conflicting mappings, IP addresses that are mapped to multiple SGTs, and the SGTs that are assigned to the same IP address. The Check Status option can be used even if device groups, FQDN, hostname, or IPv6 addresses are used in the deployment. You must remove the conflicting mappings or modify the scope of deployment before deploying these mappings. IPv6 addresses can be used in IP SGT static mappings. These mappings can be propagated using SSH or SXP to specific network devices or network device groups. If FQDN and hostnames are used, Cisco ISE looks for the corresponding IP addresses in the PAN and PSN nodes while deploying the mappings and checking the deployment status. Use the IP SGT Static Mapping of Hostnames option in the General TrustSec Settings window to specify the number of mappings created for the IP addresses returned by the DNS query. Select one of the following options:
Import IP SGT Static Mappings into Cisco ISEYou can import IP SGT mappings using a CSV file. You can also download the CSV template from the Admin portal, enter your mapping details, save the template as a CSV file, and then import it back into Cisco ISE. Procedure
Export IP SGT Static Mappings from Cisco ISEYou can export the IP SGT mappings in the form of a CSV file. You can use this file to import these mappings into another Cisco ISE node. Procedure
Add SGT Mapping GroupBefore you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
You can also update or delete the mappings and mapping groups. To update a mapping or mapping group, check the check box next to the mapping or mapping group that you want to update, and then click Edit. To delete a mapping or mapping group, check the check box next to the mapping or mapping group that you want to delete, and then click Trash > Selected. When a mapping group is deleted, the IP SGT mappings within that group are also deleted. Add Security Group Access Control ListsBefore you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
Egress PolicyThe egress table lists the source and destination SGTs, both reserved and unreserved. This page also allows you to filter the egress table to view specific policies and also to save these preset filters. When the source SGT tries to reach the destination SGT, the TrustSec-capable device enforces the SGACLs based on the TrustSec policy as defined in the Egress Policy. Cisco ISE creates and provisions the policy. After you create the SGTs and SGACLs, which are the basic building blocks required to create a TrustSec policy, you can establish a relationship between them by assigning SGACLs to source and destination SGTs. Each combination of a source SGT to a destination SGT is a cell in the Egress Policy. In the Cisco ISE GUI, click the Menu icon () and choose Work Centers > TrustSec > TrustSec Policy > Egress Policy You can view the Egress policy in three different ways:
Source Tree ViewThe Source Tree view lists a compact and organized view of source SGTs in a collapsed state. You can expand any source SGT to see the internal table that lists all information related to that selected source SGT. This view displays only the source SGTs that are mapped to destination SGTs. If you expand a specific source SGT, it lists all destination SGTs that are mapped to this source SGT and and the corresponding policy (SGACLs) in a table. You will see three dots (...) next to some fields. This signifies that there is more information contained in the cell. You can position the cursor over the three dots to view the rest of the information in a quick view popup. When you position the cursor over an SGT name or an SGACL name, a quick view popup opens to display the content of that particular SGT or SGACL. Destination Tree ViewThe Destination Tree view lists a compact and organized view of destination SGTs in a collapsed state. You can expand any destination SGTs to see the internal table that lists all information related to that selected destination SGT. This view displays only the destination SGTs that are mapped to source SGTs. If you expand a specific destination SGT, it lists all source SGTs that are mapped to this destination SGT and and the corresponding policy (SGACLs) in a table. You will see three dots (...) next to some fields. This signifies that there is more information contained in the cell. You can position the cursor over the three dots to view the rest of the information in a quick view popup. When you position the cursor over an SGT name or an SGACL name, a quick view popup opens to display the content of that particular SGT or SGACL. Matrix ViewThe Matrix View of the Egress policy looks like a spreadsheet. It contains two axis:
The mapping of a source SGT to a destination SGT is represented as a cell. If a cell contains data, then it represents that there is a mapping between the corresponding source SGT and the destination SGT. There are two types of cells in the matrix view:
The Egress Policy cell displays the source SGT, the destination SGT, and the Final Catch All Rule as a single list under SGACLs, separated by commas. The Final Catch All Rule is not displayed if it is set to None. An empty cell in a matrix represents an unmapped cell. In the Egress Policy matrix view, you can scroll across the matrix to view the required set of cells. The browser does not load the entire matrix data at once. The browser requests the server for the data that falls in the area you are scrolling in. This prevents memory overflow and performance issues. You can use the following options in the View drop-down list to change the matrix view.
ISE allows you to create, name, and save the custom views. To create custom views, choose Show > Create Custom View. You can also update the view criteria or delete unused views. The Matrix view has the same GUI elements as the Source and Destination views. However, it has these additional elements: Matrix DimensionsThe Dimension drop-down list in the Matrix view enables you to set the dimensions of the matrix. Import/Export MatrixThe Import and Export buttons enable you to import or export the matrix. Create Custom ViewBefore you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
Matrix OperationsNavigating through the MatrixYou can navigate through the matrix either by dragging the matrix content area with the cursor or by using horizontal and vertical scroll bars. You can click and hold on a cell to drag it along with the entire matrix content in any direction. The source and destination bar moves along with the cells. The matrix view highlights the cell and the corresponding row (Source SGT) and column (Destination SGT) when a cell is selected. The coordinates (Source SGT and Destination SGT) of the selected cell are displayed below the matrix content area. Selecting a Cell in the MatrixTo select a cell in the matrix view, click on it. The selected cell is displayed in different color, and the source and destination SGTs are highlighted. You can deselect a cell either by clicking it again or by selecting another cell. Multiple cell selection is not allowed in the matrix view. Double-click the cell to edit the cell configuration. Configure SGACL from Egress PolicyYou can create Security Group ACLs directly from the Egress Policy page.
Configure Work Process SettingsBefore you beginTo perform the following task, you must be a Super Admin. Procedure
Matrices Listing PageTrustSec policy matrices and DEFCON matrices are listed in the Matrices Listing page. In the Cisco ISE GUI, click the Menu icon () and choose Work Centers > TrustSec > TrustSec Policy > Egress Policy > Matrices List. You can also view the number of devices that are assigned to each matrix.
You can do the following from the Matrices Listing page:
After assigning the devices to a matrix, click Push to notify the TrustSec configuration changes to the relevant network devices. Note the following points while working on the Matrices Listing page:
TrustSec Matrix Workflow ProcessThe Matrix Workflow feature helps you to test a new policy on a limited set of devices by using a draft version of the matrix (called staging matrix) before deploying the policy on all the network devices. You can submit the staging policy for approval and deploy the staging policy on the selected network devices after it is approved. This feature helps you to deploy the new policy on a limited set of devices, check whether it is working fine, and make any changes, if required. You can continue deploying the policy on next set of devices or on all the devices. When the staging policy is deployed on all the network devices, the staging matrix can be set as the new production matrix. When the Workflow mode is enabled, a user that is assigned to the editor role can create a staging matrix and edit the matrix cells. The staging matrix is a copy of the production matrix that is currently deployed on the TrustSec network. The editor can select the devices on which he wants to deploy the staging policy and submit the staging policy to the approver for approval. The user that is assigned to the approver role can review the staging policy and approve or reject the request. The staging policy can be deployed on the selected network devices only after the staging policy is reviewed and approved by the approver. The following figure describes the workflow process. Super Admin user can select the users that are assigned to the editor and approver roles in the Workflow Process Settings page. In the Cisco ISE GUI, click the Menu icon () and choose Work Centers > TrustSec > Settings > Workflow Process. You cannot edit the SGTs and SGACLs after the staging policy is deployed on the selected devices, however, you can edit the matrix cells. You can use the Configuration Delta report to track the difference between the production matrix and the staging matrix. You can also click on the Delta icon on a cell to view the changes made to that cell during the staging process. The following table describes the different stages of the workflow:
The options displayed in the Workflow drop-down list vary based on the workflow state and the user role (editor or approver). The following table lists the menu options displayed for an editor and approver:
The workflow options are also available in the Source and Destination Tree view. You can view the list of devices that downloaded the staging/production policy by using the TrustSec Policy Download report (Work Centers > TrustSec > Reports). The TrustSec Policy Download lists the requests sent by the network devices for policy (SGT/SGACL) download and the details sent by ISE. If the Workflow mode is enabled, the requests can be filtered for production or staging matrix. Egress Policy Table Cells ConfigurationCisco ISE allows you to configure cells using various options that are available in the tool bar. Cisco ISE does not allow a cell configuration if the selected source and destination SGTs are identical to a mapped cell. Add the Mapping of Egress Policy CellsYou can add the mapping cell for Egress Policy from the Policy page. Procedure
Export Egress PolicyProcedure
Import Egress PolicyYou can create the egress policy offline and then import it in to Cisco ISE. If you have a large number of security group tags, then creating the security group ACL mapping one by one might take some time. Instead, creating the egress policy offline and importing it in to Cisco ISE saves time for you. During import, Cisco ISE appends the entries from the CSV file to the egress policy matrix and does not overwrite the data. Egress policy import fails if the:
Procedure
Configure SGT from Egress PolicyYou can create Security Groups directly from the Egress Policy page. Procedure
Monitor ModeThe Monitor All option in the egress policy allows you to change the entire egress policy configuration status to monitor mode with a single click. Check the Monitor All check box in the egress policy page to change the egress policy configuration status of all the cells to monitor mode. When you check the Monitor All check box, the following changes take place in the configuration status:
Uncheck the Monitor All check box to restore the original configuration status. It does not change the actual status of the cell in the database. When you deselect Monitor All, each cell in the egress policy regains its original configuration status. Features of Monitor ModeThe monitoring functionality of the monitor mode helps you to:
The Unknown Security GroupThe Unknown security group is a pre-configured security group that cannot be modified and represents the Trustsec with tag value 0. The Cisco security group network devices request for cells that refer to the unknown SGT when they do not have an SGT of either source or destination. If only the source is unknown, the request applies to the <unknown, Destination SGT> cell. If only the destination is unknown, the request applies to the <source SGT, unknown> cell. If both the source and destination are unknown, the request applies to the <Unknown, Unknown> cell. Default PolicyDefault Policy refers to the <ANY,ANY> cell. Any source SGT is mapped to any destination SGT. Here, the ANY SGT cannot be modified and it is not listed in any source or destination SGTs. The ANY SGT can only be paired with ANY SGT. It cannot be paired with any other SGTs. A TrustSec network device attaches the default policy to the end of the specific cell policy.
According to Cisco ISE, the cell policy and the default policy are two separate sets of SGACLs that the devices get in response to two separate policy queries. Configuration of the default policy is different from other cells:
SGT AssignmentCisco ISE allows you to assign an SGT to a TrustSec device if you know the device hostname or IP address. When a device with the specific hostname or IP address joins the network, Cisco ISE will assign the SGT before authenticating it. The following SGTs are created by default:
Sometimes, devices need to be manually configured to map the security group tags to the endpoint. You can create this mapping from the Security Group Mappings page. Before you perform this action, ensure that you have reserved a range of SGTs. ISE allows you to create up to 10,000 IP-to-SGT mappings. You can create IP-to-SGT mapping groups to logically group such large scale mappings. Each group of IP-to-SGT mappings contains a list of IP addresses, a single security group it would map to and a network device or network device group which is the deployment target for those mappings. NDAC AuthorizationYou can configure the TrustSec policy by assigning SGTs to devices. You can assign security groups to devices based on TrustSec device ID attribute. Configure NDAC AuthorizationBefore you begin
Procedure
Configure End User AuthorizationCisco ISE allows you to assign a security group as the result of an authorization policy evaluation. Using this option, you can assign a security group to users and end points. Before you begin
Procedure
TrustSec Configuration and Policy PushCisco ISE supports Change of Authorization (CoA) which allows Cisco ISE to notify TrustSec devices about TrustSec configuration and policy changes, so that the devices can reply with requests to get the relevant data. A CoA notification can trigger a TrustSec network device to send either an Environment CoA or a Policy CoA. You can also push a configuration change to devices that do not intrinsically support the TrustSec CoA feature. CoA Supported Network DevicesCisco ISE sends CoA notifications to the following network devices:
When Cisco ISE is deployed in a distributed environment where there are several secondaries that interoperate with different sets of devices, CoA requests are sent from Cisco ISE primary node to all the network devices. Therefore, TrustSec network devices need to be configured with the Cisco ISE primary node as the CoA client. The devices return CoA NAK or ACK back to the Cisco ISE primary node. However, the following TrustSec session coming from the network device would be sent to the Cisco ISE node to which the network devise sends all it's other AAA requests and not necessarily to the primary node. Push Configuration Changes to Non-CoA Supporting DevicesSome platforms do not support Cisco ISE's "Push" feature for Change of Authorization (CoA), for example: some versions of the Nexus network device. For this case, ISE will connect to the network device and make it to trigger an updated configuration request towards ISE. To achieve this, ISE opens an SSHv2 tunnel to the network device, and the Cisco ISE sends a command that triggers a refresh of the TrustSec policy matrix. This method can also be carried out on network platforms that support CoA pushing. Procedure
The network device is now configured to push Trustsec changes. After you change a Cisco ISE policy, click Push to have the new configuration reflected on the network device. SSH Key ValidationYou may want to harden security by using an SSH key. Cisco ISE supports this with its SSH key validation feature. To use this feature, you open an SSHv2 tunnel from the Cisco ISE to the network device, then use the network device's own CLI to retrieve the SSH key. You then copy this key and paste it into Cisco ISE for validation. Cisco ISE terminates the connection if the SSH key is wrong. Limitation: Currently, Cisco ISE can validate only one IP (not on ranges of IP, or subnets within an IP) Before you beginYou will require:
for the network device with which you want the Cisco ISE to communicate securely. Procedure
The network device is now communicating with the Cisco ISE using SSH key validation. Environment CoA Notification FlowThe following figure depicts the Environment CoA notification flow. Figure 11. Environment CoA Notification Flow
Environment CoA TriggersAn Environment CoA can be triggered for:
Trigger Environment CoA for Network DevicesTo trigger an Environment CoA for the Network devices, complete the following steps:
Trigger Environment CoA for Security GroupsTo trigger an Environment CoA for the security groups, complete the following steps.
Trigger Environment CoA for TrustSec AAA ServersTo trigger an Environment CoA for the TrustSec AAA servers, complete the following steps.
Trigger Environment CoA for NDAC PolicyTo trigger an Environment CoA for the NDAC Policies, complete the following steps.
Update SGACL Content FlowThe following figure depicts the Update SGACL Content flow. Figure 12. Update SGACL Content Flow
Initiate an Update SGACL Named List CoATo trigger an Update SGACL Named List CoA, complete the following steps: Procedure
Policies Update CoA Notification FlowThe following figure depicts the Policies CoA Notification flow. Figure 13. Policies CoA Notification flow
Update SGT Matrix CoA FlowThe following figure depicts the Update SGT Matrix CoA flow. Figure 14. Update SGT Matrix CoA flow
Initiate Update SGT Matrix CoA from Egress PolicyProcedure
TrustSec CoA SummaryThe following table summarizes the various scenarios that may require initiating a TrustSec CoA, the type of CoA used in each scenario, and the related UI pages. Table 17. TrustSec CoA Summary
Security Group Tag Exchange ProtocolSecurity Group Tag (SGT) Exchange Protocol (SXP) is used to propagate the SGTs across network devices that do not have hardware support for TrustSec. SXP is used to transport an endpoint's SGT along with the IP address from one SGT-aware network device to another. The data that SXP transports is called as IP-SGT mapping. The SGT to which an endpoint belongs can be assigned statically or dynamically, and the SGT can be used as a classifier in network policies. To enable SXP service on a node, check the Enable SXP Service check box in the General Node Settings page. You must also specify the interface to be used for SXP service. SXP uses TCP as its transport protocol to set up SXP connection between two separate network devices. Each SXP connection has one peer designated as SXP speaker and the other peer as SXP listener. The peers can also be configured in a bi-directional mode where each of them act as both speaker and listener. Connections can be initiated by either peers, but mapping information is always propagated from a speaker to a listener.
The following table lists some of the common terms used in the SXP environment:
To view the SXP peer devices that are added to Cisco ISE, choose Work centers > TrustSec > SXP > SXP Devices.
Add an SXP DeviceBefore you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
Add an SXP Domain FilterYou can view all the mappings learned by the SXP devices (including static mappings and session mappings). To view this window, click the Menu icon () and choose Work Centers > TrustSec > SXP > All SXP Mappings By default, session mappings learnt from the network devices are sent only to the default VPN group. You can create SXP domain filters to send the mappings to different SXP domains (VPNs). You will find automatically created mappings in this window based on the configured Virtual Network in the IP-SGT mappings.
To add an SXP domain filter: Before you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
Configure SXP SettingsBefore you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
TrustSec-Cisco ACI IntegrationCisco ISE can synchronize SGTs and SXP mappings with the Internal Endpoint Groups (IEPGs), External Endpoint Groups (EEPGs), and endpoint (EP) configuration of Cisco Application Centric Infrastructure (Cisco ACI). Cisco ISE supports packets coming from the Cisco ACI domain to the TrustSec domain by synchronizing the IEPGs, and creating correlating read-only SGTs in ISE. These SGTs map the endpoints configured in Cisco ACI, and create correlating SXP mappings in ISE. The SGTs displayed on the Security Groups page (with the value "Cisco ACI" in the Learned From field). You can view the SXP mappings on the All SXP Mappings page. These mappings are sent to Cisco ACI only if the Policy Plane option is selected (in the Cisco ACI Settings page) and the SXP device belongs to an SXP domain, that you configured on the Cisco ACI Settings page.
When you add a Security Group, you can specify whether the SGT is sent to Cisco ACI by enabling the Propagate to ACI option. When this option is enabled, the SXP mappings that are related to this SGT are sent to Cisco ACI. But, only if the Policy Plane option is selected (in the Cisco ACI Settings page) and the SXP device belongs to an SXP Domain, which you configure on the Cisco ACI Settings page. Cisco ACI supports the packets that are sent from the TrustSec domain to the Cisco ACI domain by synchronizing the SGTs, and creating correlating EEPGs. Cisco ACI creates subnets under EEPG based on the SXP mappings from Cisco ISE. These subnets are not deleted from Cisco ACI, when the corresponding SXP mappings are deleted in Cisco ISE. When an IEPG is updated in Cisco ACI, the corresponding SGT configuration is updated in Cisco ISE. A new EEPG is created in Cisco ACI, when an SGT is added in Cisco ISE. When an SGT is deleted, the corresponding EEPG is deleted in Cisco ACI. When an endpoint is updated in Cisco ACI, the corresponding SXP mapping is updated in Cisco ISE. If the connection with the Cisco ACI server is lost, Cisco ISE re-synchronizes the data again when the connection is reestablished.
You can view all the bindings sent to Cisco ACI from Cisco ISE and vice versa in the All ACI Mappings window. To view this window, click the Menu icon () and choose . When the binding is learned from the Cisco ACI, the Learned By column displays ACI and the PSNs involved column is empty. Whereas when the binding is sent to Cisco ACI from Cisco ISE, the Learned By column displays the type of binding such as static, SXP or session and the PSNs involved column displays the FQDN of the PSNs involved. Tenant information is also displayed for the bindings that are sent to ACI in the VN column (in tenant:VN format).
Configure ACI SettingsBefore you beginTo perform the following task, you must be a Super Admin or System Admin. Procedure
Cisco ACI and Cisco SD-Access Integration with Virtual Network AwarenessIn Cisco ISE Release 2.7, there is a basic implementation of synchronizing SGT and SXP mappings with the Internal Endpoint Groups (IEPGs), External Endpoint Groups (EEPGs), and endpoint configuration of Cisco ACI. Cisco ISE Release 3.0 supports an extra implementation that provides enhanced conversion of information exchange and cross-domain automation for a Cisco Software-Defined Access (SD-Access) fabric with Cisco ACI infrastructure. This implementation supports the following:
Cisco ISE learns the virtual network information from RADIUS bindings or Cisco ACI bindings, and provides a local static mapping for a specific virtual network. A virtual network can be used to enhance the SXP filter logic that is leveraged to coordinate the sharing of IP-SGT bindings with Cisco ACI. Note that the SXP domains and virtual networks are closely linked, in the sense that the virtual networks that are extended to Cisco ACI are the only constructs to share IP-SGT bindings with Cisco ACI. Therefore, specific SXP domains (denoted with the SD-Access- prefix) are mapped to the equivalent virtual network (SXP domain minus the SD-Access- prefix) in Cisco ISE. In order to allow the Cisco SD-Access border node to know about the Cisco ACI bindings, the Cisco ACI bindings are replicated as if they were originated from all the extended virtual networks before they are sent through the SXP filter logic. For example, a binding from Cisco ACI with the original Cisco ACI virtual network is sent through the SXP filter four times, if Cisco SD-Access virtual network 1, virtual network 2 and virtual network 3 are extended to Cisco ACI. This exact same binding goes through the filter for all the four virtual networks. The filters can be modified and customized as per specific deployment requirements. However, the replication will always happen for all extended virtual networks. Cisco ISE learns about the IP-SGT, EPG bindings from Cisco ACI whenever possible. However, Cisco ISE cannot force Cisco ACI to learn about any bindings. Cisco ACI has to explicitly request for the bindings from Cisco ISE. The following table lists the source and destination combinations that are possible for IP-SGT or IP-EPG bindings in Cisco ISE.
To promote cross-domain support, you must have the ability to exchange and filter the various network forwarding domains, for example, IP address, subnet mask, Security Group Tag, EPGs, virtual networks, Virtual Routing and Forwarding(VRF), from one policy domain, or a forwarding domain within a policy domain, to another and vice versa. This is especially important when a policy domain, for example Cisco SD-Access, Cisco ACI, SD-WAN, CPC, and Meraki, has multiple forwarding domains. You can identify, capture, and store the policy domain’s network-specific forwarding domain and the domain-specific attributes for all the sessions and bindings learned from other policy domains. These will be used by the policy administrator to filter the sessions and bindings into specific SXP domains. In addition, it enables the administrator to create policies that map or filter only certain bindings from one forwarding domain to another. From Cisco ISE 3.0 onwards, with every virtual network learnt by the Cisco ISE from Cisco DNA Center, you will find an automatically created SXP filter and an SXP domain in the SXP Devices window. To view this window, click the Menu icon () and choose Work Centers > TrustSec > SXP > SXP Devices. These SXP domains will, in turn, be used to set the virtual networks in the bindings shared with Cisco ACI. You can add and edit virtual networks to IP-SGT static mappings in the IP-SGT Static mapping window. To view this window, click the Menu icon () and choose Work Centers > TrustSec > Components > IP SGT Static Mapping. Click Add to add a new mapping, or click Edit to modify an existing mapping. Figure 15. Add virtual network in IP SGT Static MappingYou can also include virtual networks in the SXP domain filter to specify which SXP domain to send the mapping to when the mapping received by Cisco ISE is mapped to a particular virtual network. To view this window, click the Menu icon () and choose Work Centers > TrustSec > SXP > SXP Devices > All SXP Mappings and click Add SXP Domain Filter. The bindings learned by Cisco ACI have the original Cisco ACI virtual network, and these are sent to the SXP domain configured in the filter. This filter also influences how a binding is sent to the Cisco ACI. Figure 16. Add virtual network information in SXP Device FilterConfigure Cisco ISE for Cisco ACI and Cisco SD-Access IntegrationThis task helps you to configure Cisco ISE to support Cisco ACI and Cisco SD-Access Integration. Before you beginMake sure Cisco ISE is integrated with the latest version of Cisco DNA Center, and the APIC version being used is 5.1 or later. Procedure
Verify Cisco ACI and Cisco SD-Access IntegrationTo get detailed information between the Cisco ACI and Cisco SD-Access connectivity, choose . Select the Cisco ISE node for which the SXP and pxGrid services are enabled and click Edit. Set the log level to DEBUG for the spbhub, sxp and TrustSec components as shown in the following figure. Figure 19. Enable debug logsThe logs can be downloaded from the Dowload Logs window. (To view this window, click the Menu icon () and choose .) You can choose to download either a support bundle from the Support Bundle tab or download specific debug logs from the Debug Logs tab. In addtion, the TrustSec Dashboard is enhanced with the information learnt from the Cisco ACI integration, which is useful for troubleshooting Cisco ACI-related issues. After the Cisco DNA Center sends out the domain advertisement, confirm whether the APIC certificates are obtained from the APIC domain manager or not, in the both the Trusted Certificates window and the System Certificates window of Cisco ISE. Figure 20. Verify the Certificate in System Certificates window Figure 21. Verify the Certificate in Trusted Certificates windowRun Top N RBACL Drops by User ReportYou can run the Top N RBACL Drops by User report to see the policy violations (based on packet drops) by specific users. Procedure
Which of the following malware programs disguises a harmful program within a seemingly safe software application?Trojans Malware – Malware disguised in what appears to be legitimate software. Once activated, malware Trojans will conduct whatever action they have been programmed to carry out. Unlike viruses and worms, Trojans do not replicate or reproduce through infection.
Why do event logs record both normal and abnormal activities Select all that apply quizlet?Event logs should record both normal and abnormal activities because normal activities can help track side effects of abnormal activities or look abnormal when analyzed in context with other activities. True or False?
What is the organization's largest risk for injury infrastructure lost?What is the organization's largest risk for injury infrastructure loss? Natural disasters: a fire, flood, earthquake or similar event can destroy data centers and all they contain.
Is the period of time during which a system is unprotected from an exploit?The window of vulnerability is the period of time during which a system is unprotected from an exploit. Sharing on a computer system includes two main types of policies, global and tailored.
|