A self-signed certificate indicates that it was signed by a subordinate ca.

When you install a patch on an ISE node, the node is rebooted after the installation is complete. You might have to wait for a few minutes before you can log in again. You can schedule patch installations during a maintenance window to avoid temporary outage.

Ensure that you install patches that are applicable for the Cisco ISE version that is deployed in your network. Cisco ISE reports any mismatch in versions as well as any errors in the patch file.

You cannot install a patch with a version that is lower than the patch that is currently installed on Cisco ISE. Similarly, you cannot roll back changes of a lower-version patch if a higher version is currently installed on Cisco ISE. For example, if patch 3 is installed on your Cisco ISE servers, you cannot install or roll back patch 1 or 2.

When you install a patch from the Primary PAN that is part of a distributed deployment, Cisco ISE installs the patch on the primary node and then all the secondary nodes in the deployment. If the patch installation is successful on the Primary PAN, Cisco ISE then continues patch installation on the secondary nodes. If it fails on the Primary PAN, the installation does not proceed to the secondary nodes. However, if the installation fails on any of the secondary nodes for any reason, it still continues with the next secondary node in your deployment.

When you install a patch from the Primary PAN that is part of a two-node deployment, Cisco installs the patch on the primary node and then on the secondary node. If the patch installation is successful on the Primary PAN, Cisco then continues patch installation on the secondary node. If it fails on the Primary PAN, the installation does not proceed to the secondary node.

Cisco offers Smart Licensing, which enables you to monitor Cisco ISE software licenses and endpoint license consumption. You can monitor license usage easily and efficiently with a single registration token, rather than individually importing separate licenses. View and manage the details of all the Cisco products and licenses that you have purchased in a centralized database, the Cisco Smart Software Manager (CSSM). Log in to the CSSM portal to easily track the endpoint licenses that are available to you, and consumption statistics.

When a smart license token is active and registered in the Cisco ISE administration portal, the CSSM monitors the consumption of licenses by each endpoint session per product license. Smart Licensing notifies the administrator about license consumption by endpoint sessions with a simple table layout in Cisco ISE. Smart Licensing reports the peak usage of each enabled license to the centralized database daily. When licenses are available and not consumed, the administrator is notified of available licenses and can continue to monitor usage. When consumption exceeds the number of licenses available, an alarm is activated and the administrator is notified through alarms and notifications.

With Smart Licensing, you can also manage the different license entitlements included through your Cisco Smart Account, such as Base, Plus, Apex, or TACACS. From Cisco ISE, you can monitor basic consumption statistics per license entitlement. From your CSSM account, you can view additional information, statistics, and notifications, as well as make changes to your account and entitlements.

Note	CSSM satellite is not supported.

Cisco ISE takes internal samples of license consumption every 30 minutes. License compliancy and consumption is updated accordingly. To view this information in the Licenses table in Cisco ISE, from the main menu, choose , and click Refresh.

From the time you register your Cisco ISE Primary Administration node (PAN) with the CSSM, Cisco ISE reports peak counts of license consumption to the CSSM server every six hours. The peak count reports help ensure that license consumption in Cisco ISE is in compliance with the licenses purchased and registered. Cisco ISE communicates with the CSSM server by storing a local copy of the CSSM certificate. The CSSM certificate is automatically reauthorized during the daily synchronization, and when you refresh the Licenses table. Typically, CSSM certificates are valid for six months.

If there is a change in the compliance status when Cisco ISE synchronizes with the CSSM server, the Last Authorization column of the Licenses table is updated accordingly. In addition, when entitlements are no longer compliant, the number of days for which they are out of compliancy appears in the Days Out of Compliancy column. Noncompliancy is also indicated in the notifications displayed at the top of the Licensing area, and on the Cisco ISE toolbar next to the License Warning link. In addition to notifications, you can view alarms.

Note	TACACS licenses are authorized when Cisco ISE communicates with the CSSM server, but they are not session-based, and therefore, no consumption count is associated with them in the Licenses table.

The compliance column of the Licenses table displays one of the following values:

