ZBISE03 – Overview of our Cisco ISE 2.3 Use Cases for the ZBISE Blog Series

Hey Ziglets, welcome back.  We have a new Zigbit for our Zigbits Blog Series on Cisco ISE 2.3.  Today we are going to go through a number of what I would call design related items when it comes to deploying any policy engine in an environment.

It makes sense to me to have a post to discuss what are our end goals are for this ISE deployment we are building over the next couple of months.  I would have something like this when deploying a solution, no matter the technology, for any customer or environment I was doing work in.  Having a Blueprint is useful for us to validate what we are doing is what we intended to do from the beginning.  Some would even call this a Design of a sort.

So here goes.


Network and Server Diagram:

Here is our reference diagram that we will be using throughout this blog series.


Related Posts:

If you haven’t seen these posts yet, you should check them out


The Trusted and Untrusted Model:

I’m sure there are many different ways to break these use cases down, and I’m sure I am not the first or will be the last to use the Trusted and Untrusted Model but this has been the best way over the years to properly implement the Use Cases I have seen with the different deployments I have done.

In this model, we have a number of terms that we should define.  Once defined then we will have an example of these terms for our Lab deployment that we will be utilizing throughout this lab series.

Terminology:

  • Trusted Devices – These are normally company owned and company controlled devices
  • Trusted Users – These are user accounts that are in some sort of management or directory system. For most deployments, you will utilize Active Directory in some aspect.
  • Untrusted Devices – Any device that is not company owned or controlled. External devices and personal devices fit in this category
  • Untrusted Users – Any user that is not in a management or directory system. These could include Unknown users, local users, Guest accounts, and a number of other options.

Our Lab Trusted and Untrusted Model:

For our lab deployment, our Trusted Devices are going to be Active Directory Domain Computers, Cisco Phones, Cisco APs, and an XBox One.  Our Trusted Users are going to be Active Directory Domain Users with a couple of different groups in AD.

  • Trusted Devices
    • Lab Domain Computer
    • Cisco VoIP Phone
    • Cisco Access Point
    • XBOX One
  • Trusted Users
    • Lab Domain User
    • Lab Privileged Domain User
  • Untrusted Devices
    • Every other device that is not in the Trusted Devices category
  • Untrusted Users
    • If you do not have an account on our domain, Zsiga.lab, then you are an untrusted user. For our deployment, we will allow guest access for users that are not on the domain.

Authentication and Authorization:

I always like to break the use cases down into two phases.  The first phase is authentication and the second phase is authorization.  I do this because, in most cases authentication is straightforward to troubleshoot if something isn’t working properly.  In my experience, authorization is where you can spend countless hours trying to find that one server IP you needed in your Downloadable ACL to fix the 6 minutes it takes a user to log into a Computer.

As we go through our use cases, you will see how you can focus on authentication validation first, then once you know you are good with authentication for that specific use case, you can start working on the Authorization portion of the use case, or the permissions that use case is allowed to have.

Now that we have Identified the Trusted Devices, Trusted Users, Untrusted Devices, and Untrusted Users for our deployment, we need to determine how we are going to authenticate each specific case.

Authentication Methods:

We have a few options when it comes to authentication with each option having Pro and Cons when compared to the others.  We have Web, MAB, 802.1x PEAP-MSCHAPv2, and 802.1x EAP-TLS.  Both EAP-TLS and PEAP-MSCHAPv2 utilize Certificates to authenticate the session (Computer and/or User), but in different ways.  EAP-TLS is the gold standard for Security but it can also be the most difficult to implement depending on your PKI environment.  PEAP-MSCHAPv2 is less secure than EAP-TLS but doesn’t require the same level of PKI involvement that EAP-TLS does.  PEAP-MSCHAPv2 is usually easier to implement than EAP-TLS.  There are a number of other authentication protocols within 802.1x but these two are the most popular and the only two we are going to implement in this lab.

After 802.1x, we have Mac Authentication Bypass, or MAB.  This authentication protocol is utilizing the MAC Address of the device to authenticate to the network.  MAC Addresses can be fairly easily spoofed now a days which makes MAB not always the preferred option.  MAB is used for devices that do not support 802.1x today, like a Cisco Access Point and an XBOX One.

