Identity Services Engine Portal

Objective and Rationale Behind Identity Service Engine

‍
At the start of this project, we had multiple Service Set Identifiers (SSID), one for guests, one for employee BYOD, another for apple BYOD devices, and more. We wanted to consolidate all of these SSIDs into a single SSID for the nearly 60-acre campus. To accomplish this, we wanted a portal that would display a login screen and an optional link for guest users to create a temporary account upon connecting to the network. We also did not want the guest wireless network to interact with any of our production devices and be isolated via a firewall.

This project revolved around moving our current bring your own device (BYOD) solution to the  Cisco Identity Service Engine. Our organization provides free internet access to guests visiting for a short period. Cisco ISE creates local accounts for Guests. We also had instituted a policy that allows the employees to connect their devices such as smartphones to the corporate wireless network and use it for business purposes. This is referred to as the Bring Your Own Device (BYOD) policy. However, since the individuals own these devices, they don’t like to install management software that allows organizations to “manage” the endpoint.

‍
We went with Cisco ISE as it allows us to create accounts for visitors and authenticate them for audit purposes. Cisco ISE also provides a set of APIs to integrate with other systems such as vendor management systems to create, edit and delete Guest accounts. The built-in Certificate Authority (CA) to make and help distribute certificates to different devices was also a factor in onboarding aspects of the BYOD process. The built-in CA provides a complete certificate lifecycle management.

‍

‍

Every Cisco ISE session begins with authentication, whether to a user or a device. Authentication can be active authentication or passive authentication (not including 802.1X session): An authentication is done using 802.1X when Cisco ISE authenticates the user against an Identity Source. In contrast, in passive authentication (Easy Connect), Cisco ISE learns about the user after the user authenticates against the Identity Source like Microsoft’s Active Directory (AD), and the AD notifies ISE.

‍

Devices Involved:

Current Wireless Lan Controller: Cisco Catalyst 9800 Series Wireless Controllers

Current Anchor: Cisco 5520 Wireless Controller

Access Point: Cisco Aironet 3800 Series

Outdoor Access Point: Cisco Aironet 1560 Series Outdoor

‍

What is the Identity Service Engine and the Identity Services Engine Passive Identity Connector

Cisco web security appliance can authenticate proxy users actively against LDAP or active directory servers. The WSA can also passively identify proxy users without direct communication to a directory server. Authentication is accomplished using the Cisco identity service engine or ISE. ISE is an influential center for all things authentications. It is capable of enforcing network access using 802.1x, radius, or web authentication. ISE any or all these mechanisms to build a user session database containing the username, IP address, mac address security group tag, and more. ISE then makes this database available using an API called the platform exchange grid or PxGrid. The WSA can connect to ISE via PxGrid and subscribe to user authentication sessions. This allows the WSA to obtain user to IP mappings and security groups tags for all known network users. The WSA can also connect to the external restful service or ERS in the latest versions and obtain user group information without ever contacting the director server. Certificates must be generated and installed on both ICE and the WUSA. PxGrid is accessible Over a mutually authenticated TLS connection meaning that certificates must be used to authenticate both the client and server-side. This requires specially designed certificate templates when using active directory integrated certificate authorities. Details on how to integrate the solutions, including configuring an active directory certificate authority and issuing the certificates, are available below.

‍
When a user logs on the network, they are authenticated to ice using any number of methods that are independent of the WSA. They may be authenticated using a switch that is capable of 802.1x, mac authentication bypass, or even web authentication redirect. Once this happens, the session is created in the ISE database. The WSA connection to PxGrid is always on. The User, IP, and SGT information are populated in the WSA ISE datastore. When the client its first web request through the WSA, they are easily identified without the need for active authentication. ISE can also identify users without requiring active authentication.

Available in every ISE installation is the Passive identity (PassiveID) feature. Instead of relying on 802.1x or web authentication, this feature can connect to active directories using the windows management instrumentation interface and subscribe to specific events in the Windows security event log. PassiveID can also consume cis log messages to identify user login events. When a user logs into their domain computer, an event is generated which triggers ISE to create a user session. This session is also available to the WSA over PxGrid. Passive ID is available in the complete ISE installation or as a stand-alone virtual appliance known as the Identity Services Engine Passive Identity Connector or ISE-PIC. This is a stripped-down version of ISE without features like profiling, security group tags, or 802.1x. It operates the same way as the passive identity feature in the full ISE product. ISE-PIC is positioned as the successor to the context delivery agent or CDA. CDA also subscribed to the windows event log to learn about a user through IP mapping but does not provide as many features as ISE-PIC, such as ERS for group information, active endpoint probes, and Syslog providers. The configuration on the WSA is the same for ISE-PIC as it is for ISE.

Once ISE or ISE-PIC is configured with the WSA, user and group information may be used in various policy contracts in the WSA. In the identity profile, the WSA can attempt to identify a user transparently ISE, and if no information is available, fall back to active authentication. This removes load from WSA authentication services. The information retried for the WSA from ISE can be used in decryption policies and access policies. IF ISE-PIC is used, the available criteria are username and group membership. While the security group tag is present, ISE-PIC does not support them. If ISE is used, the available criteria are security group page, username, and group membership. In version11.8, both AD and ISE information can be used in an individual policy. This allows for the use of fallback when user and group information is not available in ISE, and active authentication through a direct server is used instead.

‍

Complications, Resolutions, Current State

‍
We integrated ISE into the network, but we had a problem where the CNA was not popping up for apple devices. We believe this may have something to do with the captive network assistant bypass being enabled. We had enabled the captive bypass portal following the Cisco Wireless Controller Configuration Guide, Release 8.4 - WLAN Security [Cisco Wireless LAN Controller Software]. The captive bypass suppressed the pseudo apple browser (Captive Network Assistant) from popping up for any WLAN on that controller. Captive bypass must be enabled in the single SSID flow for BYOD. However, if this is enabled, it will suppress the mini-browser for guest flows and since there is now support for the mini-browser with ISE 2.2 there is no need to enable captive portal bypass on the controller. The client connects to the guest network, and the mini-browser will pop and auto-login.

If disabling captive bypass does not produce the desired results, there is another option we may consider. We would still like seamless flow for guests using mini-browser and BYOD on the same controller, perhaps setting up DNS-based ACLs for the ACL_BYOD_REDIRECT and adding URL captive.apple.com to the ACL_GUEST_REDIRECT, which will redirect appropriately.

The URL captive.apple.com comes from WISPr, a draft protocol that enables users to roam between different wireless service providers. Some devices (For example, Apple iOS devices) have a mechanism to determine if the device is connected to the Internet, based on an HTTP WISPr request made to a designated URL. This mechanism automatically opens a web browser when a direct connection to the Internet is not possible. This enables the user to provide his credentials to access the Internet. The actual authentication is done in the background every time the device connects to a new SSID. The client device (Apple IOS device) sends a WISPr request to the controller, checking for the user agent details and triggering an HTTP request with a web authentication interception. After verifying the IOS version and the browser details provided by the user agent, the controller allows the client to bypass the captive portal settings and access the Internet.

At this time I am currently in contact with Apple Corporate  Support while researching possible resolutions.