• In Compliance: The use of this license is in compliance.

• Released Entitlement: The licenses have been purchased and released for use, but none have been consumed so far in this Cisco ISE deployment. In such a scenario, the Consumption Count for the license is 0.

• Evaluation: Evaluation licenses are available for use.

Figure 1. Licenses Table

Mobile Device Management (MDM) servers secure, monitor, manage, and support mobile devices that are deployed across mobile operators, service providers, and enterprises. Traditionally, MDM servers have only supported mobile devices. Some MDM servers now manage all types of devices in a network (mobile phones, tablets, laptops, and desktops) and are called Unified Endpoint Management (UEM) servers. MDM servers act as a policy server that controls the use of some applications on a mobile device (for example, an email application) in the deployed environment. Cisco ISE queries a connected MDM server for information about various attributes that you can use to create network authorization policies.

You can run multiple active MDM servers on your network, from different vendors. This allows you to route different endpoints to different MDM servers based on device factors such as location or device type.

Cisco ISE also integrates with MDM servers using the Cisco MDM Server Info APIs, Version 2 and later versions, to allow devices to access the network over VPN via Cisco AnyConnect 4.1 and Cisco Adaptive Security Appliances 9.3.2 or later.

In the following illustration, Cisco ISE is the enforcement point and the MDM policy server is the policy information point. Cisco ISE obtains data from the MDM server to provide a complete solution.

Configure Cisco ISE to interoperate with one or more external MDM servers. By setting up this type of third-party connection, you can use the detailed information available in the MDM database. Cisco ISE uses REST API calls to retrieve information from the external MDM server. Cisco ISE applies the appropriate access control policies to switches, access routers, wireless access points, and other network access points. The policies give you greater control of the remote devices that are accessing the Cisco ISE-enabled network.

For a list of the MDM vendors supported by Cisco ISE, see Supported Unified Endpoint Management and Mobile Device Management Servers.

Dictionaries 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:

• MSG_ATTR

• ENTITY_ATTR

• PIP_ATTR

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.

The structure of a Context Visibility window is similar to the home page, except that the Context Visibility windows:

• Retain your current context (browser window) when you filter the displayed data

• Are more customizable

• Focus on endpoint data

You can view the context visibility data only from the primary PAN.

Dashlets on the Context Visibility windows show information about endpoints, and endpoint connections to NADs. The information currently displayed is based on the content in the list of data below the dashlets on each window. Each window displays endpoint data, based on the name of the tab. As you filter the data, both the list and dashlets update. You can filter the data by clicking on parts of one or more of the circular graphs, by filtering rows on the table, or any combination those actions. As you select filters, the effects are additive, also referred to as cascading filter, which allows you to drill down to find the particular data you are looking for. You can also click an endpoint in the list, and get a detailed view of that endpoint.

There are four main views under Context Visibility:

• Endpoints: Filter the endpoints you want to view based on types of devices, compliance status, authentication type, hardware inventory, and more. See The Hardware Dashboard for additional information.

  Note

  We recommend that you enable the accounting settings on the network access devices (NADs) to ensure that the accounting start and update information is sent to Cisco ISE. Cisco ISE can collect accounting information, such as the latest IP address, status of the session (Connected, Disconnected, or Rejected), the number of days an endpoint has been inactive, only if accounting is enabled. This information is displayed in the Live Logs, Live Sessions and Context Visibility windows in the Cisco ISE administration portal. When accounting is disabled on a NAD, there might be a missing, incorrect, or mismatched accounting information between the Live Sessions, Live Logs and Context Visibility windows.

  Note

  The Visibility Setup workflow that is available on the Cisco ISE administration portal home page allows you to add a list of IP address ranges for endpoints discovery. After this workflow is configured, Cisco ISE authenticates the endpoints, but the endpoints that are not included in the configured IP address ranges are not displayed in the window and the Endpoints listing page ().

