Cisco Identity Services Engine (ISE) is Cisco’s next-generation policy
server that provides authentication and authorization infrastructure to the
Cisco TrustSec solution. It also provides two other critical services:

The first service is to provide a way to profile endpoint device type
automatically based on attributes Cisco ISE receives from various information
sources. This service (called Profiler) provides equivalent functions to what
Cisco has previously offered with the Cisco NAC Profiler appliance.

Another important service that Cisco ISE provides is to scan endpoint
compliancy; for example, AV/AS software installation and its definition file
validity (known as Posture). Cisco has been previously providing this exact
posture function only with the Cisco NAC
Appliance.

Cisco ISE provides an equivalent level of functionality, and it is
integrated with 802.1X authentication mechanisms.

Cisco ISE integrated with wireless LAN controllers (WLCs) can provide
profiling mechanisms of mobile devices such as Apple iDevices (iPhone, iPad,
and iPod), Android-based smartphones, and others. For 802.1X users, Cisco ISE
can provide the same level of services such as profiling and posture scanning.
Guest services on Cisco ISE can also be integrated with the Cisco WLC by
redirecting web authentication requests to Cisco ISE for authentication.

This document introduces the wireless solution for Bring Your Own
Device (BYOD), such as providing differentiated access based on known endpoints
and the user policy. This document does not provide the complete solution of
BYOD, but serves to demonstrate a simple use case of dynamic access. Other
configuration examples include using the ISE sponsor portal, where a privileged
user can sponsor a guest for provisioning wireless guest access.

This setting enables the WLC to look for the URL redirection AV-Pairs
coming from the ISE RADIUS server. This is only on a WLAN that is tied to an
interface with the RADIUS NAC setting enabled. When the Cisco AV-Pair for URL
Redirection is received, the client is put into the POSTURE_REQD state. This is
basically the same as the WEBAUTH_REQD state internally in the controller.

When the ISE RADIUS server deems the Client is Posture_Compliant, it
issues a CoA ReAuth. The Session_ID is used to tie it together. With this new
AuthC (re-Auth) it does not send the URL-Redirec AV-Pairs. Because there are no
URL Redirect AV-Pairs, the WLC knows the client does not require Posture any
longer.

If the RADIUS NAC setting is not enabled, the WLC ignores the URL
Redirect VSA’s.

CoA-ReAuth: This is enabled with the RFC 3576 Setting. ReAuth
capability was added to the existing CoA commands that were supported
previously.

The RADIUS NAC setting is mutually exclusive from this capability,
although it is required for the CoA to work.

Pre-Posture ACL: When a client is in POSTURE_REQ state, the default
behavior of the WLC is to block all traffic except DHCP/DNS. The Pre-Posture
ACL (which it is called in the url-redirect-acl AV-Pair) is applied to the
client, and what is permitted in that ACL is what the client can reach.

Pre-Auth ACL vs. VLAN Override: A Quarantine or AuthC VLAN that is
different from the Access-VLAN is not supported in 7.0MR1. If you set a VLAN
from the Policy Server, it will be the VLAN for the entire session. No VLAN
changes are needed after first AuthZ.

Client will be re-directed to the URL provided in access accept, and
put into a new state until posture validation is done. The client in this state
talks to the ISE server and validate itself against the policies configured on
the ISE NAC server.

NAC agent on client initiates posture validation (traffic to port
80): Agent sends HTTP discovery request to port 80 which controller redirects
to URL provided in access accept. The ISE knows that client trying to reach and
responds directly to client. This way the client learns about the ISE server IP
and from now on, the client talks directly with the ISE
server.

WLC allows this traffic because the ACL is configured to allow this
traffic. In case of VLAN override, the traffic is bridged so that it reaches
the ISE server.

Once ISE-client completes assessment, a RADIUS CoA-Req with reauth
service is sent to the WLC. This initiates re-authentication of the client (by
sending EAP-START). Once re-authentication succeeds, the ISE sends access
accept with a new ACL (if any) and no URL redirect, or access VLAN.

WLC has support for CoA-Req and Disconnect-Req as per RFC 3576. The
WLC needs to support CoA-Req for re-auth service, as per RFC
5176.

Instead of downloadable ACLs, pre-configured ACLs are used on the
WLC. The ISE server just sends the ACL name, which is already configured in
controller.

