Practical Deployment of Cisco Identity Services Engine (ISE)

Real-World Examples of AAA Deployments

Andy Richter, Jeremy Wood

• Publisher: Syngress
• Year: 2015
• ISBN:
  9780128045046
• Topic: Ciencia de la computación
• Subtopic: Ciberseguridad

With the proliferation of mobile devices and bring-your-own-devices (BYOD) within enterprise networks, the boundaries of where the network begins and ends have been blurred. Cisco Identity Services Engine (ISE) is the leading security policy management platform that unifies and automates access control to proactively enforce role-based access to enterprise networks. In Practical Deployment of Cisco Identity Services Engine(ISE), Andy Richter and Jeremy Wood share their expertise from dozens of real-world implementations of ISE and the methods they have used for optimizing ISE in a wide range of environments.

ISE can be difficult, requiring a team of security and network professionals, with the knowledge of many different specialties. Practical Deployment of Cisco Identity Services Engine(ISE) shows you how to deploy ISE with the necessary integration across multiple different technologies required to make ISE work like a system. Andy Richter and Jeremy Wood explain end-to-end how to make the system work in the real world, giving you the benefit of their ISE expertise, as well as all the required ancillary technologies and configurations to make ISE work.

Chapter 1

Introduction

Abstract

This chapter introduces some history of the product field Identity Services Engine (ISE) fits into and has a very high-level overview of topics that will be covered. We talk about some of the more common scenarios that companies face that will drive them to implement ISE as well as some problems that can be solved with it. Core concepts such as what AAA is and how it is used in ISE will be discussed before talking about going into general ISE features and how they could be utilized.

Keywords

introduction

history

AAA

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 particular...

Table of contents

• Cover
• Title page
• Table of Contents
• Copyright
• Acknowledgments
• Chapter 1: Introduction
• Chapter 2: ISE Clustering and Basic Setup
• Chapter 3: Authentication Methods
• Chapter 4: Policy Elements
• Chapter 5: Authentication
• Chapter 6: Authorization
• Chapter 7: Network Access Device Configuration
• Chapter 8: ISE Profiling
• Chapter 9: ISE Portals and Guest Access
• Chapter 10: Deployment Strategies
• Chapter 11: ISE Policy Design Practices
• Chapter 12: Corporate Authentication Designs
• Chapter 13: BYOD Designs
• Chapter 14: ISE Posture Assessment
• Chapter 15: VPN Integrations
• Chapter 16: ISE Reporting and Logging
• Chapter 17: ISE CLI
• Chapter 18: ISE Administration
• Subject Index