• Users: Displays user-based information from user identity sources.

  If there is a change in the username or password attribute, it reflects in the Users window when there is a change in the authentication status.

  If the username is changed in the Microsoft Active Directory, the updated change is displayed in the Users window immediately after re-authentication.

  If any other attributes such as Email, Phone, Department, etc are changed in the Microsoft Active Directory, the updated attributes are displayed in the Users window 24 hours after re-authentication.

  Note	Updating User Attributes from AD depends on the interval configured under Active Directory Probe. For more information, see Active Directory Probe.

• Network Devices: This window displays the list of NADs that have endpoints connected to them. For any NAD, click the number of endpoints that is displayed in the corresponding # of endpoints column. A window that lists all the devices filtered by that NAD is displayed.

  Note

  If you have configured your network device with SNMPv3 parameters, you cannot generate the Network Device Session Status Summary report that is provided by the Cisco ISE monitoring service (). You can generate this report successfully if your network device is configured with SNMPv1 or SNMPv2c parameters.

• Application: Use this window to identify the number of endpoints that have a specific application installed. The results are displayed in graphical and table formats. The graphical representation helps you make a comparative analysis. For example, you can find out the number of endpoints with the Google Chrome software along with their Version, Vendor, and Category (Anti-phishing, Browser, and so on) in a table as well as a bar chart. For more information, see The Application Tab.

You can create a new tab in the Context Visibility windows and create a custom list for additional filtering. Dashlets are not supported in custom views.

Click a section of a circular graph in a dashlet to view a new window with filtered data from that dashlet in. From this new window, you can continue to filter the displayed data, as described in Filtering Displayed Data in a View.

For more information about using Context Visibility windows to find endpoint data, see the following Cisco YouTube video which uses ISE 2.1 https://www.youtube.com/watch?v=HvonGhrydfg.

User authentication policies in Cisco ISE enable you to provide authentication for a number of user login session types using a variety of standard authentication protocols including, but not limited to, Password Authentication Protocol (PAP), Challenge-Handshake Authentication Protocol (CHAP), Protected Extensible Authentication Protocol (PEAP), and Extensible Authentication Protocol (EAP). Cisco ISE specifies the allowable protocol(s) that are available to the network devices on which the user tries to authenticate and specifies the identity sources from which user authentication is validated.

Cisco ISE allows for a wide range of variables within authorization policies to ensure that only authorized users can access the appropriate resources when they access the network. The initial release of Cisco ISE supports only RADIUS-governed access to the internal network and its resources.

At the most fundamental level, Cisco ISE supports 802.1X, MAC authentication bypass (MAB), and browser-based Web authentication login for basic user authentication and access via both wired and wireless networks. Upon receiving an authentication request, the “outer part” of the authentication policy is used to select the set of protocols that are allowed when processing the request. Then, the “inner part” of the authentication policy is used to select the identity source that is used to authenticate the request. The identity source may consist of a specific identity store or an identity store sequence that lists a set of accessible identities until the user received a definitive authorization response.

Once authentication succeeds, the session flow proceeds to the authorization policy. (There are also options available that allow Cisco ISE to process the authorization policy even when the authentication did not succeed.) Cisco ISE enables you to configure behavior for “authentication failed,” “user not found,” and “process failed” cases, and also to decide whether to reject the request, drop the request (no response is issued), or continue to the authorization policy. In cases where Cisco ISE continues to perform authorization, you can use the “AuthenticationStaus” attribute in the “NetworkAccess” dictionary to incorporate the authentication result as part of the authorization policy.

The authorization policy result is Cisco ISE assigning an authorization profile that might also involve a downloadable ACL specifying traffic management on the network policy enforcement device. The downloadable ACL specifies the RADIUS attributes that are returned during authentication and that define the user access privileges granted once authenticated by Cisco ISE.

Note

Cisco ISE processes the attributes in the following order while identifying the Authentication session for the incoming accounting packet: For Cisco devices: Class/State audit-session-id For third party devices: Class/State Calling-Station-ID If the authentication session cannot be identified, Cisco ISE creates a new session ID based on the Calling-Station-ID, NAS-Port, and NAS-IP-Address.