This design should work for both VLAN and ACL cases. In case of VLAN
override, we just redirect the port 80 is redirected and allows (bridge) rest
of the traffic on the quarantine VLAN. For the ACL, the pre-auth ACL received
in access accept is applied.

Cisco ISE profiler service provides the functionality in discovering,
locating, and determining the capabilities of all the attached endpoints on
your network, regardless of their device types, in order to ensure and maintain
appropriate access to your enterprise network. It primarily collects an
attribute or a set of attributes of all the endpoints on your network and
classifies them according to their profiles.

The profiler is comprised of these components:

The sensor contains a number of probes. The probes capture network
packets by querying network access devices, and forward the attributes and
their attribute values that are collected from the endpoints to the analyzer.

An analyzer evaluates endpoints using the configured policies and the
identity groups to match the attributes and their attribute values collected,
which classifies endpoints to the specified group and stores endpoints with the
matched profile in the Cisco ISE database.

For mobile device detection, it is recommend to use a combination of
these probes for proper device identification:

In this example of an iPad, the profiler captures the web browser
information from the User-Agent attribute, as well as other HTTP attributes
from the request messages, and adds them to the list of endpoint
attributes.

MS Active Directory (AD) is not required for a simple proof-of-concept.
ISE can be used as the sole identity store, which includes differentiating
users access for access and granular policy control.

At the release of ISE 1.0, using AD integration, the ISE can use AD
groups in authorization policies. If ISE internal user store is used (no AD
integration), groups cannot be used in policies in conjunction with device
identity groups (identified bug to be resolved in ISE 1.1). Therefore, only
individual users can be differentiated, such as employees or contractors when
used in addition to device identity groups.

Any device that initiates RADIUS requests to the ISE must have a
definition in ISE. These network devices are defined based on their IP address.
ISE network device definitions can specify IP address ranges thus allowing the
definition to represent multiple actual devices.

Beyond what is required for RADIUS communication, ISE network device
definitions contain settings for other ISE/device communication, such as SNMP
and SSH.

Another important aspect of network device definition is appropriately
grouping devices so that this grouping can be leveraged in network access
policy.

In this exercise, the device definitions required for your lab are
configured.

The controller is connected to the Ethernet port on the neighboring
switch (Fast Ethernet 1). The neighbor switch port is configured as an 802.1Q
trunk and allows all VLANs on the trunk. The native VLAN 10 allows the
management interface of the WLC to be connected.

Posture redirect ACL is configured on the WLC, where ISE will use to
restrict client for posture. Effectively and at a minimum the ACL permits
traffic between ISE. Optional rules can be added in this ACL if
needed.

Little information is known about a new device when it first comes onto
the network, an administrator will create the appropriate policy to allow
unknown endpoints to be identified before permitting access. In this exercise,
the authorization policy will be created so that a new device will be
redirected to ISE for posture assessment (for mobile devices are agentless,
therefore only profiling is relevant); endpoints will be redirected to the ISE
captive portal and identified.

Complete these steps:

From ISE, navigate to Policy >
Authorization.

There is a policy for Profiled Cisco IP Phones. This is out of the
box. Edit this as a posture policy.

Enter the following values for this policy:

Rule Name: Posture_Remediation

Identity Groups: Any

Other Conditions > Create New: (Advanced) Session >
PostureStatus

PostureStatus > Equals:
Unknown

Set the following for permissions:

Permissions > Standard:
Posture_Remediation

Click Save.

Note: Alternatively custom policy elements can be created to add ease
of use.

Click Endpoints. Associate and connect a device
(an iPhone in this example).

Refresh the Endpoints list. Observe what information is
given.

From the endpoint device, browse to:

URL: http://www (or 10.10.10.10)

The device is redirected. Accept any prompt for
certificates.

After the mobile device has completely redirected, from ISE refresh
the Endpoints list again. Observe what has changed. The previous endpoint (for
example, Apple-Device) should have changed to ‘Apple-iPhone’etc. The reason is
that the HTTP probe effectively obtains user-agent information, as part of the
process of being redirected to the captive portal.

After successfully testing the posture authorization, continue to build
policies to support differentiated access for the Employee and Contractor with
known devices and different VLAN assignment specific to the user role (in this
scenario, Employee and Contractor).