The final authentication method that we are going to utilize in our lab is Web Auth.  Web authentication is a way to authenticate via a splash page of some sort to an internal database.  We traditionally use Web authentication for Guest Access in conjunction with MAB.

Authorization Methods:

There are a number of different authorization methods, or permissions, we can apply once a device and / or user has authenticated.  There are honestly too many to go through all of the different options but we will show some of the common attributes that are used in real world deployments today.  For our lab we will be using Change of Authorization (CoA), downloadable ACL (dACL), Voice Domain permissions, VLAN override, and Airspace ACL.  Once again, there are many more so this is not an inclusive list but if we add any other method I will make sure to go into some detail on it at that time.


Our Lab Use Case Design

Here is what we are going to do for each of our devices that we have identified in the Trusted / Untrusted Model.  For anything that we are going to use 802.1x Authentication, we are going to do both PEAP-MSCHAPv2 and EAP-TLS to show these two authentication methods.

Trusted Devices and Trusted Users

  • PEAP-MSCHAPv2 on Wired:
    • Domain Computer with downloadable ACL
    • Domain User with downloadable ACL
    • Privileged User with full access
  • PEAP-MSCHAPv2 on Wireless:
    • Domain Computer with Airspace ACL
    • Domain User with Airspace ACL
    • Privileged User with full access
  • EAP-TLS on Wired:
    • Domain Computer with downloadable ACL
    • Domain User with downloadable ACL
    • Privileged User with full access
  • EAP-TLS on Wireless:
    • Domain Computer with Airspace ACL
    • Domain User with Airspace ACL
    • Privileged User with full access
  • Cisco VoIP Phone
    • Profiled on Wired over MAB, Voice Domain + downloadable ACL
  • Cisco AP
    • Profiled on Wired over MAB, VLAN Override + downloadable ACL
  • XBOX One
    • Profiled on Wired over MAB, VLAN Override + downloadable ACL

Untrusted Devices / Users

  • Guest Access
    • Hotspot
    • Self Registered
    • Sponsored Guest

Untrusted Devices and Trusted Users

  • Bring Your Own Device (BYOD) Access

Use Case Organization with Policy Sets

Now I’m sure some of you might be thinking that this sounds confusing, there are a lot of moving pieces, how can we manage all of this?  Well not to fear, Cisco ISE has a feature called Policy Sets to help us organize and manage the Use Cases you are deploying.  You can really organize them in so many different ways.

For our Lab deployment, we are going to have two policy sets, one for Wired use cases called WIRED and one for Wireless use cases called WLAN. Now when we break the use cases down like this, it makes it easier to understand, manage, and troubleshoot when needed.  Here are two pictures of how the use cases in our lab are going to look. Keep in mind, throughout the next few months we may make some changes to these use cases.

WIRED Use Cases / Policy Set:

WLAN Use Cases / Policy Set:


Related Resources:

Cisco ISE Community

MAC Authentication Bypass Deployment Guide

RFC 3580: IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines

RFC 4072: Diameter Extensible Authentication Protocol (EAP) Application

RFC 7268: RADIUS Attributes for IEEE 802 Networks

RFC 8044: Data Types in RADIUS


Ask questions and give feedback


Engage with Zigbits further:


Engage with me further:


Transparency:

This post may contain affiliate links to products or services were I may receive a level of compensation from your actions by following those links. This is seamless to you and does not add any additional cost to the products or services in question. In addition, I do not let any affiliate relationship cloud my judgement or my recommendation of a product or service. My recommendations will always be above reproach.  This is my commitment to you Ziglets!

Michael “Zig” Zsiga II, CCDE™ 2016::32, CCIE™ #44883 has been in the networking industry a little over 15 years. He is currently a Lead Technical Architect at ePlus in the New England region of the United States. Zig holds an active CCDE and two CCIE certifications, one in Routing and Switching and the second in Service Provider. Zig also holds a Bachelor’s of Science in Computer Science from Park University. Zig is a father, a husband, a United States Marine, a gamer, a nerd, a geek and a big soccer fan. Zig loves all technology and can usually be found in the lab learning and teaching others. Zig is a co-organizer of The Boston Network Operators Group (www.bosnog.org), runs multiple CCIE Study groups, and is a newly published author. Zig lives in New Hampshire, USA with his wife, Julie and their son Gunnar.

Leave a Reply

Your email address will not be published. Required fields are marked *