In this scenario, the network access device (NAD) makes a new authorization request to the Cisco ISE RADIUS server from an unknown endpoint connection. The endpoint then receives a url-redirect to Cisco ISE.

Note

webauth-vrf-aware command is supported only in IOS XE 3.7E, IOS 15.2(4)E or later versions. Other switches do not support WebAuth URL redirect in virtual routing and forwarding (VRF) environment. In such cases, as a workaround, you can add a route in the global routing table to leak the traffic back into the VRF.

If the guest device is connected to a NAD, the guest service interaction takes the form of a MAC Authentication Bypass (MAB) request that leads to a Guest portal Central WebAuth login. The following is an outline of the subsequent Central Web Authentication (Central WebAuth) process, which applies to both wireless and wired network access devices.

1. The guest device connects to the NAD through a hard-wired connection. There is no 802.1X supplicant on the guest device.

2. An authentication policy with a service type for MAB allows a MAB failure to continue and return a restricted network profile containing a url-redirect for the Central WebAuth user interface.

3. The NAD is configured to authenticate MAB requests to the Cisco ISE RADIUS server.

4. The Cisco ISE RADIUS server processes the MAB request and does not find an endpoint for the guest device.

   This MAB failure resolves to the restricted network profile and returns the url-redirect value in the profile to the NAD in an access-accept. To support this function, ensure that an authorization policy exists and features the appropriate wired or wireless MAB (under compound conditions) and, optionally, “Session:Posture Status=Unknown” conditions. The NAD uses this value to redirect all guest HTTPS traffic on the default port 8443 to the url-redirect value.

   The standard URL value in this case is: https://ip:port/guestportal/gateway?sessionId=NetworkSessionId&portal=<PortalID>&action=cwa

5. The guest device initiates an HTTP request to redirect URL via a web browser.

6. The NAD redirects the request to the url-redirect value returned from the initial access-accept.

7. The gateway URL value with action CWA redirects to the Guest portal login page.

8. The guest enters their login credentials and submits the login form.

9. The guest server authenticates the login credentials.

10. Depending on the type of flow, the following occurs:

    • If it is a non-posture flow (authentication without further validation), where the Guest portal is not configured to perform client provisioning, the guest server sends a CoA to the NAD. This CoA causes the NAD to reauthenticate the guest device using the Cisco ISE RADIUS server. A new access-accept is returned to the NAD with the configured network access. If client provisioning is not configured and the VLAN needs to be changed, the Guest portal performs VLAN IP renew. The guest does not have to re-enter login credentials. The username and password entered for the initial login are used automatically.

    • If it is a posture flow, where the Guest portal is configured to perform client provisioning, the guest device web browser displays the Client Provisioning page for posture agent installation and compliance. (You can also optionally configure the client provisioning resource policy to feature a “NetworkAccess:UseCase=GuestFlow” condition.)

The Guest portal redirects to the Client Provisioning portal (because there is no client provisioning or posture agent for Linux), which in turn redirects back to a guest authentication servlet to perform optional IP release/renew and then CoA.

With redirection to the Client Provisioning portal, the Client Provisioning service downloads a non-persistent web agent to the guest device and performs a posture check of the device. You can optionally configure the posture policy with a “NetworkAccess:UseCase=GuestFlow” condition.

If the guest device is non-compliant, ensure that you have configured an authorization policy that features “NetworkAccess:UseCase=GuestFlow” and “Session:Posture Status=NonCompliant” conditions.

When the guest device is compliant, ensure that you have an authorization policy configured with the conditions “NetworkAccess:UseCase=GuestFlow” and “Session:Posture Status=Compliant.” From here, the Client Provisioning service issues a CoA to the NAD. This CoA causes the NAD to reauthenticate the guest using the Cisco ISE RADIUS server. A new access-accept is returned to the NAD with the configured network access.

Note	“NetworkAccess:UseCase=GuestFlow” can also apply for Active Directory and LDAP users who log in as guests.

Employees can access the My Devices portal directly.

