Thank you for opening to the first page, as this is a step many people don’t take in a technical manual. I have a few technical books on my shelf that I use exclusively to flip through to specific chapters and have never read the introduction. In that spirit, let’s keep the intro short so we can get into the meat of what you’re here for.
In this book we hope to bring a practical perspective to deploying the Cisco Identity Services Engine (ISE) system that may otherwise be elusive to the uninitiated in the arts of edge authentication or those who don’t have lots of time to spend in the lab playing.
A little history: Before ISE was a product, if you were a Cisco customer and you wanted to deploy edge authentication that used 802.1x, enforce policy based on the posture of a personal computer (PC), deploy robust guest provisioning/web authentication, and profile what connected devices physically, you’d need to buy four separate products. These included:
• Cisco Access Control Server (ACS)
• Cisco Clean Access
• Network Admission Control (NAC) Guest
• NAC Profiler
Someone at Cisco (whose hand we’d really like to shake) decided that having so many products in a design was a really poor idea and Cisco went about creating a product that brought each of those together.
ISE provides edge authentication services for networks in a variety of ways:
• IEEE 802.1x authentication
• Media access control (MAC) Authentication Bypass (MAB)
• Web authentication
• Posture assessment
• Device profiling
• External mobile device management (MDM) integration
• Authentication via application program interface (API)
To accomplish these functions, ISE integrates into network access devices (switches, wireless controllers, virtual private network (VPN) concentrators) with Remote Authentication Dial-In User Service (RADIUS). Not only is it simply RADIUS integration, but also the great majority of what ISE provides is standards-compliant RADIUS. Being that Cisco is a large manufacturer (let’s point out the obvious), there are some proprietary features ISE provides; we’ll address some of those individually later.
Because ISE is a RADIUS server at its core, when you configure it, you have to remember the three A’s (aka AAA or triple A):
• Authentication
• Authorization
• Accounting
Each of these not only need to be configured on your network access devices but are also the process that ISE goes through in processing devices that are connecting to the network.
When a RADIUS authentication request first comes in, it goes to “authentication” policy. This is where ISE determines if the identity of the user or device is who they say they are. This process could involve 802.1x authentication, MAB, or a web authentication.
For the authentication to be successful, a few possible things could be validated, which depends on what is happening for the specific device. If a password is used in the authentication, the password is validated against the Active Directory (AD) and/or Lightweight Directory Access Protocol (LDAP) database. If a certificate is used, it is validated against the certification authority (CA) certificate chain; perhaps its validity is also checked for revocation status. If the MAC address is presented for an authentication bypass, MAB authentication is processed, meaning the MAC address is checked against the MAC addresses in a database of known MAC addresses.
At the end of the authentication process we should know who the user is who is asking for network access. This would mean that the password presented is valid, or the certificate is valid in our database, or the MAC address is in our database. If this is the case, then the process proceeds. If the password or certificate or MAC address is invalid, ISE will stop the process and send a RADIUS access-reject.
Now it’s important to realize that just because a device or user is authenticated doesn’t mean they’re necessarily going to be authorized for network access. This is an important concept. Again, the purpose of authentication is only to determine the identity of the user or device and not necessarily to determine what we would like to do with them; that’s the role of the authorization in ISE.
Authorization takes place after authentication and while the rules look very similar to authentication (for those already accustomed to ISE), the purpose is to say, now that I know who this is, what level of access do I wish to give them to my network? That level of access may be all sorts of things:
• Unfettered access to network resources
• No network access
• Access to network resources with some limitations
The first two of these examples are pretty easy to break down.
In the case of unfettered network access, this may be most applicable to information technology (IT) administrators who do need access to all resources to perform job duties.
No network access may come about when we know who or what the user or endpoint is, but we don’t want them to have any access. In that case the device would have succeeded in authenticating, but failed to authorize.
Access with limitations is really where some of the magic can happen. You then have the ability to deploy policy and impose it on users to ensure that the correct people and devices have appropriate access. The example that is often brought up to customers may be something like:
• Marketing users should have access to marketing servers and email servers but not finance servers.
• Finance users should have access to finance servers and email servers but not marketing servers.
But what if you want to know whether the marketing users are connecting to the network with an Android phone? Would you want them to have access to their corporate servers then?
That’s a common situation that ISE can help provide a solution for. ISE has a built-in profiler that helps answer the following question: What kind of device is the user connecting with? ISE develops the endpoint profile by learning a variety of things about it. Does the device Organizationally Unique Identifier (OUI) tell us who manufactured the device? How does it ask for an Internet Protocol (IP) address and is there something that gives us a clue about what a device is as it asks for an address? What kind of browser is it using? Is it running a protocol that will announce what it is (Cisco Discovery Protocol (CDP) or Link Layer Discovery Protocol (LLDP))?
Based on a combination of a variety of things like this we can, with some certainty, understand what the endpoint device is and then potentially apply policy based on that information. The policy may look like the following:
• Marketing users coming in with Android phones don’t get access to corporate servers but do get access to the internet and the mail server.
• Marketing users connecting with Microsoft Windows PCs are allowed access to marketing servers and email servers.
You see where we’re going with this; we are looking to deploy policy based on a range of criteria based on who the person may be and what kind of device they are connecting with. Let’s take this a step further and look into another example. Say you have a third party coming to work at your office, someone like an outside auditor. You need to provide this person some level of internal access for them to perform the job functions they’ve been hired by your company to do, and they’re going to be using the PC that their employer issued to them. Given that his or her machine is not a member of your domain, and this user is not indoctrinated into your security policy, you need to understand more about what the device is and who may be using them. ISE can help with this in that we can perform a posture assessment of the device. With this posture assessment we can obtain really useful information about the PC including specific Windows versions, what version of antivirus is deployed and whether it has been updated recently, and other arbitrary things such as: are certain patches installed, are registry keys set, do files exist, and are applications or services running? This lets us create network policy that may read something like:
• Auditors connecting with PCs that are running recently an up-to-date antivirus are permitted access to finance servers and the internet.
• Auditors connecting with PCs that are running out-of-date antivirus applications are permitted access to the internet in order to obtain definition updates but are not permitted access to internal resources.
This provides us really in-depth policy creating functionality all from one user interface (UI) and one product to integrate into your network. From a single authorization policy we can deploy policy about who the user is and what they’re connecting with, and we can apply policy based on the running state of the end system. That is what we’re able to bring all together with ISE.
In our opinion, most important piece of ISE (for the uninitiated) is the concept of “Change of Authorization” (CoA). This is the magical part of ISE that lets our advanced functionality work. CoA is a RADIUS datagram that is sent from the RADIUS server to the authentication device (switch, controller, etc.) that can change the state of an edge client device (PC, phone, printer, etc.). Previously for a device to have its RADIUS authentication state changed, it would have to be entirely disconnected and authenticated from the start. There was simply no RADIUS mechanism for the RADIUS server to send an unsolicited update to an authenticator about a client that was previously allowed onto the network. This allows ISE to actually manipulate the live network access state of clients in a variety of ways:
• The administrator may revoke a user’s access in real time from a central authentication server.
• ISE may require a login to a website. Once the login is successful, access may be granted to a user. CoA is required to present the website redirect, and then remove it after the user enters authorized credentials.
• A previously unknown device is connected to the network. ISE may learn that this is actually valid and it may authorize the device onto the network.
If a network device does not support CoA, the utility of deploying ISE is greatly reduced, but not entirely negated; we just lose the ability to do things like the above.
In this book we’re going to spend some time at a variety of points going through useful design options that we’ve found to be helpful in our deployments. The configurations will include really important broad design points, such as how to design strong authentication for corporate assists or how to configure enforcement in a wired environment. We’ll also go through much smaller points such as how to design ISE rules efficiently or what ISE settings may be particularly useful.
Lastly, once you’ve finished designing and deploying your ISE implementation, we’re going to spend some time going over monitoring, reporting, and troubleshooting. What’s the point of having all this identity information on your network if you don’t bother reporting and looking to see who is authenticated where and when and with what? ISE has built-in reporting capabilities but depending on what you’re looking to get out of it there are capabilities with syslog and third-party products that give you additional capabilities that augment your network viability.
We want to get something out of the way early here—ISE has a reputation of being a challenging product to deploy. This is an unfair characterization because the challenges come mostly from complexity that the administrator has created for themselves. This complexity can be broken down into a few categories:
• Cumulative effect of design requirements
• Gratuitous design requirements that may or may not increase security
• Numerous complex integrations
• Trying to fit old paradigms into a new product
There are a few ways we want to help you out here. One, we want to give you good design options with the tools you need to deploy them in your environment. We also want to call out the popular, but not necessarily effective, design elements.
Lastly, we hope to demystify integrations because broken down to individual components the concepts in any particular ISE deployment are not challenging. Complexity in ISE deployments comes from the cumulative sum of small manageable problems in a variety of disciplines (e.g., Cisco Internetworking Operating System (IOS) and Microsoft AD and public key infrastructure (PKI)). By breaking down the configuration and design elements individually we hope you’ll have a good grasp on how ISE may be deployed in your environment by the time you get through this book.
Our goal is to focus on practice examples of how ISE is configured and practical tips for ISE design. ISE is extraordinarily configurable and there is simply no way to get through every possibly design; therefore, we intend to cover common and useful designs and configurations. Since ISE is extremely flexible in design it can seem daunting when you first start out; taking things in small sections can make much easier. We’ve endeavored to design this book to do just that. One of the sales guys at my company has said to a variety of our customers: “ISE can boil the ocean, but we don’t want to do that.” At the risk of giving a sales guy too much credit, he’s exactly right.
We also will not cover every feature available in ISE because some provide very narrow-use cases, or others are useful to only a very small handful of customers and are generally impractical for most environments. It’s not that we don’t like these features; some we really like but they are practical for a small sliver of deployments out there and are not practical for most users. If we don’t mention a specific ISE feature or functionality that you think is practical for your organization, don’t be shy; use it! Every deployment is different; we’re just sharing what we think and you’re welcome to disagree with us.
In any case, we hope you enjoy this book and find it helpful.