Complete these steps:

Navigate to ISE > Policy >
Authorization.

Add/Insert a new rule above the Posture Remediation
policy/line.

Enter the following values for this policy:

Rule Name: Employee

Identity Groups (expand): Endpoint Identity Groups

Endpoint Identity Groups: Profiled

Profiled: Android, Apple-iPad or Apple-iPhone

In order to specify additional device types, click the
+ and add more devices (if needed):

Endpoint Identity Groups: Profiled

Profiled: Android, Apple-iPad or Apple-iPhone

Specify the following Permissions’ values for this policy:

Other Conditions (expand): Create New Condition (Advanced
Option)

Condition > Expression (from list): InternalUser >
Name

InternalUser > Name:
employee

Add a condition for posture session Compliant:

Permissions > Profiles > Standard:
Employee_Wireless

Click Save. Confirm that the policy has been added
properly.

Continue by adding the Contractor policy. In this document, the
previous policy is duplicated in order to expedite the process (or, you can
manually configure for good practice).

With the authorization profiles and policies prepared for
differentiating access, it is time to test. Having a single secured WLAN, an
employee will be assigned the employee VLAN and a contractor will be for the
contractor VLAN. An Apple iPhone/iPad is used in the next examples.

Complete these steps:

Connect to the secured WLAN (POD1x) with the mobile device and use
these credentials:

You can look at ISE real-time log view in ISE > Monitor
> Authorizations. You should see individual users (employee,
contractor) get differentiated authorization profiles
(Employee_WirelessvsContractor_Wireless) in different
VLANs.

ISE can be configured to allow guests to be sponsored. In this case you
will configure ISE guest policies to allow either Internal or AD domain (if
integrated) users to sponsor guest access. You will also configure ISE to allow
sponsors to view guest password (optional), which is helpful to this
lab.

Complete these steps:

Add employee user to the SponsorAllAccount group. There are
different ways to do this: go directly to the group, or edit the user and
assign group. For this example, navigate to Administration >
Identity Management > Groups > User Identity Groups. Then, click
SponsorAllAccount and add employee
user.

Previously, you have configured the appropriate guest policy and groups
to allow AD domain user to sponsor temporary guests. Next, you will access the
Sponsor Portal and create a temporary guest access.

Complete these steps:

From a browser, navigate to either of these URLs: http://<ise
ip>:8080/sponsorportal/ or https://<ise
ip>:8443/sponsorportal/. Then, log in with the following:

Username: aduser (Active Directory), employee (Internal User)

Password:
XXXX

From the Sponsor page, click Create Single Guest User
Account.

For a temporary guest, add the following:

First Name: Required (for example, Sam)

Last Name: Required (for example, Jones)

Group Role: Guest

Time Profile: DefaultOneHour

Time Zone:
Any/Default

Click Submit.

A guest account is created based on your previous entry. Note that
the password is visible (from previous exercise) as opposed to hash
***.

Leave this window open showing the Username and Password for the
guest. You will use them to test Guest Portal Login
(next).

In order to secure communications with ISE, determine whether the
communication is authentication related or for ISE management. For example, for
configuration using the ISE web UI, X.509 certificates and certificate trust
chains need to be configured to enable asymmetric encryption.

Complete these steps:

From your wired connected PC, open a browser window to
https://AD/certsrv.

Note: Use the secure HTTP.

Note: Use Mozilla Firefox or MS Internet Explorer in order to access
ISE.

ISE can communicate directly with Active Directory (AD) for
user/machine authentication or for retrieving authorization information user
attributes. In order to communicate with AD, ISE must be ‘joined’ to an AD
domain. In this exercise you will join ISE to an AD domain, and confirm AD
communication is working correctly.

Complete these steps:

In order to join ISE to the AD domain, from ISE go to
Administration > Identity Management > External Identity
Sources.

From the left pane (External Identity Sources), select
Active Directory.

On the right-hand side, select the Connection tab
and enter the following:

When AD groups are added, more granular control is allowed over ISE
policies. For example, AD groups can be differentiated by functional roles,
such as Employee or Contractor groups, without the related bug being
experienced in previous ISE 1.0 exercises where policies were limited only to
users.

In this lab, only the Domain Users and/or the Employee group are used.