Some network devices that need network access are not supported by native supplicant provisioning and cannot be registered using the BYOD portal. However, employees can add and register personal devices, whose operating systems are not supported or do not have web browsers (such as printers, internet radios, and other devices), using the My Devices portal.

Employees can add and manage new devices by entering the MAC address for the device. When employees add devices using the My Devices portal, Cisco ISE adds the devices to the Endpoints window () as members of the RegisteredDevices endpoint identity group (unless already statically assigned to a different endpoint identity group). The devices are profiled like any other endpoint in Cisco ISE and go through a registration process for network access.

When two MAC addresses from one device are entered into the My Devices portal by a user, profiling determines that they have the same hostname, and they are merged together as a single entry in Cisco ISE. For example, a user registers a laptop with wired and wireless addresses. Any operations on that device, such as delete, acts on both addresses.

When a registered device is deleted from the portal, the DeviceRegistrationStatus and BYODRegistration attributes change to Not Registered and No, respectively. However, these attributes remain unchanged when a guest (who is not an employee) registers a device using the Guest Device Registration window in the credentialed Guest portals, because these BYOD attributes are used only during employee device registration.

Regardless of whether employees register their devices using the BYOD or the My Devices portals, they can use the My Devices portal to manage them.

Note	The My Devices portal is not available when the Administrator's portal is down.

Cisco ISE retrieves user or machine attributes and groups from Active Directory for use in authorization policy rules. These attributes can be used in Cisco ISE policies and determine the authorization level for a user or machine. Cisco ISE retrieves user and machine Active Directory attributes after successful authentication and can also retrieve attributes for an authorization that is independent of authentication.

Cisco ISE may use groups in external identity stores to assign permissions to users or computers; for example, to map users to sponsor groups. You should note the following restrictions on group memberships in Active Directory:

• Policy rule conditions may reference any of the following: a user’s or computer’s primary group, the groups of which a user or computer is a direct member, or indirect (nested) groups.

• Domain local groups outside a user’s or computer’s account domain are not supported.

Note

You can use the value of the Active Directory attribute, msRadiusFramedIPAddress, as an IP address. This IP address can be sent to a network access server (NAS) in an authorization profile. The msRADIUSFramedIPAddress attribute supports only IPv4 addresses. Upon user authentication, the msRadiusFramedIPAddress attribute value fetched for the user will be converted to IP address format.

Attributes and groups are retrieved and managed per join point. They are used in authorization policy (by selecting first the join point and then the attribute). You cannot define attributes or groups per scope for authorization, but you can use scopes for authentication policy. When you use a scope in authentication policy, it is possible that a user is authenticated via one join point, but attributes and/or groups are retrieved via another join point that has a trust path to the user's account domain. You can use authentication domains to ensure that no two join points in one scope have any overlap in authentication domains.

Note

During the authorization process in a multi join point configuration, Cisco ISE will search for join points in the order in which they listed in the authorization policy, only until a particular user has been found. Once a user has been found the attributes and groups assigned to the user in the join point, will be used to evaluate the authorization policy.

An authorization policy fails if the rule contains an Active Directory group name with special characters such as /, !, @, \, #, $, %, ^, &, *, (, ), _, +, or ~.

Admin user login through Active Directory might fail if the admin username contains $ character.

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.

A logging category is a bundle of message codes that describe a function, a flow, or a use case. In Cisco ISE, each log is associated with a message code that is bundled with the logging categories according to the log message content. Logging categories help describe the content of the messages that they contain.

Logging categories promote logging configuration. Each category has a name, target, and severity level that you can set, as per your application requirement.

Cisco ISE provides predefined logging categories for services, such as Posture, Profiler, Guest, AAA (authentication, authorization, and accounting), and so on, to which you can assign log targets.

For the logging category Passed Authentications, the option to allow local logging is disabled by default. Enabling local logging for this category will result in high utilization of operational space, and fill prrt-server.log along with the iseLocalStore.log.

If you choose to enable local logging for Passed Authentications, go to , click Passed Authentications from the category section, and check the check box against Local Logging.