I wanted to write this post on how to save a little time by using template access lists to copy and paste your ACLs into the command line of the wireless controller. In this small blog post, I'll share a couple templates for Blackhole, Employee, Guest and Web Redirect ACLs which anyone could use.
In this blog post, I'm going to go over a different way to configure your switch for ISE called Cisco Common Classification Policy Language (C3PL). I have known about this configuration for awhile but I will admit that I didn't really try to learn it until recent. If you read the IBNS 2.0 deployment guide here, it's pretty intimidating guide at a whopping 65 pages long and reads like a typical manual. I ended up reading Jamey Heary and Aaron Woland's Cisco ISE for BYOD Second Edition and they broke it down beautifully in 4 pages which made me go "Team C3PL."
In this blog post, I'm going to get into designing, scaling and deploying ISE. Like any piece of infrastructure, all the best configurations in the world won't help you if it's not design properly. In this post, I'm going to really focus on what I do to make an ISE implementation successful.
In this long overdue post, I'm going to go over my recently favorite release of ISE: ISE 2.3. I planned to write this a month or two ago but got a bit busy with work and other stuff so I'm catching up a little now.
In this blog post, I'm going to go over the new policy sets in ISE 2.3. A lot of people have come to me and said they were worried about having to learn the new policy sets. Well, I have good news for you: While there are some enhancements, it's not really as initimating or new as you think. Are there enhancements? Sure! But it doesn't mean you have to re-learn the whole thing if you don't want to.
In this post, I'm going to review the PassiveID features of ISE that are new as of ISE 2.2 and 2.3. In this particular post, I'll be doing it all from ISE 2.3 but bear in mind that you can do all this from ISE 2.3 as well. In ISE 2.0, there was a feature added called EasyConnect which utilized WMI logs from the Active Directory Domain Controller to check for login events. Based on those login events, ISE would make a decision to grant access. This allowed ISE to grant network access beyond the typical 802.1x and profiling methods. This functioned well but required a LOT of backend work to prepare Active Directory to share the WMI logs and if you read my earlier post here, you will see what I mean The creators of ISE decided to revamp this process and create a better way to do this in ISE 2.2 and later.
This blog post is for my ISE 2.1 notes
In this blog post, I'll go through the configuration for TrustSec and SXP for both my Catalyst 3650 switch and wireless controller. I'll walk through the configuration, create the SXP connection, and verify. After that, I'll test out a policy by connecting a client to the switch, watching the tag be applied on ingress and the policy applied.
In this blog post, we're going to go over the configuration of TrustSec in ISE 2.1. This configuration also applies to ISE 2.0 as well for the most part. While TrustSec is not a required configuration for a secure ISE deployment, it definitely has some great advantages. It's a security architecture utilizing security group tags (SGTs) that allows that network to enforce access control policy, reduce ACL complexity, and can be utilized for policy in other security devices which I will go into further in later blog posts when I go over pxGrid on different systems.
This post is going to go over the integration of ISE 2.1 and AMP for Endpoints. ISE 2.1 introduces the concept of a "Threat Centric NAC" which allows you to configure vulnerabiltiy and threat adapters to send high fidelity Indicators of Compromise (IoC), Threat Detected events, and CVSS scores to ISE so that threat-centric access policies can be created to change the privilege of the endpoint accordingly.
I'm definitely going to go over this more in future posts after I'm done with my StealthWatch series. I'll just post this high level information about some of the additional features of ISE 2.1 which I'm pretty excited about.
This is the continuation from my previous post. In this post, we're going to create some basic objects from the REST API and just push them out through POSTMAN.
I decided to play around with creating templates of my configs in XML and being able to push them via the RESTful API in ISE.
In a perfect world, you could authenticate your hosts onto the network with either dot1x or going through a guest portal but the reality is that not every device connected to your network will have the ability to navigate the guest flow or utilize dot1x. Unfortunately, most of us don't live in a perfect world and have to connect devices to our networks such as phones, IP cameras, printers, badge readers, access points, etc so for that reason, profiling comes in. What ISE will do is gather a series of attributes from the NADs that the endpoints are connected to and based on those collections of attributes, ISE is able to make a determination of what kind of device that endpoint is
In this post, I'm going to configure Hotspot access. Hotspot access is a little different than regular guest access in ISE. The use case for Hotspot is where you might want to allow guests to access the internet without issuing them credentials or directly identifying them but still have some level of control. An example of this is if you own a chain of retail stores and you want to give your customers guest access to the internet and you don't want them to have to self-register or disclose information about their identity. Hotspot would be the solution to provide access. With Hotspot access, you can have a branded portal for marketing reasons, have the user accept an AUP for legal reasons, redirect them to your company's page or maybe a webpage with the latest deals/coupons, and you can even have them enter an access code that you have displayed in this location to reduce random connections to the network from users not location in the establishment.
In this post, I'm going to create my guest wireless policy. Guest access is typically what you think of when you visit a company, connect to the wireless and then get a splash page to enter some sort of credentials you were either provided or you self-register to get your own credentials. I'm going to create a basic guest wireless policy but I'll walk you through some of the different options you can use with this policy if you want to play around with this in your own lab or you're looking to deploy this in your production network.
In this guide, I'm going to walk through MDM integration with ISE. MDM is used to deploying, securing, monitoring, integrating and managing mobile devices in the workplace. The MDM software that is download to the mobile device can control the distribution of application and patches as well as control data and configuration on the endpoint.
In this post, I'm going to walk through the BYOD policy configuration. This policy will be pushing certificate to my users via the SCEP profile we previously created inside ISE. I'll walk through some of the different options you can configure in this policy but overall, I'm going to keep the policy itself pretty simple.
In this next post, I'm going to walk through the policy creation for dot1x for wired and wireless access. As stated in a previous post, I'm going to be using PEAP-EAP-TLS but there are many different methods you can use. I'm also going to configure differentiated access based on a user's role to demonstrate some of the possibilities with ISE.
In this post, I am going to configure my wireless controller to use ISE for AAA, set up my SSIDs, and configure other basic settings. I'm going to start from the initial installation of the Virtual Wireless Controller and go through those steps. After I have that completed, I will set up all the initial configurations you will need in order to have the Wireless Controller use ISE.